In 1968, Edsger Dijkstra published a classic letter which was titled “Go To Statement Considered Harmful”. I think the headline buries the lede, because it’s actually an exhortation to structured programming in general, but it is not incorrect. goto is indeed considered harmful in the letter. Dijkstra’s letter was completely correct. History has bourne him out. He won. He won. Past tense. The winning is over. It has been accomplished.

The Strong Law of Small Numbers states: There aren’t enough small numbers to meet the many demands made of them. What this means is that there are so many more mathematical patterns in the world that involve small numbers than there are small numbers that there will inevitably be coincidences where two completely distinct will share some terms together, but that sharing is essentially false and meaningless. 3Blue1Brown goes over one of the Wikipedia page’s examples of a sequence of terms that reads 1, 2, 4, 8, and 16.

Snorbla the Obviously-Named Science Fiction Alien Maintainer lifted ximir’s snorp away from today’s chemically-encoded daily news dispatch. It was no time to be doom-sniffing ximir’s feed… today was an Auspicious Day. As the Master of the Large Gravitational Array Transmitter, it was ximir’s duty and privilege to press The Button. For the last several lifetimes of the Snorbla family, the two main black holes of the array, spinning just on the cusp of where they would go out of control from loss of energy for maximum amplitude, had been spinning in a direction inline with the plane of the communication array’s target.

In the 21^st century, Wall Street went gaga for subscription revenue.

There are many good reasons for this. Software releases turn out to be a clean example of this, so I’m going to talk about that for simplicity, but it applies to a greater or lesser extent to many other business transactions as well.

Here is something you can try to understand ChatGPT and similar systems better, by looking in to your own brain.

I’m going to write three statements here. I want to you to introspectively examine your own reaction to them. These will not be trick statements; I am not trying to fool you or embarass you, even in your own mind. I am simply going to present these statements to you and I want you to observe your own internal reactions.

A point touched upon in my Interfaces and Nil in Go, or, Don’t Lie to Computers that deserves full expansion is, what exactly does it mean for a value to be valid?

It is something that I think many would consider obvious at first, but if you dig into it… and programming generally does make us dig into things like this… it becomes less obvious.

But if you are one who thinks it’s obvious, riddle me this. I have a string containing the six characters “here's”.

Is it valid?

Apologies for the possible RSS burst. I’ve switched what this blog is hosted on and that often comes with all the RSS readers getting a fresh chunk of posts. I think that finally erases the “this website is undergoing a bit of a refresh” that has been on the homepage of this site for at least 15 years now. Refresh finally accomplished.

Sum types are useful, but they are also an attractive nuisance in object oriented languages. There's a certain type of programmer who gets a taste of functional programming and has a good time, but misinterprets that good time to mean that sum types are always better, because they are FP, and FP is Better.

(If you'd like my full opinion on functional programming in object-oriented languages, see my Functional Programming Lessons in Imperative Code BlogBook. See that BlogBook also if you want to rip into me about my opinions of FP expressed in this post.)

But sum types are not generally better, they are specifically better. Using sum types, or even forcing sum types into languages that don't really have them like C, is a valid solution for certain problems, but in most cases they are not the best choice.

To understand when sum types are best, you must understand something called...

I've said a few times on Hacker News over the years that I don't think you can have a single shell language that covers the interactive and programmatic use cases, but I have not yet talked through it enough to myself to crystallize the point. I think I have it now. Interactive shell usage is optimized for the fact that a human will be examining the state of the world after every shell command.

Title is literally true. This may not be the best place to learn about these concepts for the first time, because I'm going to focus on knocking down the misconceptions about them.

Then again, it may not be the worst place, for the same reason.

I had promised myself I would not add to the pile of functor or monad "tutorials", but I've been worn down. I gave up when I saw a reddit comment complaining about how Functor was "too hard to understand", which made me sad, because the correct response to the Functor interface is, "That's it?". And while Monad is legitimately a bit more interesting and complex, the correct response to that is not that different.

I am aware of the notorious effect that people "get" monads and then post their own idiosyncratic takes on them. In my defense, this isn't something I write just after my "ah ha!" moment, I've understood them in Haskell's context for many years now, and actually... this isn't even about that "ah ha!" moment at all. This is only about what they are. Even if you completely understand everything I write in this post, the real "ah ha!" where you realize just how useful the libraries built up around the monad interface are, the first time you search for a type on Hoogle where you're like this should exist and it turns out it does in fact exist already, that's still in your future. In fact I'm quite deliberately not trying to convey that feeling in the interests of getting at simply what the monad interface is. Which isn't, strictly speaking, a pre-requisite to that experience, but it does help.