programming

Joe Armstrong: Why OO Sucks

Famed programmer Joe Armstrong passed away this weekend. He created the Erlang programming language, based on the actor model, and without using Google, I’m pretty darned sure that Erlang had an impact on Akka, the very cool actor library for Scala. Here’s an article Mr. Armstrong wrote some years ago, titled, Why OO Sucks (OO as in OOP).

The meaning of the word “reify” in programming

I don’t recall hearing of the words “reify” or “reification” in my OOP years, but that may be because I studied aerospace engineering in college, not computer science. Since learning functional programming (FP) I often see those words, so I thought I’d try to understand their meaning.

Background

I ran into the word “reify” when I saw code like this:

trait Foo {
    //...
}

object Foo extends Foo

I’d see that code and eventually saw that someone described that last line as a “reification” process.

What “reify” means

The short answer is that the main definition of reify seems to be:

“Taking an abstract concept and making it concrete.”

For the longer answer, I found the following definitions and examples of reification.

Roy Carlson: The sooner you start to code, the longer the program will take

“The sooner you start to code, the longer the program will take.”

~ Roy Carlson (which I saw in this tweet)

In general, I’m a fan of that quote, meaning that the harder the problem is, the more I like to find a whiteboard or some index cards to work through the problem that way before I start coding.

The Scientific Method

Back in the 1990s I was fortunate enough to work for a very smart, energetic man. In a way, working for him — or at least in the position he gave me — helped change the trajectory of my career into what I wanted it to be.

Skipping 99% of that story ... one thing he did exceptionally well was troubleshoot problems, and troubleshoot them very fast. I didn’t know it at the time, but he was using something called The Scientific Method. After observing him for a while, I saw him repeat these steps so precisely that I thought he must have them on a tattoo on the inside of his eyelids:

  1. Observe some feature, in our case, a bug
  2. Hypothesize a model consistent with the observations
  3. Predict future events the hypotheses should yield
  4. Verify the predictions by making further observations
  5. Validate by repeating

Testing takes time, just like structural analysis takes time

“Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It’s time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn’t sufficient, but it is necessary.”

~ Neal Ford (as seen on this tweet)

Functional programming leads to happiness alvin December 16, 2018 - 5:35pm

As I wrote in Functional Programming, Simplified, functional programming can lead to happiness (and sanity). The quotes in this slide from Rúnar Bjarnason’s FP talk expand on what I wrote in my book. They keys are that pure functions are very simple, and you don’t have to constantly worry about the mutable state in your application.