Why The Defaults Matter

I often think of why I feel that it’s important to have a functional language—not just write code that’s pseudo-functional in an imperative language.  As I think this through, I wanted to record some of my ideas on the subject.

Even the best developers I’ve known are almost always inclined to take the defaults.  I mean if the default string type is ASCII then you’re very unlikely to see Unicode strings in the app unless someone specifies that this is needed.  This is not laziness; it’s simply that these developers have other issues to concentrate upon.

Why is this important?  Simply this: I’ve come to realize that default mutability is an accidental complexity–in the sense that Fred Brooks used that term in his “No Silver Bullet” essay.  Don’t misunderstand what I’m saying–mutability is necessary and appropriate.  But having all values in software mutable by default is an invitation to lots of unexpected side effects.  And this is why I really believe that functional languages will continue to gain in use.  Functional languages are immutable by default.  Impure functional languages (OCaml, F#, Clojure, and Scala among others) do allow a programmer to specify mutable quantities where it’s appropriate due to performance considerations but they default to quantities being immutable–and that’s why they’re important.  If things default to being immutable, developers will learn to work with immutable quantities and become accustomed to them in the same way they’re now accustomed to thinking in Objects.  People seem to forget that 30 years ago, OO was as much an academic discipline as Functional is now.

Every developer knows they should mark quantities as constant (or final or readonly or whichever keyword expresses immutability) but most do this only as an afterthought and they do it incompletely.  Default immutability could eliminate a whole class of side-effect errors and therefore reduce errors in our code by a large fraction of all errors present. The issue is not the question of does “const correctness” (for lack of a better way of phrasing it) make software less error-prone; the issue is getting developers who are always under impossible deadlines to use constants by default.  Languages that default to constant, immutable quantities are a large step in that direction.  This is why functional programming is important and this is why you’re going to inevitably see more and more developers gravitating toward these functional languages.

The Tech Support Effect

At a few points in my career I’ve worked in tech support.  It’s an experience I heartily recommend to every developer.  Every developer should spend at least a month or two supporting software because it helps you to understand the sorts of issues our tech support people deal with.  I really believe that too many developers, and I include myself in that group, don’t appreciate how truly valuable good technical support people are.

An interesting thing happens to many support people of long-standing.  They get a very negative impression of the software they’re supporting.  This is simple and understandable because all they hear most days are complaints about the software.  People don’t call tech support to tell them “Hey the software is working great!”  Even if 99.9% of the software is working exactly as it should, the .1% will be the part that customers call about. For lack of any better name for this phenomenon I call it the “Tech Support Effect”—that long term cynicism that sets in from hearing complaints and negativity day in and day out.  

I think the same thing happens in other areas of life as well.  The news can really depress a person quickly because the parts of our economy that are working aren’t the parts that get reported upon.  Gas may reach $5/gallon soon but no one in the news will tell you that the Europeans would be dancing for joy if gas were only $5/gallon over there.  Of course they have better mass transit but that’s another discussion. The 999 people who safely negotiate some dangerous turn on a freeway don’t make the news; it’s the 1 person who fails to make the turn that gets shown at 6 pm.  It’s easy to get a very skewed view of things.

And I definitely think this happens in software development.  We see the failings of our own software so often that we can really get down on ourselves and start to think of ourselves as idiots.  We can forget that many of us turn out thousands of lines of code that works substantially as it should when we’re shown a line of code where we forgot a semi-colon and that caused a problem for a customer.

The point is this; don’t fall for the Tech Support Effect in your own life.  All of us have things in our life we could wish would be better.  But every once in a while if you think of all the good things you’ve already got it can help to put the negative in perspective.