Even if you decide to not release it for the public and keep it to yourself, can be a political issue. The mere existence of something can create a imbalance of capabilities, e.g. people with access to the software have advantages over people with no access to it, which can be political.

In this sense, politics is a weird lens to view such abilities/actions, rather than something like socioeconomics. Granted, government policy affects peoples’ wellbeing, which can definitely affect their political views, but making the jump to “everything is political” feels like a stretch?

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

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.

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

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.

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.

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

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

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.

Oh, nice!

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

https://exercism.org/tracks/kotlin

Java

My take on a modern Java solution (parts 1 & 2).

package thtroyer.day1;

import java.util.*;
import java.util.stream.IntStream;
import java.util.stream.Stream;


public class Day1 {
    record Match(int index, String name, int value) {
    }

    Map numbers = Map.of(
            "one", 1,
            "two", 2,
            "three", 3,
            "four", 4,
            "five", 5,
            "six", 6,
            "seven", 7,
            "eight", 8,
            "nine", 9);

    /**
     * Takes in all lines, returns summed answer
     */
    public int getCalibrationValue(String... lines) {
        return Arrays.stream(lines)
                .map(this::getCalibrationValue)
                .map(Integer::parseInt)
                .reduce(0, Integer::sum);
    }

    /**
     * Takes a single line and returns the value for that line,
     * which is the first and last number (numerical or text).
     */
    protected String getCalibrationValue(String line) {
        var matches = Stream.concat(
                        findAllNumberStrings(line).stream(),
                        findAllNumerics(line).stream()
                ).sorted(Comparator.comparingInt(Match::index))
                .toList();

        return "" + matches.getFirst().value() + matches.getLast().value();
    }

    /**
     * Find all the strings of written numbers (e.g. "one")
     *
     * @return List of Matches
     */
    private List findAllNumberStrings(String line) {
        return IntStream.range(0, line.length())
                .boxed()
                .map(i -> findAMatchAtIndex(line, i))
                .filter(Optional::isPresent)
                .map(Optional::get)
                .sorted(Comparator.comparingInt(Match::index))
                .toList();
    }


    private Optional findAMatchAtIndex(String line, int index) {
        return numbers.entrySet().stream()
                .filter(n -> line.indexOf(n.getKey(), index) == index)
                .map(n -> new Match(index, n.getKey(), n.getValue()))
                .findAny();
    }

    /**
     * Find all the strings of digits (e.g. "1")
     *
     * @return List of Matches
     */
    private List findAllNumerics(String line) {
        return IntStream.range(0, line.length())
                .boxed()
                .filter(i -> Character.isDigit(line.charAt(i)))
                .map(i -> new Match(i, null, Integer.parseInt(line.substring(i, i + 1))))
                .toList();
    }

    public static void main(String[] args) {
        System.out.println(new Day1().getCalibrationValue(args));
    }
}

Bill is a liability.

Project Panama is aimed at improving the integration with native code. Not sure when it will be “done”, but changes are coming.

Nice video about it here : https://youtu.be/cZLed1krEEQ

Tldw: US DOS version actually has 2 separate impossible jumps on a level that aren’t present on the European DOS or NES versions.

Yep, absolutely.

In another project, I had some throwaway code, where I used a naive approach that was easy to understand/validate. I assumed I would need to replace it once we made sure it was right because it would be too slow.

Turns out it wasn’t a bottleneck at all. It was my first time using Java streams with relatively large volumes of data (~10k items) and it turned out they were damn fast in this case. I probably could have optimized it to be faster, but for their simplicity and speed, I ended up using them everywhere in that project.

I’ve got so many more stories about bad optimizations. I guess I’ll pick one of those.

There was an infamous (and critical) internal application somewhere I used to work. It took in a ton of data, putting it in the database, and then running a ton of updates to populate various fields and states. It was something like,

• Put all data in x table with batch y.
• Update rows in batch y with condition a, set as type a. (just using letters as placeholders for real states)
• Update rows in batch y that haven’t been updated and have condition b, set as type b.
• Update rows in batch y that haven’t been updated and have condition c, set as type c.
• Update rows in batch y that have condition b and c and condition d, set as type d.
• (Repeat many, many times)

It was an unreadable mess. Trying to debug it was awful. Business rules encoded as a chain of sql updates are incredibly hard to reason about. Like, how did this row end up with that data??

Me and a coworker eventually inherited the mess. Once we deciphered exactly what the rules were and realized they weren’t actually that complicated, we changed the architecture to:

• Pull data row by row (instead of immediately into a database)
• Hydrate the data into a model
• Set up and work with the model based on the business rules we painstakingly reverse engineered (i.e. this row is type b because conditions x,y,z)
• Insert models to database in batches

I don’t remember the exact performance impact, but it wasn’t markedly faster or slower than the previous “fast” SQL-based approach. We found and fixed numerous bugs, and when new issues came up, issues could be fixed in hours rather than days/weeks.

A few words of caution: Don’t assume that building things with a certain tech or architecture will absolutely be “too slow”. Always favor building things in a way that can be understood. Jumping to the wrong tool “because it’s fast” is a terrible idea.

Edit: fixed formatting on Sync

I might be wrong, but the 2nd case looks like an anti pattern, the loop switch sequence .

The last case looks the most readable to me. Always start with that unless there’s a clear reason not to (eg inefficient multiple nested loops).