There is a common metaphor for hyperspace travel in science fiction, where some scientist type explains how the FTL works by taking a piece of paper, drawing a line on it to demonstrate “normal” travel, then folding the paper to bring the origin and destination together.

Imperative code affords straight line approaches to problem. I have some code. It does 73 things. I need it to do a 74th thing, in the middle of one of the things it currently does, which is itself a complicated mixture of the other 72 things going on. The most direct approach is just to slap some code in the middle of the thing that does the new thing. I have seen many code bases that are the result of person-centuries of this style of programming. Despite superficially having functions and modules, it is architecturally just a list of things to do, often multiple lists haphazardly mashed together.

One of the distinguishing features of functional programming is an emphasis on pure functions. I will start with an initial sloppy definition of purity to get us started, and will refine it into a range of definitions later. If you don’t like this first one, bear with me.

For now we’ll go with, a pure function is a function that considers only its inputs or immutable external values, makes no changes to any other values, and returns the same result given the same parameters every time. I add the consulting external values because in the case of

I recommend to any professional programmer that they spend some time with a very strict functional language, enough to get to the point they can write non-trivial programs in it.

For the purposes of these posts, you can read functional programming as Haskell. There is an earlier definition of functional programming that just involves having closures, but as all modern¹ languages have closures now that is no longer a relevant definition. There are other languages like O’Caml, Clojure, and Scala that have very functional flavors, but there are few languages in common use that take it to the extreme of Haskell.

Programming languages seem to have somewhat stagnated to me. A lot of shuffling around ideas that already exist, not a lot of new ones.

This is not necessarily bad. Shuffling around ideas that already exist is a natural part of refining them. Shuffling around ideas that already exist is safer than a radical rewrite of existing convention. Even taking a language that already exists and giving it a new standard library can be worthwhile.

Pure Python is generally a slow language. Written for performance, it will often be around 40-50 times slower than C, and Python “written for performance” is Python that is very straightforward and does not use many of its features. Python code that has a couple of methods on inherited classes, maybe a non-trivial decorator, and some __getattr__ or similar features can slow down multiplicative factors beyond the 40-50 slower very quickly.

In This Post Is Not About Python, I make a comment towards the beginning about how Python “written for performance” is “Python that is very straightforward and does not use many of its features”. It may seem odd to post an addendum prior to the post it is an addendum too, but, let’s just say, I’ve learned a bit about how the Internet reads things over the years, and I both want this out of the main flow of that post, yet, available immediately when I post it.

The term “magic” is commonly thrown about in the programming world without a definition. This post gives a definition for it.

Not the definition, just a definition. As a long-standing fuzzy term, I can’t necessarily capture all uses of it in the wild, but I believe this captures a lot of the practical value.

Magic Definition

A piece of code is magic in proportion to:

1. How many other places in the code must be consulted for a human to understand what it does.
2. How difficult it is to know what code to consult based on an examination of the code in question.

You can think of it as being proportional to the amount of time that someone skilled in the language, but unfamiliar with the code base, would need to be sure they know what a given piece of code is doing, from the full source code alone. That is, no debugger or similar tools.

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. The obvious guess for the next term is 32, but for this sequence, it is actually 31.

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?