• 0 Posts
  • 13 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle




  • 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<String> 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("");
    

  • 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.)


  • 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.


  • As a normal software dev, I wouldn’t want to work in the games industry at all. There’s plenty of interesting and well paying work in this field.

    And then I tinker on the side. I don’t think it’s ever been easier to make your own games as a hobby. So many great tools and resources to learn from. PICO8 has been a blast, but going to learn something more capable soon - not sure if that’ll be Godot, Raylib, or LibGDX yet, but I’ll probably but I’ll probably try prototyping some stuff to figure it out.






  • I’m reluctant to call much “bloat”, because even if I don’t use something doesn’t mean it isn’t useful, to other people or future me.

    I used to code in vim (plus all sorts of plugins), starting in college where IDEs weren’t particularly encouraged or necessary for small projects. I continued to use this setup professionally because it worked well enough and every IDE I tried for the main language I was using wasn’t great.

    However, I eventually found IDEs that worked for the language(s) I needed and I don’t have any interest in going back to a minimalistic (vim or otherwise) setup again. It’s not that the IDE does things that can’t be done with vim generally, but having a tool that understands the code, environment, and provides useful tooling is invaluable to me. I find being able to do things with some automation (like renaming or refactoring) is so much safer, faster, and enjoyable than doing it by hand.

    Features I look for/use most often:

    • Go to (both definition and usages)
    • Refactor tooling (renaming, inlining, extracting, etc).
    • Good warnings, along with suggested solutions. Being able to apply solution is a plus.
    • Framework integrations
    • User-friendly debugger. Ability to pause, drill in, and interact with data is immensely helpful with the type of applications I work on.
    • Configurable breakpoints.
    • Build tool integrations. Doing it on the console is… fine… but being able to set up what I need easily in the IDE is preferable.

    Features I don’t use or care so much about? Is there much left?

    • My IDE can hook up to a database. I’ve tried it a few times, but it never seemed particularly useful for the apps I work on.
    • git integration. I have a separate set of tools I normally work with. The ones in my IDE are fine, but I usually use others.
    • Profiler. I use it on occasion, but only a few times a year probably.

    I do code in non-IDE environments from time to time, but this is almost always because of a lack of tooling than anything else. (Like PICO-8 development)