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?

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