Joe Armstrong Quotes

The clarity of programming languages have several advantages over traditional languages. For example, programs in such languages are considerably shorter than the equivalent programs in imperative languages. They also encourage clear programming styles.

A technology that nobody use, just dies.

I don't like modules. It's a sort of love/hate relationship. The problem with modules is the classification problem. When you have written a function you don't know in what modules you put it in.

People says notation does not matter, they don't like Erlang notation [...] but notation does matter.

That's quite easy to make things that are not fault tolerant and not scalable.

What's legacy code? That's dead programmers stuff, not only there are no comment in it, you can't ask people because they are dead. It written in languages that nobody understand, there is no specification and yet it works beautifully!

I think things like PowerPoint have sort of destroyed creativity.

I have a problem with categorization problem because I cannot say this thing got to be in that module or that class.

Finally after hours of googling, I can write my program. That what's I call research. The research takes 3 hours, writing the program takes 2 minutes, for the final version. You publish the program, and you throw away the research. That's not smart. Somebody later cannot figure out how you did it because all he's see is the end result.

Four good tools to learn: Emacs, Bash, Make and Shell. You could use Vi, I am not religious here. Make is pretty damn good! I use Make for everything, that good!

Hidden state in object so in any object programming language means you can't compose things. Hidden state is a just state effect stopping you to composing things.

Defensive programming in C, is only necessary because you have only have a single thread of computation. If you have a sequential language and it crashes, you lost everything.

People are inventing new programming language all the time but I think that's not the big problem is actually writing programs. I think the big technical problem in building system is what I call "the connecting things together problem". It's a version nightmare problem. It's given things in different languages and actually connecting them together.

I was using Smalltalk and I never actually go through this boundary of sort of simulating the class structure in my head so that I can program itself. It was painful, I used to chose the changelog to find things, I regret you did it.

In Erlang, F(G(X)) is used for small steps. Pipes are used for big steps. The big steps semantics is processes. It's messages between processes. Processes are used for big computation. When you got F(G(X)) is a small step, and we map small steps on the same core. We map big steps on processes. Processes map on multi-core. The system just does it for you.