Part of being in a marching band is memorizing where you need to go on the field and when. We would have a week-long bootcamp before school started where we would drill that and the songs into our heads.

At the time, Google Glass was just coming out. I couldn't help but dream that we could all just put on a pair of those and get real time waypoints like in an FPS. Sure, we'd all look like dorks, but whatever. You play enough Halo, and you'll start to wish you had a HUD too.

Google Glass never took off. I never even got to try it. But recently Facebook launched a similar product, their Pervert Glasses Display.

I had to drive an hour to a BestBuy in New Hampshire to demo them and, if I ever wore them in public, I would be cruisin' for a bruisin'. Still, two things would tempt me.

1. Real-life waypoints. I want a HUD. I want to look off in the sky and see a beacon telling me where I need to go.
2. A real-life dash-cam. I want to be able to go "clip that" and capture the last 60 seconds of whatever I just saw. I see some shit.

But alas, the product sucks.

You cannot make your own apps for the thing, so you are limited to whatever Facebook has made. This includes Instagram, WhatsApp, Facebook, ... all chat apps. Really putting hats on hats.

There is a Maps app, but it just shows a normal map. You could just hold your phone up to your face and get the same experience.

There were some...games? Even the person demoing it said they basically just use theirs as a mic for Discord.

To top it all off, the thing gives me a headache. It is really hard to look at anything on the display part without closing one eye. Add that to all the normal horse excrement like needing to log in, connect with your phone, or the battery not even lasting a full day and yeah. Huge bummer.

The control doohickey that senses your finger movements was legitimately fun though. I would want that as an input device for a lot of things, not that it will be an option.

Maybe SnapChat's Pervert Glasses will be better. I'll have to try a pair before that company dies.

<- Index

But if you want to know more specific info, say "which of my libraries gets the most downloads," they point you to a separate service called "Scarf."

And wow, that is neat. A lot of people use my repackaged guava (which whatever), but actually I get quite a few downloads on my JSON library. Nowhere near Jackson, but I choose to be happy about it. Really wish I could see the rest though.

And it makes sense that most of my users are in the US, but I am taken aback by how much of the globe I've touched.

A bit of a bummer that I only get to see the last 3 months, I wonder if I hit everywhere at least once.

But hey what the fuck is this?

So okay clearly behind the scenes they have some way to guess at which companies are the ones initiating a download for a library. Probably no more complicated than having some known IP addresses of them. That isn't what shocks me.

What shocks me is both that they gate this information and the price they demand for access.

So as whatever user tier I am I get "50 free unlock credits". Meaning of the large corporations that use the libraries I publish I can see exactly 50.

To get 250 unlocks, which isn't even the whole list for me, I would have to pay them $1350 a month.

Well, not really. That is just what they show as the default. I can tune the "runs" number down to 1 and the "company unlocks" to exactly 413 and then it is only $1076.60 a month.

And I could go into all the other pricing options, but I think you get the picture. That's more than a car payment and only a little less than a Github Copilot subscription.

Clearly they are able to gatekeep it. Sonatype sold them IPs of downloads and they have a dataset mapping IPs to companies. Neither of those are public so they get to put a price on it.

But the only reason people would pay a price is that the information has value. If an author knows exactly who is consuming their open source libraries that gives them leverage. They can go to these companies and say "Hey, I am in your supply chain."

If you have been following me the last few months you'll know I have been working on a repository scheme of my own. Making it such that information like "Company A depends on David Smith of Lansing Michigan" is not gatekept has now moved way up my priorities list.

Because fuck this, fuck Scarf.

<- Index

So I had ChatGPT generate that for me.

If your initial reaction to reading that and seeing that is some variation of "ughhh" or rolling your eyes or "fuck this guy" congrats. You are normal.

If it wasn't I cannot stress to you enough that you are an outlier. Whenever you pick key art for a presentation or blog, your business, or whatever - if you use AI art you give a clear signal that you have low social literacy. You immediately associate yourself with a huge bundle of negative emotions because people, largely, hate this shit.

The game theory on this is astoundingly clear. The best case scenario is that your audience doesn't mind. The worst, and common-case, scenario is that they think less of you. Nobody sane looks at that and goes "wow, they must have spent such a long time prompting."

Here are some easy alternatives.

Alternative 1: Lazy photoshop

Here I've taken a photo of a T-Rex from the Jurassic Park Wiki and used https://jspaint.app to very poorly edit on a thumbs up emoji.

I'm sure I could have found a public domain rendering of a dinosaur, but if we cared about intellectual property AI wouldn't be on the table regardless.

And again to stress the point - people will look upon this much more favorably.

Alternative 2: Doodle

This one speaks for itself. Pull out your colored pencils, your markers, your watercolors. Draw something, and take a photo with your phone.

Now I drew this one, but do you comprehend how much it improves people's perception of you if you can say "my 6-year-old niece drew this?" If you have access to a child make use of that.

Alternative 3: Commission Art

I write about software, I post in software spaces. I must assume that some significant fraction of those reading this are software professionals.

Do you have any idea how negatively it reflects on you as a person if you have a six-figure job but won't shell out some cash to a starving artist?

I commissioned https://bsky.app/profile/dsoart.com for this one, and I am more than pleased. You can too. Or any number of relatively affordable professionals.

Alternative 4: Be a grifter

People with minor cases of major brain damage. Those who have drunk too long from the leaden hose of LinkedIn. The kind of person who was really into NFTs in 2022. These people make perfect marks.

Using AI images is an effective way to filter out people with critical thinking skills. If you are running a grift it can be a valuable piece of your toolkit. Much like your classic "Nigerian prince" scams, the kind of people who see that junk and still engage are your most cash of cows.

If that's what you want to do, if that's who you want to be - godspeed, loser.

<- Index

A linked list is either

• An empty list
• A "not empty" list, which has a "head" and a "tail"

In Java we can represent this situation using a "sealed interface."

// A linked list is either empty or not empty.
sealed interface LinkedList<T> 
    permits Empty, NotEmpty {}

record Empty<T>() implements LinkedList<T> {}
record NotEmpty<T>(T first, LinkedList<T> rest) {}

To define operations on a linked list we need to define their operation on the "empty" and "not empty" cases.

The size of an empty list is 0.

int size(LinkedList<?> ll) {
    return switch (ll) {
        case Empty() -> 0;
        ...
    };
}

And the size of a not empty list is 1 + the size of the rest of the list.

int size(LinkedList<?> ll) {
    return switch (ll) {
        case Empty() -> 0;
        case NotEmpty(_, var rest) -> 1 + size(rest);
    };
}

To "map" a function on each element in the list works very similarly.

<T, R> LinkedList<R> map(
        LinkedList<T> ll, 
        Function<? super T, ? extends R> f
) {
    return switch (ll) {
        case Empty() -> new Empty();
        case NotEmpty(var first, var rest) -> new NotEmpty(
                f.apply(first), 
                map(rest, f)
        );
    };
}

As does every operation you might want to define. The recursive structure of the list itself is your guide for implementing operations on it.

Binary Search Trees

A tree is either

• A leaf node, holding no data
• A branch node, holding a value as well as a subtree to its left and right

In Java we can represent this situation using a "sealed interface."

// A tree is either a leaf or a branch.
sealed interface BST<T> 
    permits Leaf, Branch {}

record Leaf<T>() implements BST<T> {}
record Branch<T>(BST<T> left, T value, BST<T> right) {}

To insert a value into a BST we need to be careful to always properly order elements. If a branch has 5 and we try to insert 2 in the tree, the 2 should go to the "left" because it is less than 5.

<T> BST<T> insert(
        BST<T> bst,
        T value,
        Comparator<? super T> comparator
) {
    return switch (bst) {
        case Leaf() -> new Branch(
                new Leaf(),
                value,
                new Leaf()
        );
        case Branch(var left, var v, var right) -> {
            int comparison = comparator.compare(value, v);
            if (comparison == 0) {
                yield bst;
            }
            else if (comparison > 0) {
                yield new Branch(
                        left,
                        v,
                        insert(right, value, comparator)
                );
            }
            else {
                yield new Branch(
                        insert(left, value, comparator),
                        v,
                        right
                );
            }
        }
    };
}

This is the invariant that allows us to quickly search for values in such a structure. At every branch we can ignore at most half of the tree.

<T> boolean contains(
        BST<T> bst,
        T value,
        Comparator<? super T> comparator
) {
    return switch (bst) {
        case Leaf() -> false;
        case Branch(var left, var v, var right) -> {
            int comparison = comparator.compare(value, v);
            if (comparison == 0) {
                yield true;
            }
            else if (comparison > 0) {
                yield contains(
                        left,
                        value,
                        comparator
                );
            }
            else {
                yield contains(
                        right,
                        value,
                        comparator
                );
            }
        }
    };
}

Now compare this explanation and whatever one you - the reader - were given in school. What are your thoughts?

<- Index

Python is the undisputed monarch in exactly one domain: Data Science.

The story, as I understand it, goes something like this:

Python has very straight-forward interop with native code. Because interop is straightforward, libraries like numpy and pandas got made. Around these an entire Data Science ecosystem bloomed.

This in turn gave rise to interactive notebooks with iPython (now "Jupyter"), plotting with Matplotlib, and machine learning with PyTorch and company.

There are other languages and platforms - like R, MATLAB, etc. - which compete for users with Python. If you have a field biologist out there wading through the muck to measure turtles, they will probably make their charts and papers with whatever they learned in school.

But the one glaring weakness of these competitors is that they are not general purpose languages. Python is. This means that Python is also widely used for other kinds of programs - such as HTTP servers.

So for the people who are training machine learning models to do things like classify spam it is easiest to then serve those models using the same language and libraries that were used to produce them. This can be done without much risk because you can assume Python will have things like, say, a Kafka library should you need it. You can't really say the same for MATLAB.

And in the rare circumstance you want to do something that is easiest in one of those alternative ecosystems, Python will have a binding. You can call R with rpy2, MATLAB with another library, Spark with PySpark, and so on.

For something to legitimately be a competitor to Python I think it needs to do two things.

1. Be at least as good at everything as Python.
2. Be better than Python in a way that matters.

The only language which clears this bar is called Clojure.

That's a bold claim, I know. Hear me out.

Clojure has a rich ecosystem of Data Science libraries, including feature complete numpy and pandas equivalents in dtype-next and tech.ml.dataset. metamorph.ml for Machine Learning pipelines, Tableplot for plotting, and Clay for interactive notebooks.

For what isn't covered it can call Python directly via libpython-clj, R via ClojisR, and so on.

Clojure is also a general purpose language. Making HTTP servers or whatever else in Clojure is very practical.

What starts to give Clojure the edge is also the answer to the age-old question: "Why is Python so slow?"

Python is slow because it cannot be made fast. The dark side of Python's easy interop with native code is that many of the implementation details of CPython were made visible to, and relied upon by, authors of native bindings.

Because all these details were relied upon, the authors of the CPython runtime can't really change those details and not break the entire Data Science ecosystem. This heavily constrains the optimizations that the CPython runtime can do.

This means that people need to constantly avoid writing CPU intensive code in Python. It is orders of magnitude faster to use something which delegates to the native world than something written in pure Python. This affects the experience of things like numpy and pandas. There is often a "fast way" to do something and several "slow ways." The slow ways are always when too much actual Python code gets involved in the work.

Clojure does not have this problem. Clojure is a language that runs on the Java Virtual Machine. The JVM can optimize code like crazy on account of all the souls sacrificed to it. So you can write real logic in Clojure no issue.

There's a reason Python's list is implemented in C code but Java can have multiple competing implementations, all written in Java. Java code can count on some aggressive runtime optimizations when it matters.

This also means that if you use Clojure for something like an HTTP Server to serve a model, you can generally expect much better performance at scale than the equivalent in Python. You could even write that part in pure Java to make use of that trained pool of developers. Anecdotally, startups often switch from whatever language they started with to something that runs on the JVM once they get big enough to care about performance.

Clojure's library ecosystem includes many high quality libraries written in Java. Many of these are better performing than their Python analogues. Many also do things for which Python has no equivalent. Clojure then gets access to all Python libraries via libpython-clj.

Clojure's interop story is also quite strong at the language level. Calling a Python function is almost as little friction linguistically as calling a Clojure function. Calling native code with coffi is also pretty darn simple.

The language is also very small even compared to Python. Obviously the education system infrastructure is not in place, but in principle there is less to learn about the language itself before one can productively learn how to do Data Science.

An extremely important part of productive Data Science work is interacting with a dataset. This is why interactive notebooks are such a big part of this world. It's also a benefit of using dynamic languages like Python and Clojure. Being able to run quick experiments and poke at data is more important than static type information.

Clojure is part of a family of languages with a unique method of interactive development. This method is considered by its fans to be superior to the cell-based notebooks that Jupyter provides.

All in all, it's a competitive package. Whether it ever gets big enough to take a big bite of Python comes down to kismet, but I think it's the only thing that might stand a chance to.

If this got you interested in learning Clojure check out Clojure Camp for resources and noj for a cohesive introduction to the Data Science ecosystem.

<- Index

public class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        System.out.print("What is your name? ");
        String name = scanner.nextLine();
        System.out.println("Hello, " + name);
    }
}

This is.

void main() {
    var name = IO.readln("What is your name? ");
    IO.println("Hello, " + name);
}

Good Fucking Riddance.

I'll be nuanced later, we've all earned some catharsis now.

Holy fucking shit did this suck¹. There is a comments section below. Give your eulogy for that piece of shit sorcerous incantation there or wherever else.

new Scanner(System.in) and System.out.println too. Don't let your sense of dignity hold you back.

Just record yourself giving a guttural scream and post it. Sing a song, do a dance, cast aspersions.

Honestly just let it all out.

1: When I was a Freshman in High School I asked a Junior what it meant. He had no clue.

That Junior later went on to drop out of college and become a Minecraft Youtuber. I vividly remember him making videos where he and his girlfriend pretend to be toddlers in a Minecraft day-care. What a life.

<- Index

Take the definition of k_means from scikit-learn for example.

def k_means(
    X,
    n_clusters,
    *,
    sample_weight=None,
    init="k-means++",
    n_init="auto",
    max_iter=300,
    verbose=False,
    tol=1e-4,
    random_state=None,
    copy_x=True,
    algorithm="lloyd",
    return_n_iter=False,
):
    # ...

It takes two arguments positionally and then has a very large number of optional arguments which have default values.

If a caller wants to only change the max_iter parameter they do not need to specify the others

k_means(X, n_clusters, max_iter=10000)

Java does not (yet) have this or an equivalent as a language feature. Not only can you not specify parameters by name, you cannot get default values for said parameters easily

// This is unideal for multiple reasons
k_means(
    X,
    n_clusters,
    null,
    "k-means++",
    "auto",
    300,
    false,
    1e-4,
    null,
    true,
    "lloyd",
    false
);

There are many strategies for coping with this. The most notable is using the builder pattern to make an "input object".

var input = KMeansInput.builder(X, n_clusters).maxIter(10000).build(); 
var o = k_means(input);

This requires you to make both a class that holds all the input values in addition to an intermediate mutable class which holds all the same values.

public final class KMeansInput {
    private final Object X;
    private final int nClusters;
    private final Double sampleWeight;
    // ... Need to have all the data here
    
    private KMeansInput(Builder builder) {
        // copy from and potentially validate what is in the builder;
    }
    
    public static Builder builder(Object x, int nClusters) {
        return new Builder(x, nClusters);
    }
    
    public static final class Builder {
        private final Object X;
        private final int nClusters;
        private Double sampleWeight = null;
        // ... AND all the data here
        
        private Builder(Object x, int nClusters) {
            this.X = x;
            this.nClusters = nClusters;
        }
        
        // Then mutating methods
        public Builder sampleWeight(double sampleWeight) {
            this.sampleWeight = sampleWeight;
            return this;
        }
        
        // ...
        
        // and a build()
        public KMeansInput build() {
            return new KMeansInput(this);
        }
    }
}

And all of that is a non-trivial amount of boilerplate.

Of course you could just have a public class with all the fields exposed.

public class KMeansInput {
    public final Object X;
    public final int nClusters;
    public Double sampleWeight = null;
    // ...
    public int maxIter = 300;
    // ...

    public KMeansInput(Object x, int nClusters) {
        this.X = x;
        this.nClusters = nClusters;
    }
}

Since setting a field value puts the name of that field on the page, this also works as an approximation of named arguments.

var input = new KMeansInput(X, n_clusters);
input.maxIter = 10000; 
var o = k_means(input);

But there are two major downsides here. One is that you have a mutable object now and those are hard to reason about. You don't really know if k_means will mutate its "input object" or not.

var input = new KMeansInput(X, n_clusters);
input.maxIter = 10000; 
// All is well for the first call
var o1 = k_means(input);
// But this second call is dodgey
var o2 = k_means(input);

The other is the classic "there is no way to evolve a call to a field in a binary compatible way" issue.

If you wanted to make sure maxIter is never negative but still want a mutable aggregate, here come the getters and setters.

var input = new KMeansInput(X, n_clusters);
input.setMaxIter(10000); 
var o = k_means(input);

But this reintroduces boilerplate.

public class KMeansInput {
    private final Object X;
    
    public Object getX() { return x; }
    
    private final int nClusters;
    
    public int getNClusters() { return nClusters; }
    
    private Double sampleWeight = null;
    
    public Double getSampleWeight() { return sampleWeight; }
    
    public void setSampleWeight(Double sampleWeight) {
        this.sampleWeight = sampleWeight;
    }
    
    // ...
    private int maxIter = 300;
    
    public int getMaxIter() {
        return maxIter;
    }
    
    public void setMaxIter(int maxIter) {
        this.maxIter = maxIter;
    }
    
    // ...

    public KMeansInput(Object x, int nClusters) {
        this.X = x;
        this.nClusters = nClusters;
    }
}

So now not only do you have about a lot of boilerplate, just like the builder approach, but you are stuck with a mutable object in the end.

The next best candidate is records. They work well for getting an immutable aggregate with default values.

public record KMeansInput(
        Object X,
        int nClusters,
        Double sampleWeight,
        String init,
        String nInit,
        int maxIter,
        boolean verbose,
        double tol,
        Object randomState,
        boolean copyX,
        String algorithm,
        boolean returnNIter
) {
    public KMeansInput(Object X, int nClusters) {
        this(
                X, 
                nClusters, 
                null, 
                "k-means++", 
                "auto", 
                300, 
                false, 
                1e-4, 
                null, 
                true, 
                "lloyd", 
                false
        );
    }
}

Downside is that the constructor(s) you make to delegate to the canonical constructor will be fiddly. There aren't any names in that this(...) invocation.

There is also the fact that records expose a pattern matching API that is not currently generally available to all classes. This means that, unlike the Builder -> input object flow, adding new components to an input object record is always a sort of breaking change.

You will eventually be able to use withers to take a fully constructed record, update one part, and recreate the record.

var input = new KMeansInput(X, n_clusters).with {
    maxIter = 10000;  
};

But withers are also still not in the language. You can emulate them by making your own mutable aggregate and using it as a temporary for "reconstruction."

import java.util.function.Consumer;

public record KMeansInput(
        Object X,
        int nClusters,
        Double sampleWeight,
        String init,
        String nInit,
        int maxIter,
        boolean verbose,
        double tol,
        Object randomState,
        boolean copyX,
        String algorithm,
        boolean returnNIter
) {
    public KMeansInput(Object X, int nClusters) {
        this(
                X,
                nClusters,
                null,
                "k-means++",
                "auto",
                300,
                false,
                1e-4,
                null,
                true,
                "lloyd",
                false
        );
    }

    public KMeansInput with(Consumer<MutableKMeansInput> consumer) {
        var mut = new MutableKMeansInput(this);
        consumer.accept(mut);
        return mut.freeze();
    }
}

public final class MutableKMeansInput {
    public Object X;
    public int nClusters;
    public Double sampleWeight;
    public String init;
    public String nInit;
    public int maxIter;
    public boolean verbose;
    public double tol;
    public Object randomState;
    public boolean copyX;
    public String algorithm;
    public boolean returnNIter;
    
    MutableKMeansInput(KMeansInput input) {
        this.X = input.X;
        this.nClusters = input.nClusters;
        // and so on
    }
    
    KMeansInput freeze() {
        return new KMeansInput(X, nClusters, sampleWeight, ...);
    }
    
}

Using this scheme would look something like this.

var input = new KMeansInput(X, nClusters).with(it -> {
    it.maxIter = 10000;
});

You might notice that its somewhat like "builder, but backwards." A builder starts out with a mutable aggregate and later builds a (hopefully) immutable one. A record with this style of wither emulation starts off with an immutable aggregate and uses a temporary mutable aggregate which gets turned into the immutable verson later

Unfortunately this didn't really solve our boilerplate problem. Records once withers are in the language come the closest though. As with all boilerplate a degree of code generation can help a little, so you can reach for recordbuilder or similar.

The last way I can think of is a Java classic. Instead of having a method that takes in arguments, turn the whole process into an object.

class KMeans {
    private final Object X;
    private final int nClusters;
    private Double sampleWeight;
    // ...
    
    public KMeans(Object X, int nClusters) {
        // ...
        // initialize all the defaults
    }
    
    // then setters for all the knobs
    public void setSampleWeight(Double sampleWeight) {
        this.sampleWeight = sampleWeight;
    }
    
    // ...
    
    // and finally the ability to run the algorithm
    public KMeansOutput run() {
        // ...
    }
}

The overall object lifecycle of "make it, tweak it, run it" comes up a lot, but often especially when reading code from Java's early days. I don't have a coherent explanation as to why, but I think at some point this style of code fell out of favor.

var kMeans = new KMeans(X, nClusters);
kMeans.setMaxIter(10000);
var o = kMeans.run();

So of all these options suck in their own ways.

Records with withers has the most potential in my eyes, but its important to remember that this whole process only solves for the situation where most of the parameters are optional and have defaults.

While I'd say rare-ish, its not impossible to end up wanting to make something where all 20 or so parameters should be defined and have no defaults. Named arguments as a general feature could handle that, but it's going to be quite awhile before that is top of anyone's priority list.

Edit: As has been pointed out, you can also pass a callback that operates on a mutable object without necessarily exposing the object to be directly constructed.

kMeans(X, nClusters, opts -> opts.maxIter = 1000);

Same general sorts of tradeoffs between direct fields vs. methods that set exist there.

I don't know why I forget about that one all the time.

Also with the setters you can still do the builder thing where you make then chainable.

new KMeansInput(X, nClusters)
    .setMaxIter(1000)
    .setTol(1e-8);

<- Index

"List all the differences between using an abstract class and using a delegate object when sharing common functionality."

Both let you reuse a method definition

class Adder {
    int add(int x, int y) {
        return x + y;
    }
}

class Composition {
    private Adder a = new Adder();
    
    int add(int x, int y) {
        return a.add(x, y);
    }
}

abstract class Adder {
    int add(int x, int y) {
        return x + y;
    }
}

class Inheritance extends Adder {
    // Implicitly inherits add
}

Composition requires you re-list every method you want to borrow

class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return x - y;
    }

    int mul(int x, int y) {
        return x * y;
    }

    int div(int x, int y) {
        return x / y;
    }
}

class Composition {
    private MathDoer m = new MathDoer();

    int add(int x, int y) {
        return m.add(x, y);
    }

    int sub(int x, int y) {
        return m.sub(x, y);
    }

    int mul(int x, int y) {
        return m.mul(x, y);
    }

    int div(int x, int y) {
        return m.div(x, y);
    }
}

abstract class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return x - y;
    }

    int mul(int x, int y) {
        return x * y;
    }

    int div(int x, int y) {
        return x / y;
    }
}

class Inheritance extends Adder {
    // Implicitly inherits add, sub, mul, and div
}

Inheritance can lead to observing otherwise hidden method relationships

abstract class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

class Inheritance extends Adder {
    // Will print for both add and sub
    // but brittle if sub is ever redefined
    // to be "return x - y;"
    int add(int x, int y) {
        IO.println("Add called. x=" + x + ", y=" + y);
        return super.add(x, y);
    }
}

class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

class Composition {
    private MathDoer m = new MathDoer();

    // Resilient to whatever internal relationships
    // add and sub have within MathDoer
    int add(int x, int y) {
        IO.println("Add called. x=" + x + ", y=" + y);
        return m.add(x, y);
    }

    int sub(int x, int y) {
        IO.println("Sub called. x=" + x + ", y=" + y);
        return m.sub(x, y);
    }
}

Inheritance implicitly gives polymorphic dispatch for all exposed methods

abstract class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return x - y;
    }
}

class Inheritance extends MathDoer {
    int add(int x, int y) {
        IO.println("Add called. x=" + x + ", y=" + y);
        return super.add(x, y);
    }
}

void main() {
    MathDoer m = new Inheritance();
    IO.println(m.add(1, 2));
}

// To get dynamic dispatch you need an intermediate interface
interface IMathDoer {
    int add(int x, int y);
    int sub(int x, int y);
}

// This in turn means methods must be public.
//
// If you want "package-private" dynamic dispatch you
// are out of luck.
class MathDoer implements IMathDoer {
    public int add(int x, int y) {
        return x + y;
    }

    public int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

class Composition implements IMathDoer {
    private MathDoer m = new MathDoer();
    
    public int add(int x, int y) {
        return m.add(x, y);
    }

    public int sub(int x, int y) {
        return m.sub(x, y);
    }
}

void main() {
    IMathDoer m = new Composition();
    IO.println(m.add(1, 2));
}

You can compose behavior from multiple objects. Inheritance is linear

abstract class Adder {
    int add(int x, int y) {
        return x + y;
    }
}

abstract class Subber {
    int sub(int x, int y) {
        return x - y;
    }
}

class Inheritance extends Adder { // Cannot also extend Subber
    
}

class Adder {
    int add(int x, int y) {
        return x + y;
    }
}

class Subber {
    int sub(int x, int y) {
        return x - y;
    }
}

class Composition {
    private Adder a = new Adder();
    private Subber s = new Subber();

    // Resilient to whatever internal relationships
    // add and sub have within MathDoer
    int add(int x, int y) {
        return a.add(x, y);
    }

    int sub(int x, int y) {
        s.sub(x, y);
    }
}

Inheritance lets you define protected members which are public only to classes in the same package and extenders

package a;

abstract class MathDoer {
    protected abstract int addInternal(int x, int y);
    
    public final int add(int x, int y) {
        return addInternal(x, y);
    }

    public final int sub(int x, int y) {
        return addInternal(x, mul(y, -1));
    }
}

package b;

// If extending the class, can see addInternal 
// despite being in a different package
class Inheritance extends MathDoer {
    protected int addInternal(int x, int y) {
        return x + y;
    }
}

package a;

// No way to define a method or field that will
// be visible across package boundaries only to things
// that are "composing".
final class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

Inheritance requires you directly expose constructors

abstract class MathDoer {
    // Subclasses need to call a super-class constructor
    MathDoer() {}
    
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

class Inheritance extends Adder {
    Inhertiance() {
        super();
    }
}

class MathDoer {
    private MathDoer() {}
    
    public static MathDoer getIt() {
        return new MathDoer();
    }
    
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
}

class Composition {
    // Meanwhile composition can allow you to keep constructors hidden
    // and only expose static factories or builders.
    private MathDoer m = MathDoer.getIt();
    
    int add(int x, int y) {
        return m.add(x, y);
    }

    int sub(int x, int y) {
        return m.sub(x, y);
    }
}

Inheritance leaves you exposed to new methods with incompatible signatures

abstract class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }
    
    // int mul(int x, int y) {
    //     return x * y;
    // }
}

class Inheritance extends Adder {
    double mul(int x, int y) {
        // This is fine initially, but poses a problem 
        // if an incompatible method is added to the superclass later
        return ((double) x * y);
    }
}

class MathDoer {
    int add(int x, int y) {
        return x + y;
    }

    int sub(int x, int y) {
        return add(x, -1 * y);
    }

    int mul(int x, int y) {
        return x * y;
    }
}

class Composition {
    private MathDoer m = new MathDoer();

    // Resilient to whatever internal relationships
    // add and sub have within MathDoer
    int add(int x, int y) {
        return m.add(x, y);
    }

    int sub(int x, int y) {
        return m.sub(x, y);
    }

    // Any methods not taken via composition
    // do not pose a problem.
    //
    // A caveat is that this is an issue
    // with interfaces as well, so its more a property
    // of polymorphic dispatch
    double mul(int x, int y) {
        return ((double) x * y);
    }
}

Once I am able to cohere my thoughts without foaming at the mouth and twitching, expect a rant on "mechanics-ism."

<- Index

This is patently ridiculous. To understand why you need to understand a little basic kindergarten level economics.

The Lemonade Stand

Imagine a lemonade stand run by three plucky 12-year-olds. Call them Ed, Edd, and Eddy.

Each day of operation for this lemonade stand will both cost money to run and bring in money from sales. These costs are expenses and the money brought in is revenue.

Subtract expenses from revenue, and you get the total profit (or loss) for that day of operations.

Say they sell $10 worth of lemonade and the cost of sugar, lemon, and water totals up to $6. For that day they will have made $4 in profit.

Startup Costs

Businesses have all sorts of expenses.

We can simplify these broadly into one-time expenses (like the lumber to make the booth) and recurring expenses (like the materials to make the lemonade.)

One-time expenses needed for the business to begin operations are called "startup costs."

Since the business is not yet running - at least not at full capacity - the funds to cover these startup costs needs to come from somewhere else. For a lemonade stand this is likely a parent of one of the children. This, depending on the preferred child-rearing strategy, can make that parent an "investor."

So if it costs $20 to get all the supplies for the first day of operations, how long until the lemonade stand can repay their startup costs?

Unit Economics

It is generally understood that the more customers a business has the more money it makes.

To know exactly how much money to expect you need to understand the "unit economics" of the business. This is just the amount made per unit of product sold.

So if you sell 1 cup of lemonade for $1.00, and it took $0.50 to make, you will profit $0.50 per cup of lemonade sold.

This means that once you sell 40 cups of lemonade you will have made back the initial $20 investment.

Economies of Scale

Unfortunately sugar and lemons are not sold in clean "amount needed for a cup of lemonade" increments.

If you buy a small bag of sugar it might cost $5 but contain enough sugar for 20 cups of lemonade. If, however, you buy a large bag of sugar it might cost $100 but contain enough sugar for 1000 cups of lemonade.

This is what people mean by "economies of scale." If you can expect to sell more than 1000 cups of lemonade you can make your per-unit cost go down by buying the larger bag of sugar. If you aren't yet selling that much lemonade you might need to make do with the smaller bag.

Subsidies

It is always possible for a business to run at a loss. There are two broad reasons for this.

First is that it might not yet be profitable. It takes time for customers to discover and use your lemonade stand. For a period of time you might be stuck buying small bags of sugar. If you actually priced your product so that you make a profit-per-unit you might never get enough customers to "activate economies of scale."

Second is that it might never be profitable.

In both situations a business needs to be subsidized. This means that cash needs to be continuously injected to keep operations afloat.

Investors generally do this because they believe that, with enough time in the proverbial oven, the business can become profitable. One way that can happen is that the aforementioned "economies of scale" can drive down per-unit costs.

The other is "market capture." If you pour enough money into a lemonade stand that it can open branches on literally every street corner you can prevent new lemonade stands from opening. Being the only option in town for lemonade means you can jack up the price to become profitable. This has some limits - you can't make lemonade $2000 and expect anyone to be able or willing to afford that - but monopolies and oligopolies are almost the ideal state for a business.

If a business will never become profitable investors still might subsidize it. Lemonade stands are often used to teach children life lessons, not to become profitable. For this reason a parental investor might contribute money that they never expect to make back. The thing they are purchasing is not future returns but instead the existence of the lemonade stand itself.

With a particularly affluent parent a modest lemonade stand can be kept in operation almost indefinitely, even if they sell the lemonade for free.

Anthropic

Anthropic, a major AI company, loses money on every active user. This is because they charge people a monthly rate, and it costs multiple times that monthly rate to provide them the product they paid for.

The numbers aren't fully known, but it seems safe to say that for everyone who pays for and uses their platform they probably lose at least ~3x what that person paid them. The more someone uses their AI the faster they lose money.

There aren't any economies of scale left for them to activate. They are already plenty big and the GPUs they bought are expensive. But the more expensive part is actually running them. The costs of doing that aren't going to go down any time soon and actually increase the more usage they see.

They also can't make up the difference by capturing the market. Their users are costing them multiple thousands of dollars and only paying them at most a few hundred. Not enough people will drop a mortgage payment on AI to make up the difference.

Anthropic is just one AI company, but the broad math seems to be the same for all of them.

Why this still works

But here's the part that critics don't understand.

People aren't investing in AI companies to make a profit. It's clear these companies will never be profitable and, because the market famously is never irrational, investors must be taking this into account.

Instead, these companies are kept healthy and thriving by "parental investors." Just like how a lemonade stand keeps a kid occupied on the weekend and out of trouble, generative AI companies keep a large number of business and tech brothers off the streets. You'd much rather have then doing ZYNs and Addies in a safe office setting where they can chill with their homies and learn valuable life skills.

These investors have, from my perspective, almost infinite money. It only makes sense that they will be able to keep investing that infinite money forever, regardless of how much money the AI companies lose.

The future is bright and this economy - our economy - is invincible.

<- Index

I've written about some of these issues before, but now I have a project I can use as an example.

Stick around to the end for an open challenge to the audience.

Context

Yu-Gi-Oh is a children's card game from Japan. Each player has "life points" and the goal of the game is to use your monsters, spells, and traps to reduce your opponent's life points to zero.

This game is how I first learned to read.

My Father likes playing a Yu-Gi-Oh game from the early 2000s called "Power of Chaos: Yugi the Destiny," named after the character in the anime who solves a puzzle and gets possessed by the spirit of an ancient Egyptian Pharaoh.

Since he figured out it supports multiplayer and can let me play against him, he has also started playing "Power of Chaos: Joey the Passion." This is also from the early 2000s and is named after the character in the anime who is a Japanese high school student that for some reason speaks with a Brooklyn accent.

Every now and then a character will die because they lost this children's card game. This got censored as them being "sent to the shadow realm," a place of eternal torture where their soul will never know peace. Much more kid friendly.

In my opinion the "Power of Chaos" series of games have by far the best visual, audio, and interaction design of any Yu-Gi-Oh game. This includes unofficial fan projects.

So something I threw on my large list of back-burner projects is to make my own Yu-Gi-Oh game that closely emulates the design of those early games.

Unfortunately the actual card game is crazy complicated. Every card is basically its own tiny program and there are decades of special case rulings to implement. It is well beyond the scope of what I am capable of as an individual.

Fortunately there is both a crowdsourced repository of lua scripts for all the cards and a community maintained engine for simulating the rules of the game. This engine has a relatively minimal C API and is, I think, a perfect example of the kind of thing that should have bindings written for it. The depth of expertise that went into it is unrepeatable.

Problem 1: C libraries aren't always pure C

Despite having a C API some of the headers of this particular library made use of C++ features. This is often ignorable in the C/C++ world since the major C compilers also support C++. It is not ignorable when you use jextract to generate bindings. jextract only supports C.

You could interpret this as a one-off, but my suspicion is that it's a problem that will naturally recur for libraries written in C++ that expose a C API. Especially if they are never tested in this context.

The solutions are to either make issues/open PRs or to enhance jextract to be able to support a limited subset of C++. Despite the words "limited subset" the latter is likely a nightmare pit of a task, so you should be ready to do the first.

Problem 2: You need different Java code per-platform

jextract takes as input a C header file and spits out a folder of Java classes. These classes include information about available functions as well as the memory layouts of defined structs. Unfortunately C is a protocol where memory layouts can change based on both the target operating system and the underlying CPU architecture.

This means you need different Java code for macos-aarch64 than you do for windows-x86. Pop-quiz: how do you do this in Maven? In Gradle?

You also need access to the target platform to generate this code. jextract doesn't have the zig cc magic that lets it compile for any platform from any platform. So you are left with having to use services like Github Actions.

In the absolute best case scenario you can just swap out a source set when compiling. OCG_CardData might have a platform specific layout, but the generated methods and struct members will be the same.

If you want to have one library support all platforms you'll need to contrive a system for selecting methods to call at runtime. This can lead to some pointless duplication.

Problem 3: C libraries are often special snowflakes

Question: what is the Maven Central for C?

Answer: ha. hahaha. ha. ha. ha. ha.

While there are things like Conan and vcpkg out in the world it's far from a given that any particular library you'd want is on them.

Its likely you'll end up either adding a GitHub repo as a submodule or writing a script to download the repo or some random .zip/.tar.gz file.

From there every C library has its own build instructions and flags you may or may not need to pass.

Pop-quiz: how do you do this in Maven? In Gradle?

Problem 4: You need to figure out packaging

From here we'll assume that the C library you are binding is going into a library. Either to be shared with the wider world or to be one module in a larger project tree.

Firstly, you probably need to make one artifact per target platform. In Maven repositories the way people share such artifacts is with a classifier scheme. Each artifact should be published with a -macos-aarch64 or similar classifier and modules depending on these libraries need to select the right one.

Then for the actual .dll/.so/.dylib that is the compiled artifact for the C library you have a few options.

1. Expect the user to just have it on their machine already or install it separately.
2. Expect the user to provide it manually with -Dsystem.library.path.
3. Package that file into a jar and extract it dynamically at runtime.
4. Package your code as a .jmod and expect that to be usable.

Option 1 sucks for obvious reasons.

Option 2 is just option 1 but without it needing to be a global system-level thing. Tools like Maven are, best I can tell, built around the concept that a "Set of Dependencies" should become a --class-path. You can't really have C shared libraries as automatically resolved dependencies.

Option 3 is what most libraries do today. LWJGL has "natives" jars which contain the actual shared libraries. It then uses a shim to extract the shared libraries to the filesystem. This is annoying firstly because its finicky code. Extracting a file atomically to the filesystem is a whole thing. It also requires that you are deploying code in a context where you have a writable filesystem. This is not always the case.

But most importantly it annoys me because it is so clearly a forced move. If you could actually just put the shared library on the -Dsystem.library.path automatically in the same way other dependencies are automatically put on the --class-path I don't think people would be doing it. Well, that and if people weren't universally using uberjars as their deployment mechanism.

Option 4 I think has potential. It's what I've done for the Yu-Gi-Oh bindings. For those unaware, .jmod files have delineated locations for classes, legal metadata, configuration files, and shared libraries. This is how the JDK bundles the shared libraries needed for making things like Swing work.

One problem is that .jmods aren't usable at runtime. You need to link them together with jlink to produce a JDK then use that JDK. You can technically extract the contents of a .jmod and put the extracted classes folder on the --module-path and libs on the -Dsystem.library.path.

Pop-quiz: how do you do that in Maven? In Gradle?

Problem 5: Nobody uses the --module-path

In discussions about the --module-path the focus tends to be on one of three aspects.

1. I heard a friend of a cousin say it broke a library nearly a decade ago in Java 9.
2. It was needed to turn off deep reflection for JDK internals.
3. Wow, tooling does not support this well at all.

The 3rd aspect is most relevant here because you can't really expect anyone using your library to have put it on the --module-path. This is unfortunate because modules are the only mechanism to group up and hide whole packages from external consumers.

jextract will generate a large number of public classes which contain calls to fundamentally unsafe APIs. Not only that, unless you go through and manually allowlist functions and symbols with --include-function et al. it will contain a lot of stray functions you may or may not be using in your actual binding code.

What you would ideally want is to just not export those autogenerated classes and only export the code you wrote that wraps them up. This would be needed for someone writing --enable-native-access=your.specific.module to mean "I have audited or otherwise trust the producer of this module to have interacted with the native world in a way that won't crash the JVM."

This is in contrast to --enable-native-access=ALL-UNNAMED and "yeah whatever, just let me use native stuff. Who cares where it comes from."

Even if you don't particularly care about that story, autogenerated bindings don't make for the world's best public API.

Challenges

So with that prelude, here is the challenge for the audience.

1. Using your build tool of choice (Maven, Gradle, bld, Mill, etc.) replace the Justfile I have to build the project. I mean replace, not do a different or worse job. Produce as a final artifact a .jmod, procure the C library, run jextract, include the proper legal metadata, etc.

2. Put it in a local maven repository and use it from a Maven project. Good luck.

3. Bonus points, actually work on the unfinished binding code. Would be appreciated, but it's also my burden to bear and not super relevant to the rest of this post.

<- Index

The reason I focus so much on specifically Java education is because it is often the first language people are taught. This matters for a lot of reasons, not all of which I have the page space to get in to, but crucially being taught first has a direct impact on a language's popularity.

I'm writing this because I think Clojure now has a real shot at becoming a first language.

Why

Of all the less-than-massively-popular-languages out there, Clojure is probably hurt the least by not having widespread adoption. This is in large part because it gets to piggyback on existing libraries and ecosystems.

Clojure is a hosted language. Clojure on the JVM can use any Java library, Clojure in the browser can use any JavaScript library, and so on. It is always good when Clojure-native libraries get written, but they've never been an absolute necessity.

So why pursue popularity?

1. Paper Clipping.

A lawyer has a duty to be a zealous advocate for their client. There's a non-trivial tribal monkey aspect to wanting your programming language to be popular and, at a certain point, pursuing that end has no fundamental justification.

But we make our own meaning in life so screw it.

2. It's Better.

The value proposition of Clojure is different to most other languages. I'm not going to s*** Paul Graham's d*** or wax poetic about macros, but it's hard to deny that Clojure codebases tend to be quite different to those written in Python, JavaScript, Java, R, etc.

There are reasons to think that Clojure could be a better fit for producing certain genres of software. Popularity would therefore lead to "better" software being produced, which is reasonable to want.

I'm being vague on purpose here. The difference between closed and open aggregates alone could be its own essay.

3. Money.

The more people who use Clojure the more Clojure jobs there are. The more Clojure jobs there are the more secure Clojure experts can be, etc.

TypedClojure is a one-man-show. TypeScript is funded by Microsoft paychecks. Popularity opens the door to all sorts of support.

How

So to become popular you need to be someone's first language. To be someone's first language you need to be what they learned in school. This means convincing teachers and curriculum makers.

For CS education I think this is a lost cause. There are very well-made CS 101 courses that use lisps and face cosmically stupid pushback for doing so. It is hard to imagine winning that fight.

But people going for Computer Science degrees aren't the only people who program. When my brother got his Masters in Marine Biology he was taught R. Analyzing data, making charts, etc. is needed for a wide variety of fields.

I think Clojure could steal significant market share here.

Noj is a collection of a bunch of data science libraries for Clojure. With what is in there you can:

• Load data into data frames
• Make visualizations
• Train ML models (including deep learning)
• Do anything Python can do (by directly calling Python libraries)
• Do anything R can do (by directly calling R libraries)
• Do anything Wolfram can do (by directly calling Worlfram)
• ... and more

This has the makings of an extremely compelling pitch.

The biggest missing piece, as I see it, is resources tailored to people learning Clojure as a first language.

Historically the vast majority of Clojure programmers have been transplants from other languages. We have books like Clojure for the Brave and True that serve this crowd, but few-to-none for people who are starting truly from scratch.

This has also affected the way people talk about Clojure. Keep in mind that you don't need to convince people of functional programming, homoiconicity, or anything else when it's the first thing they learn. The pitches you'd use to pull in a Ruby programmer should be kept in their lane.

So that's the gap. The data science people are presumably going to keep chugging away at the things they do. If you are interested in making Clojure a "First Language" give a shot at making something that fills that gap.

<- Index

It offers a way to represent a potentially missing piece of information. If your method might not produce a result you can use an empty Optional to represent that.

Optional<LocalDate> birthday(String name) {
    return switch (name) {
        case "Mr. Rodgers" -> 
                Optional.of(LocalDate.of(1928, Month.MARCH, 20));
        case "Mr. T" -> 
                Optional.of(LocalDate.of(1952, Month.MAY, 21));
        default -> 
                Optional.empty();
    };
}

void main() {
    for (var name : List.of("Mr. T", "H.R. Puffinstuff")) {
        IO.println(name + ": " + birthday(name));
    }
}

This has a few pros over the other standard option of returning null.

For one, Java's type system (currently) does not track null values as part of a type. This means that a programmer needs to infer nullability from written documentation and context clues.

LocalDate birthday(String name) {
    return switch (name) {
        case "Mr. Rodgers" -> 
                LocalDate.of(1928, Month.MARCH, 20);
        case "Mr. T" -> 
                LocalDate.of(1952, Month.MAY, 21);
        default -> 
                null;
    };
}

void main() {
    for (var name : List.of("Mr. T", "H.R. Puffinstuff")) {
        // .getMonth() is not always valid to call
        IO.println(name + ": " + birthday(name).getMonth());
    }
}

This is mitigated somewhat when an API makes use of nullability annotations. Today that requires you to use special null-aware tooling but null-aware types are slated to come to Java proper at some point.

// LocalDate? in the future (probably)
@Nullable LocalDate birthday(String name) {
    return switch (name) {
        case "Mr. Rodgers" -> 
                LocalDate.of(1928, Month.MARCH, 20);
        case "Mr. T" -> 
                LocalDate.of(1952, Month.MAY, 21);
        default -> 
                null;
    };
}

void main() {
    for (var name : List.of("Mr. T", "H.R. Puffinstuff")) {
        // Tooling should catch this mistake
        IO.println(name + ": " + birthday(name).getMonth());
    }
}

But null values in Java always require explicit checks to handle.

if (v == null) {
    // ...
}

// or

v == null ? ... : ...;

// or Objects.requireNonNullElse(v, ...)
// but that's just a method

This makes them ill-suited to the task Optional was originally introduced for - being part of the customary chain of method calls that form stream operations. This is most important when an Optional appears in the middle of a stack of such operations, but even when the Optional handling is at the end it's at least aesthetic.

Stream.of(1, 2, 3)
    .filter(x -> x < 2)
    .findFirst() // Here is where we get an optional
    .orElse(0); // And we can preserve the method chain stack 

People are far more likely to remember to write the above when Java forces them to. That's the point of it.

Integer first = Stream.of(1, 2, 3)
    .filter(x -> x < 2)
    .findFirst(); 
// Not forced to handle null usually and it's aesthetically
// inconvenient. This leads to mistakes in the context of chained methods.
if (first == null) {
    first = 0;
}

But because it "solves null" (it doesn't) it sees a lot of use. A very common pattern has been for folks to take a null returning method and refactor it to use optional instead.

When this works its generally fine, what isn't fine is how callsites are often adapted.

User user = findUserById(id);
if (user != null) {
    // Logic
}

The code above is often turned into something like the following.

Optional<User> userOpt = findUserById(id);
if (userOpt.isPresent()) {
    User user = userOpt.get(); // or .orElseThrow() if civilized
    // Logic
}

Callsites refactored like this are strictly worse. Often an extra intermediate variable needs to be created, that intermediate has a stupid name, and static analysis tools will either not know what is happening or have special carve out exceptions so they know "when .isPresent(), .get() is okay."

Those carve out exceptions may or may not also apply to other ecosystem Optional types.

// It's hard to argue that java.util.Optional really deserves
// special treatment over vavr's Option, but because code like
// this exists it's going to get it.
Option<User> userOpt = findUserById(id);
if (userOpt.isDefined()) {
    User user = userOpt.get();
    // Logic
}

And the general sort of advice to deal with this is to use .map and .ifPresent - the methods that let you work with the value in an Optional without "unboxing" it.

findUserById(id).ifPresent(user -> {
    // Logic
});

// or keep chaining and deal with it later

findUserById(id).map(User::email);

When this works, it can be better. It just stops working when the code you want to run that involves the value might throw a checked exception - .ifPresent and friends cannot cope with that.

findUserById(id).ifPresent(user -> {
    // Logic
    if (...) {
        // Difficult to know what to do.
        // Do we wrap the exception?
        callRemoteAPI();  
    }
    // Logic
});

It also stops working when you have multiple Optionals, at least from a readability perspective.

findUserById(idA).ifPresent(userA -> {
    findUserById(idB).ifPresent(userB -> {
        findUserById(idC).ifPresent(userC -> {
            // Logic
        }); 
    });
});

And also when you want to mutate some local variables relevant to the rest of the function.

int existingUsers = 0;
findUserById(id).ifPresent(user -> {
    // Logic
    existingUsers++; // Lambda rules - does not work
    // Logic
});

And just in general, beyond the small and clean usages, I think using these methods makes code net worse.

What I suggest, and I think people don't consider specifically because they are viewing Optional as a replacement for null, is to use .orElse(null) and write the rest of the code in the method like normal.

User user = findUserById(id).orElse(null);
if (user != null) {
    // Logic
}

Static analysis tools can eat "local variable known to sometimes be null" for breakfast and there are no problems handling checked exceptions, multiple optionals, or mutating local state. It's a much more seamless refactor.

int existingUsers = 0;

User userA = findUserById(idA).orElse(null);
User userB = findUserById(idB).orElse(null);
User userC = findUserById(idC).orElse(null);
if (userA != null && userB != null && userC != null) {
    // Logic
    existingUsers++;
    if (...) {
        callRemoteAPI();  
    }
    // Logic
}

The fact that it might be null also becomes explicit in the source code at every usage site, which is a strict improvement over the equivalent code with null returning methods.

int existingUsers = 0;

// Back to inferring from context or documentation
User userA = findUserById(idA);
User userB = findUserById(idB);
User userC = findUserById(idC);
if (userA != null && userB != null && userC != null) {
    // Logic
    existingUsers++;
    if (...) {
        callRemoteAPI();  
    }
    // Logic
}

There are more bike sheds to have on Optional, don't get me wrong, I just want to strongly encourage you to reconsider blanket advice to "avoid .isPresent/.get, use .map/.ifPresent" and highlight that .orElse is useful for more than valid default values.

<- Index

The rest of this post is going to follow the example program from this piece of Go Documentation. I'm even going to straight rip a lot of the prose.

My intent is to highlight how you can do spiritually similar things in Java.

The code in this guide, god willing, will work unaltered in Java 25.

Prerequisites

• Java.
• Some Libraries. The repo at the end will have them all in a folder. Java dependency management is a whole adventure, for now just follow along the ride.

Getting Started

Make a new directory for this tutorial and cd into it:

$ mkdir javawiki
$ cd javawiki

Create a file named Wiki.java, open it in your favorite editor, and add the following lines:

void main() {
}

Data Structures

A wiki consists of a series of interconnected pages, each of which has a title and a body (the page content). Here, we define Page as a record with two components representing the title and body.

record Page(String title, byte[] body) {}

The Page record describes how page data will be stored in memory. But what about persistent storage? We can address that by creating a save method on Page:

record Page(String title, byte[] body) {
    void save() throws IOException {
        var filename = title + ".txt";
        Files.write(Path.of(filename), body);
    }
}

The save method throws an IOException to let the application handle it should anything go wrong while writing the file. If all goes well, Page.save() will return without throwing.

In addition to saving pages, we will want to load pages, too:

record Page(String title, byte[] body) {
    void save() throws IOException {
        var filename = title + ".txt";
        Files.write(Path.of(filename), body);
    }

    static Page load(String title) throws IOException {
        var filename = title + ".txt";
        var body = Files.readAllBytes(Path.of(filename));
        return new Page(title, body);
    }
}

The method load constructs the file name from the title parameter, reads the file's contents into a new variable body, and returns a reference to a Page object.

At this point we have a simple data structure and the ability to save to and load from a file. Let's update the main method to test what we've written:

void main() throws IOException {
    var p1 = new Page(
            "TestPage", 
            "This is a sample Page.".getBytes(StandardCharsets.UTF_8)
    );
    p1.save();
    var p2 = Page.load("TestPage");
    IO.println(new String(p2.body, StandardCharsets.UTF_8));
}

After executing this code, a file named TestPage.txt would be created, containing the contents of p1. The file would then be read into p2, and its body component printed to the screen.

You can run the program like this:

$ java Wiki.java

Click here to view the code we've written so far.

Introducing the jdk.httpserver module (an interlude)

Here's a full working example of a simple web server:

import module jdk.httpserver;

void handler(HttpExchange exchange) throws IOException {
    exchange.sendResponseHeaders(200, 0);
    try (var os = exchange.getResponseBody()) {
        os.write(
                "Hi there, I love %s!"
                        .formatted(exchange.getRequestURI().getPath().substring(1))
                        .getBytes(StandardCharsets.UTF_8)
        );
    }
}

void main() throws IOException {
    var server = HttpServer.create(
            new InetSocketAddress(8080),
            0
    );
    server.createContext("/", this::handler);
    server.start();
}

The main method begins with a call to HttpServer.create, which creates an http server that will listen on port 8080. (Don't worry about its second parameter, 0, for now.)

Then server.createContext tells the server to handle all requests to the web root ("/") with handler.

It then calls `server.start(). This method will block until the program is terminated.

If you run this program and access the URL:

http://localhost:8080/monkeys

the program would present a page containing:

Hi there, I love monkeys!

Introducing the dev.mccue.jdk.httpserver module (an interlude within an interlude)

The jdk.httpserver module does not see as widespread use as Go's equivalent. As such, I think there are some ways to improve the API that should be rolled into the standard library at some point.

I put the most important of these - a Body abstraction - into a library. I'm going to ignore how to procure libraries in Java for the moment, but suspend your disbelief in the meantime.

With this library the server example above becomes the following:

import module jdk.httpserver;
import module dev.mccue.jdk.httpserver;

void handler(HttpExchange exchange) throws IOException {
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of("Hi there, I love %s!".formatted(
                    exchange.getRequestURI().getPath().substring(1)
            ))
    );
}

void main() throws IOException {
    var server = HttpServer.create(
            new InetSocketAddress(8080),
            0
    );
    server.createContext("/", this::handler);
    server.start();
}

Using jdk.httpserver to serve wiki pages

Let's create a handler, viewHandler that will allow users to view a wiki page. It will handle URLs prefixed with "/view/".

void viewHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/view/".length());
    var p = Page.load(title);
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of(
                    "<h1>%s</h1><div>%s</div>"
                            .formatted(
                                    p.title, 
                                    new String(p.body, StandardCharsets.UTF_8)
                            )
            )
    );
}

To use this handler, we rewrite our main function to initialize an HttpServer using the viewHandler to handle any requests under the path /view/.

void main() throws IOException {
    var server = HttpServer.create(
            new InetSocketAddress(8080),
            0
    );
    server.createContext("/view/", this::viewHandler);
    server.start();
}

Click here to view the code we've written so far.

Let's create some page data (as test.txt), compile our code, and try serving a wiki page.

Open test.txt file in your editor, and save the string "Hello world" (without quotes) in it.

java --module-path lib --add-modules ALL-MODULE-PATH Wiki.java

With this web server running, a visit to http://localhost:8080/view/test should show a page titled "test" containing the words "Hello world".

Editing Pages

A wiki is not a wiki without the ability to edit pages. Let's create two new handlers: one named editHandler to display an 'edit page' form, and the other named saveHandler to save the data entered via the form.

First, we add them to main():

void main() throws IOException {
    var server = HttpServer.create(
            new InetSocketAddress(8700),
            0
    );
    server.createContext("/view/", this::viewHandler);
    server.createContext("/edit/", this::editHandler);
    server.createContext("/save/", this::saveHandler);
    server.start();
}

The method editHandler loads the page (or, if it doesn't exist, create an empty Page record), and displays an HTML form.

void editHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/edit/".length());
    Page p;
    try {
        p = Page.load(title);
    } catch (NoSuchFileException e) {
        p = new Page(title, new byte[]{});
    }
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of(
                    """
                    <h1>Editing %s</h1>
                    <form action="/save/%s" method="POST">
                        <textarea name="body">%s</textarea><br>
                        <input type="submit" value="Save">
                    </form>
                    """.formatted(
                            p.title,
                            p.title,
                            new String(p.body, StandardCharsets.UTF_8)
                    )
            )
    );
}

This function will work fine, but all that hard-coded HTML is ugly. Of course, there is a better way.

(I mean honestly the bigger issue is XSS vulnerabilities, but whatever. Following along.)

The com.samskivert.jmustache module

com.samskivert.jmustache is a library available in the Java ecosystem. We can use it to keep the HTML in a separate file, allowing us to change the layout of our edit page without modifying the underlying Java code.

First, we must add com.samskivert.jmustache to the list of imports. Again, we are glancing over how you procure libraries for this tutorial.

import module jdk.httpserver;
import module dev.mccue.jdk.httpserver;
import module com.samskivert.jmustache;

Let's create a template file containing the HTML form. Open a new file named edit.html, and add the following lines:

<h1>Editing {{title}}</h1>

<form action="/save/{{title}}" method="POST">
    <div><textarea name="body" rows="20" cols="80">{{body}}</textarea></div>
    <div><input type="submit" value="Save"></div>
</form>

Modify editHandler to use the template, instead of the hard-coded HTML:

void editHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/edit/".length());
    Page p;
    try {
        p = Page.load(title);
    } catch (NoSuchFileException e) {
        p = new Page(title, new byte[]{});
    }
    
    var template = Mustache.compiler()
            .compile(Files.readString(Path.of("edit.html")));
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of(template.execute(Map.of(
                    "title", p.title,
                    "body", new String(p.body, StandardCharsets.UTF_8)
            )))
    );
}

Since we're working with templates now, let's create a template for our viewHandler called view.html:

<h1>{{title}}</h1>

<p>[<a href="/edit/{{title}}">edit</a>]</p>

<div>{{body}}</div>

Modify viewHandler accordingly:

void viewHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/view/".length());
    var p = Page.load(title);
    var template = Mustache.compiler()
            .compile(Files.readString(Path.of("view.html")));
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of(template.execute(Map.of(
                    "title", p.title,
                    "body", new String(p.body, StandardCharsets.UTF_8)
            )))
    );
}

Notice that we've used almost exactly the same templating code in both handlers. Let's remove this duplication by moving the templating code to its own function:

void renderTemplate(
        HttpExchange exchange,
        String tmpl,
        Page p
) throws IOException {
    var template = Mustache.compiler()
            .compile(Files.readString(Path.of(tmpl)));
    HttpExchanges.sendResponse(
            exchange,
            200,
            Body.of(template.execute(Map.of(
                    "title", p.title,
                    "body", new String(p.body, StandardCharsets.UTF_8)
            )))
    );
}

And modify the handlers to use that function:

void viewHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/view/".length());
    var p = Page.load(title);
    renderTemplate(exchange, "view", p);
}

void editHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/edit/".length());
    Page p;
    try {
        p = Page.load(title);
    } catch (NoSuchFileException e) {
        p = new Page(title, new byte[]{});
    }

    renderTemplate(exchange, "edit", p);
}

Click here to view the code we've written so far.

Handling non-existent pages

What if you visit /view/APageThatDoesntExist You'll get no response. This is because Page.load errors. Instead, if the requested Page doesn't exist, it should redirect the client to the edit Page so the content may be created:

void viewHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/view/".length());
    Page p;
    try {
        p = Page.load(title);
    } catch (NoSuchFileException _) {
        exchange.getResponseHeaders()
                .put("Location", List.of("/edit/" + title));
        HttpExchanges.sendResponse(exchange, 302, Body.empty());
        return;
    }
    renderTemplate(exchange, "view", p);
}

To do this we send an HTTP status code of 302 and a include Location header in the response.

Saving pages

The function saveHandler will handle the submission of forms located on the edit pages. To parse the form body we are going to add another library - dev.mccue.urlparameters.

import module dev.mccue.urlparameters;

void saveHandler(HttpExchange exchange) throws IOException {
    var title = exchange.getRequestURI()
            .getPath()
            .substring("/save/".length());
    var body = UrlParameters.parse(
            new String(
                    exchange.getRequestBody().readAllBytes(),
                    StandardCharsets.UTF_8
            )
    ).firstValue("body").orElseThrow();
    var p = new Page(title, body.getBytes(StandardCharsets.UTF_8));
    p.save();
    exchange.getResponseHeaders()
            .put("Location", List.of("/view/" + title));
    HttpExchanges.sendResponse(exchange, 302, Body.empty());
}

Click here to view the code we've written so far.

Etc.

There is more in the Go tutorial, including caching templates, making sure there aren't path traversal vulnerabilities (which, very important!), and some other potpourri.

But the purpose of this is just to illustrate that Java is capable of the same sort of "simple" web development that Go is known for. I'm leaving that stuff (and introducing a proper mux) as exercises for you the reader.

And just as a note: If you dig into the jdk.httpserver module you will see some "for development only" warnings around it. This is because the actual server implementation in the JDK is mostly there to serve the jwebserver tool. (jwebserver is more or less equivalent to Python's http.server) You can seamlessly swap to using a production quality server like Jetty and others by adding the appropriate dependencies.

Tell me all about your past traumas with Java in the comments below.

<- Index

"Groyper" is the term used to describe the followers of Nick Fuentes.

Nick Fuentes is a "Hitlerist," meaning he agrees with specifically the policies of Adolf Hitler. You might also know him as the "Your Body, My Choice" guy.

"Big Balls" is the name of one of the young fascists recruited by DOGE. He gained particular notoriety for being young, very punchable, and having a head turning nickname.

Another DOGE fascist is Gavin Kliger. Gavin Kliger is very much a Groyper.

They are all Groypers.

This is why when DOGE fascist Marko Elez posted "Just for the record, I was racist before it was cool" and "Normalize Indian hate" Elon Musk went out of his way to keep him on the team.

DOGE has announced plans to rewrite the computer systems of the Social Security Administration. The timeline they give for this endeavor is several months.

This will not work out for the people who are dependent on their Social Security checks. The way in which it won't work out is t.b.d., but there are a few possibilities that come to mind.

For one, they are supposedly replacing tens of millions of lines of COBOL. That is an amount of code far beyond anyone's capacity to fully understand, let alone recreate, in a few months.

So best case scenario they miss something. More likely scenario they don't care if they "miss" something. These are fascists. They are predisposed to make things worse on purpose out of condescension, intentional malice, or some other goblin emotion.

Then there is the overarching plot-line of dismantling the social safety net. The template for those sorts of actions tends to be to take over a public service, make it worse, then privatize it as a solution. This would fit that template.

The stated plan is to accomplish this with AI. The practice of using AI to produce large chunks of code has been christened by the venture capital tech space as "Vibe Coding."

Training programs have already sprung up seeking to capitalize on the term, reinforcing the convenient smuggling it gives to obvious negligence.

As was the pattern with Big Data and "Web 3" before it, the programming and tech world seems to have few antibodies to nonsensical claims of future potential. Even skepticism will end up wrapped in the framing of "Well this is obviously the future, but."

Social Security's systems are reportedly currently in COBOL, but the plan is for them to be rewritten into Java.

There would be, in a saner time, reasons for that. Java can run on what we would call "commodity hardware" and there is a statistically younger pool of trained people to pull on to write it. It wouldn't be the first system "modernized" in such a way and doing so could make longer term maintenance simpler in a few ways.

But while COBOL Mainframes have a casual reputation of being relics of the past, they are some of the only systems in the world where you can have leader + follower replication of the results of individual CPU instructions.

IBM, the "Made the Holocaust Possible" company, has an online transaction system called CICS that I have been informed is "nuclear attack resistant." I rest easy believing that, if we ever have the privilege to suffer through a Threads, my bank account will have its correct balance.

Unless they found a well-thought-out plan tucked in the desk of a more competent person they fired, these considerations will not be approached with nuance.

I mean, presuming there is a plan at all. It could just be, intentionally or not, a distraction while they pull out more important copper wiring like the FDIC.

If I'm found dead it wasn't a suicide. If I'm disappeared find and rescue me. Leave comments wherever.

<- Index

There is a set of things that you can do when working with a Postgres database which I have found made my and my coworker's lives much more pleasant. Each one is by itself small, but in aggregate have a noticeable effect.

Use UUID primary keys

UUIDs have downsides

• Truly random UUIDs doesn't sort well (and this has implications for indexes)
• They take up more space than sequential ids (space being your cheapest resource)

But I've found those to be far outweighed by the upsides

• You don't need to coordinate with the database to produce one.
• They are safe to share externally.

CREATE TABLE person(
    id uuid not null default gen_random_uuid() primary key,
    name text not null
)

Give everything created_at and updated_at

It's not a full history, but knowing when a record was created or last changed is a useful breadcrumb when debugging. Its also something you can't retroactively get unless you were recording it.

So just always slap a created_at and updated_at on your tables. You can maintain updated_at automatically with a trigger.

CREATE TABLE person(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    name text not null
);

CREATE FUNCTION set_current_timestamp_updated_at()
    RETURNS TRIGGER AS $$
DECLARE
_new record;
BEGIN
  _new := NEW;
  _new."updated_at" = now();
RETURN _new;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER set_person_updated_at
    BEFORE UPDATE ON person
    FOR EACH ROW
    EXECUTE PROCEDURE set_current_timestamp_updated_at();

You need to create the trigger for each table, but you only need to create the function once.

on update restrict on delete restrict

When you make a foreign key constraint on a table, always mark it with on update restrict on delete restrict.

This makes it so that if you try and delete the referenced row you will get an error. Storage is cheap, recovering data is a nightmare. Better to error than do something like cascade.

CREATE TABLE person(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    name text not null
);

CREATE TABLE pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    name text not null,
    owner_id uuid not null references person(id)
                on update restrict
                on delete restrict
);

Use schemas

By default, every table in Postgres will go into the "public" schema. This is fine, but you are missing out if you don't take advantage of your ability to make new schemas.

Schemas work as namespaces for tables and for any moderate to large app you are going to have a lot of tables. You can do joins and have relationships between tables in different schemas so there isn't much of a downside.

CREATE SCHEMA vet;

CREATE TABLE vet.person(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    name text not null
);

CREATE TABLE vet.pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    name text not null,
    owner_id uuid not null references vet.person(id)
                on update restrict
                on delete restrict
);

Enum Tables

There are a lot of ways to make "enums" in sql. One is to use the actual "enum types," another is to use a check constraint.

The pattern introduced to me by Hasura was enum tables.

Have a table with some text value as a primary key and make columns in other tables reference it with a foreign key.

CREATE TABLE vet.pet_kind(
    value text not null primary key
);

INSERT INTO vet.pet_kind(value)
VALUES ('dog'), ('cat'), ('bird');

CREATE TABLE vet.pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    owner_id uuid not null references vet.person(id)
                on update restrict
                on delete restrict,
    kind text not null references vet.pet_kind(value)
                on update restrict
                on delete restrict
);

This way you can insert into a table to add more allowed values or attach metadata like a comment to explain what each value means.

CREATE TABLE vet.pet_kind(
    value text not null primary key,
    comment text not null default ''
);

INSERT INTO vet.pet_kind(value, comment)
VALUES 
    ('dog', 'A Canine'),
    ('cat', 'A Feline'),
    ('bird', 'A 50 Year Commitment');

CREATE TABLE vet.pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    owner_id uuid not null references vet.person(id)
                on update restrict
                on delete restrict,
    kind text not null references vet.pet_kind(value)
                on update restrict
                on delete restrict
);

Name your tables singularly

This isn't even Postgres specific, just please name your tables using the singular form of a noun.

SELECT * FROM pets might seem nicer than SELECT * FROM pet but the moment you start doing anything more interesting with your queries you will notice that your queries are actually working in terms of individual rows.

SELECT *
FROM pet
-- It's a cruel coincidence that in english an "s"
-- suffix can sometimes work both as a plural
-- and a possessive, but notice how the where clause
-- is asserting a condition about a single row.
WHERE pet.name = 'sally' 

The deeper you dig the more annoying edge cases you'll run into with plural table names. Just name your tables the same as what an individual row in that table represents.

Mechanically name join tables

Sometimes there are sensible names to give "join tables" - tables which form the basis for "many to many" relationships between data - but often there isn't. In those cases don't hesitate to just concatenate the names of the tables you are joining between.

CREATE TABLE vet.person(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now()
);

CREATE TABLE vet.pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now()
);

-- pet_owner would work in this context, but
-- I just want to demonstrate the table_a_table_b naming scheme
CREATE TABLE vet.person_pet(
    id uuid not null default gen_random_uuid() primary key,
    created_at timestamptz not null default now(),
    updated_at timestamptz not null default now(),
    person_id uuid not null references vet.person(id)
                on update restrict
                on delete restrict,
    pet_id uuid not null references vet.pet(id)
                on update restrict
                on delete restrict
);

CREATE UNIQUE INDEX ON vet.person_pet(person_id, pet_id);