(Temporary note, March 2: I have this whole series written, but I have suspending posting until I no longer have the seasonal cruds. I’d like an opportunity to engage with anyone who posts this various places without my personal crankiness stat starting maxed out.) 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.

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.

To set expectations, this is not a sweeping review of the entire industry; indeed, quite the contrary. This is just one guy’s story about his limited experiences with VR gaming. About five years ago, the office I work at allowed some interested employees to host a “VR Gaming” event in the main conference room. It wasn’t sponsored by the company, so it was put on just by the enthusiasts that happened to work there.

An increasingly-frequently asked question in the Go subreddit is some variant of: “I have this code but it isn’t doing what I expect it to do.” type MyStruct struct { // definition } type OtherStruct struct { // definition } type MySumType interface { MyStruct | OtherStruct } func main() { myStruct := MyStruct{...} printVal(myStruct) } func printVal[T MySumType](in T) { switch val := in.(type) { case MyStruct: fmt.Println("It's a MyStruct") case OtherStruct: fmt.

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.

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.