thtroyer

joined 1 year ago
MODERATOR OF
[–] [email protected] 1 points 3 months ago

Oh, nice! I'm going to have to check that out!

 

First version of a new fantasy console/computer from Lexaloffle is available to purchase now, on sale till the end of the month.

I haven't tried it yet (other than limited messing around with the Picotron playground in the past), but am excited to check it out soon.

From their website,

Picotron is a Fantasy Workstation for making pixelart games, animations, music, demos and other curiosities. It has a toy operating system designed to be a cosy creative space, but runs on top of Windows, MacOS or Linux. Picotron apps can be made with built-in tools, and shared with other users in a special 256k png cartridge format.

Excellent video introduction by Krystian (Lazy Devs) here.

And like PICO-8, you can play anything posted to the BBS in your browser here

[–] [email protected] 12 points 3 months ago

This is probably going to be similar to Apple's find system, which is a low powered Bluetooth based system. Apple Airtags and powered-off phones just broadcast a "I am here" signal once in a while that other devices can receive and report back to Apple.

[–] [email protected] 4 points 4 months ago (1 children)

Having used PHP and Java extensively in my career, it's always entertaining to read what people think about these languages.

[–] [email protected] 17 points 4 months ago

Based on some places I used to work, upper management seemed convinced that the "idea" stage was the hardest and most important part of any project, and that the easy part is planning, gathering requirements, building, testing, changing, and maintaining custom business applications for needlessly complex and ever changing requirements.

[–] [email protected] 3 points 4 months ago

Absolutely.

I've seen so many projects hindered by bad decisions around performance. Big things like shoehorning yourself into an architecture, language, or particular tool, but even small things like assuming the naive approach is unacceptably slow. If you never actually measure anything though, your assumptions are just assumptions.

[–] [email protected] 1 points 4 months ago

What? The GPL would have offered no more protection for this exact scenario than the LGPL (or any other license for that matter).

[–] [email protected] 2 points 5 months ago* (last edited 5 months ago)

Null is terrible.

A lot of languages have it available as a valid return value for most things, implicitly. This also means you have to do extra checking or something like this will blow up with an exception:

// java example
// can throw exception
String address = person.getAddress().toUpperCase();

// safe
String address = "";
if (person.getAddress() != null) {
    person.getAddress().toUpperCase();
}

There are a ton of solutions out there. Many languages have added null-coalescing and null-conditional operators -- which are a shorthand for things like the above solutions. Some languages have removed the implicit nulls (like Kotlin), requiring them to be explicitly marked in their type. Some languages have a wrapper around nullable values, an Option type. Some languages remove null entirely from the language (I believe Rust falls into this, using an option type in place of).

Not having null isn't particularly common yet, and isn't something languages can just change due to breaking backwards compatibility. However, languages have been adding features over time to make nulls less painful, and most have some subset of the above as options to help.

I do think Option types are fantastic solutions, making you deal with the issue that a none/empty type can exist in a particular place. Java has had them for basically 10 years now (since Java 8).

// optional example

Class Person {
    private String address;
    
    //prefer this if a null could ever be returned
    public Optional getAddress() {
        return Optional.ofNullable(address);
    }
    
    // not this
    public String getAddress() {
        return address;
    }

When consuming, it makes you have to handle the null case, which you can do a variety of ways.

// set a default
String address = person.getAddress().orElse("default value");

// explicitly throw an exception instead of an implicit NullPointerException as before
String address = person.getAddress().orElseThrow(SomeException::new);

// use in a closure only if it exists
person.getAddress().ifPresent(addr -> logger.debug("Address {}", addr));

// first example, map to modify, and returning default if no value
String address = person.getAddress().map(String::toUpperCase).orElse("");
[–] [email protected] 5 points 5 months ago (1 children)

While so many things are so much better than they used to be in the programming ecosystem, I feel like entry-level GUI programming is so much worse.

This will probably be an unpopular opinion, but Visual Basic (pre .NET) was one of the easiest ways to make a simple, contemporary (for the time) GUI. Drag and drop some elements, modify the UI properties, double click and add code. It made for an excellent introduction to programming because the UI portions were simple and intuitive enough to stay out of the way.

The rest of VB wasn't great. Weird language/syntax/keywords keywords, closed environment, mediocre tooling. But for building UIs? I haven't used anything as easy as that and it's been over 20 years now...

I don't have any recommendations unfortunately. Almost everything I do is web based or command line. Web UIs aren't terrible, but there's a learning curve and lots of limitations. Haven't found anything for desktop apps I like lately (last one I built was also with tkinter for a small Python project. Bleh.)

[–] [email protected] 3 points 5 months ago

Best decision I made was taking an internship. I wasn't really looking for one, but through some connections, one basically fell in my lap. It was in old tech I messed with in high school, so I was reluctant, but getting real world programming experience was fantastic. The team was great and I helped solve some interesting problems on a small project of theirs. They kept me on as long as they could (>1 year). I think people can be way to idealistic, especially when starting out. Go get a year or two somewhere, anywhere. You'll have a ton more marketability and control over where you end up with experience and professional references.

Biggest career regret was waiting around afterwards for a time to try to get hired on at that same place. Not a ton of programming jobs locally and I wanted to continue my work there, but the company went through semi-frequent growth/shrink phases, and my team wasn't able to get me hired in, though they did try for a while. There were plenty of other good things happening in my life during the down-time after this job and before the next, so it's not really something I regret, but I definitely won't wait on a company like that again.

[–] [email protected] 2 points 6 months ago
[–] [email protected] 2 points 6 months ago (2 children)

I noticed you don't have a build/dependency management tool set up. I find having one makes project setup and producing builds much easier, for myself and others.

If you're interested, I might be able to add Maven to it and submit a PR. :)

 

I enjoy the limited environment, retro-like environment myself. It limits my choices to stay focused on small projects, while providing a fairly robust and modern environment to work in.

view more: next ›