This is another lesson that does not require functional programming to notice, but it is a lesson that functional programming puts front and center whereas independently discovering it from imperative programming may take a long time.
Functional programming derives (pun intended) a lot of benefit from its typeclasses, despite them in some sense being second-class citizens in the expression problem to sum types. Much code is written against small interfaces like “functors” or “monads”, which can then be applied to any value that fits into those interfaces.
Functional programming languages of the type I’m talking about have immutable objects1.
For this particular section I’m just going to be talking about “immutability”, so in addition to Haskell, I also include Erlang and any other language with immutable values only. This does not includes languages that merely encourage them, but permit mutability; this discussion is about 100% immutable langauges, where mutation is held not just at arm’s length, no matter how “long” that arm may be (Rust), but outright eliminated.
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.
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 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 modern1 languages have closures now that is no longer a relevant definition.
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:
How many other places in the code must be consulted for a human to understand what it does.
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.