Monday, 31 October 2011

Rich Hickey

Rich Hickey is the creator of the Clojure programming language. Clojure runs on the JVM and is part of the Lisp family. It's been generating quite a lot of buzz for a couple of years and together with Scala is the hottest ticket in the JVM world. And good riddance, since Java is showing signs of rigor mortis.

Anyway, Mr Hickey is a great speaker and he's got some very interesting stuff to say.

Some of his ideas that I agree with;
  • Object Oriented design as popularised in C++, C#, Java etc really isn't any good for big complex systems. "Mutability by default" leads to incomprehensible and buggy programs
  • Thousands of objects (concurrently or not) modifying each others' state is just another form of spaghetti code (no matter how many design patterns and clever locking schemes you use)
  • Our obsession with testing is just a side effect of our insufficient programming tools. If we had better tools (for instance languages) we would more easily write correct programs and we wouldn't need to obsess about test coverage
  • Agile and short sprints can lead to always picking the "easy solution" instead of a better thought out "simple solution". If this is repeated over a long time, this accumulation of technical debt leads to programs full or errors.
Obviously the real world isn't as black and white as stated above. It's very possible to write buggy programs in ML and Clojure, and absolutely gorgeous big programs in C++. However, generally speaking Mr Hickey is onto something. The OO paradigm needs to be questioned and not taken as gospel, the new breed of functional/OO hybrid languages really have something to offer. Especially when multi core concurrent programming is becoming the norm.

Here's link to a very good talk by Mr Hickey on some of these topics...


Much more on Mr Hickey and Clojure in future posts.

Update: Are we there yet? Another awesome presentation dealing with popular languages, OO vs Functional, immutability, incidental complexity.

Sunday, 30 October 2011

What is software?

Having worked on many software projects and with a lot of different people, one thing that strikes me is the lack of understanding of what software is and how it's created. Even among us developers, there's is still this belief lurking, that if you senior enough, you can design and size a problem, before you hand it over to some less senior developers to implement. (Some) people still believe that building software is the same as building cars on an assembly line.

Abelsson and Sussman speaks about a "sorcerer's spirit" in chapter 1 of SICP;

A computational process is indeed much like a sorcerer's idea of a spirit. It cannot be seen or touched. It is not composed of matter at all. However, it is very real. It can perform intellectual work. It can answer questions. It can affect the world by disbursing money at a bank or by controlling a robot arm in a factory. The programs we use to conjure processes are like a sorcerer's spells. They are carefully composed from symbolic expressions in arcane and esoteric programming languages that prescribe the tasks we want our processes to perform.
Some years back I say the great presentation by Brian Cantrill (then DTrace developer at Sun). The whole presentation is really interesting (DTrace is awesome btw), but the first "philosophical" part really stuck with me, and goes some ways to explain what software is. Here's a transcript of the first part, and the full presentation is here.

Software is really different, it's unique. It is different from everything else that we (as humans) have made. And when we try to draw analogies between software and other things we built, those analogies always come apart, the are always loaded with fallacies. So what is it that makes software so special? <...>

Here's the paradox; is software information or is software machine? The answer is that it's both. Like nothing else, in software the blueprints are the machine. In software, once you designed the thing you've built it, it is the machine. That's why the waterfall model is fundamentally flawed. This idea that you can design the design before you design it, which is what the waterfall model is essentially saying, is flawed. <...>

This is a point that was hit home to me when I (Brian) first came to Sun, and helped develop the ZFS file systems with Jeff Bonwick. We are in Jeff's office and we had the source code up in one window and the debugger up in another. And all of a sudden Jeff steps away from his keyboard and says "Does it bother you what none of this actually exists? Where are looking at the source code over there, and the debugger there, and we think that we are looking at a thing. But we are not looking at a thing, we see an representation of an abstraction." This (the software in the debugger) does not exist anymore that your name exists. "Your name doesn't exist, we just made it up, doesn't it bother you?" <...>

We can't see software, what does running software look like? It doesn't look like anything. It doesn't emit heat, it doesn't attract mass, it's not physical. It's a mathematical machine. And that is the problem with all the thinking about software engineering has come from the gentlemanly per suits of of civil engineering. Men in top hats and suits would employ millions to build bridges and dams. It's very romantic but has no analogy in software. That is not the way software is built. Software is more like a bunch of people sitting around trying to prove theorems.

Saturday, 29 October 2011

Welcome and some guiding words...

Let's start with a great quote from my favourite book on computer programming, the mighty SICP (or Structure and Interpretations of Computer Programs) by Ableson and Sussman.
Underlying our approach to this subject (computer programming) is our conviction that ``computer science'' is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology -- the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of ``what is.'' Computation provides a framework for dealing precisely with notions of ``how to.''
The entire SICP book is available on the web here, and if you think of yourself as a programmer, and haven't read it, well, what are you waiting for?

So, welcome to yet another blog about programming, not computers, but programming, or at least a very small slice of it. I'll put my thoughts of some topics that interest me here, and the focus will be on how to create readable, correct and maintainable code, functional  programming, some key problems a "modern" developer will face, like concurrency.

So, add this one to your RSS aggregator if you want to read about OCaml, Clojure, Scala, F#, Mono, concurrent programming etc...