A Day In The Lyf

…the lyf so short, the craft so longe to lerne

Beating Sapir-Whorf

The Sapir-Whorf hypothesis is a famous linguistic theory that postulates that what you think is constrained by what you can say. In other words, the way you understand the world is limited by the language(s) you speak.

The hypothesis is regarded as incorrect by modern linguists. However, the spirit of the theory appears to be largely true if we refer only to computer languages – our solution space is limited to the number of ways we know to express solutions. Paul Graham was indirectly talking about Sapir-Whorf when he described the Blub Paradox. Blub, the language that sits halfway up the hypothetical totem pole that represents the relative power of computer languages, has certain constructs that make languages lower on the pole seem downright dysfunctional. The Blub programmer would look down, realize that the language he’s looking at doesn’t even have some language feature X, and scoff at how much extra work it would be to write programs without X. X, the Blub programmer argues, is so fundamental to designing your application that it would criminal to use any languages without X.

When the Blub programmer looks up the totem pole, though, he just sees weird languages. What he doesn’t realize, of course, is that programmers in those languages are looking down at Blub and wondering how anybody could possibly program without language feature Y.

The Blub paradox makes a nice story, and while it has value, it oversimplifies the language landscape. There isn’t a linear totem pole for expressive power when it comes to languages. Graham suggests looking at the size of the parse tree, which is indeed a useful single metric, but ignores aspects like long-term maintainability, readability, syntactic sugar, etc. The computer language landscape is diverse precisely because there are different opinions on the best way to solve different problems.

What should be obvious is that not all software problems should be solved with the same tool. Too many programmers go down that path, and use Java (or C#, or C++…) as the hammer and let everything become a nail.

Granted, we don’t always have control over which language we use. We write programs in Java (or C#, or C++…) because that’s our job, even though we may suspect that it’s not always the best tool. Fair enough. But if our ability to describe solutions to a problem is constrained by the programming languages we know, doesn’t it make sense to learn other languages even if we can’t use them on the job?

Knowing a diverse set of programming paradigms can help you become a better programmer. It’s helped me. For example, I wrote a closure-based undo in C#. A more typical OO-based undo would have resorted to the command design pattern, but the closure-based implementation required much fewer changes to the codebase. I don’t think I would have come up with the solution if I had not had some prior exposure to functional languages.

The key is to make sure that when you pick up a new language, that it’s different enough from languages you already know that you force yourself to wrap your head around some new concept. You don’t get that, for instance, going from Java to C#. I’ve tried learning at least a little about several languages, and found useful new concepts in the following:

In the object-oriented space:

  • C# / Java (statically typed OO)
  • Eiffel (design-by-contract, anchored types)
  • Ruby (open classes, incredible reflection, metaprogramming)
  • Smalltalk (like Ruby, but with keyword arguments and a very lightweight syntax)

In the hybrid OO space

  • Perl / Python (dynamic typing, default variables, list comprehensions)
  • C++ / Delphi (destructors)
  • JavaScript (prototypes instead of classes, hybrid functional)

In the procedural space:

  • C (weak typing, systems level procedural, teaches good understanding of computer memory)

In the functional space:

  • Scheme / Common Lisp (homoiconic, syntactic macros, multiple dispatch, continuations, no penalty for tail recursion)
  • Erlang (nice distributed model, pattern matching)

In the “everything-else” space:

  • shell scripting (using processes as the unit of abstraction)
  • SQL (yes, even the much-maligned relational, set-based model provides another, occasionally superior, way of solving problems)
  • XSLT (declarative)

In the “I wish I could speak intelligently about” space:

  • Prolog (propositional logic programming)
  • Forth (stack-based programming)

PragDave recommends that you learn a new programming language each year. It’s terrific advice. Pick a language, find some coding exercises, and try to wrap your head around solving those problems idiomatically in the new language. Don’t be surprised if you start out solving them the same way you would have in a language you already knew, but remember the end goal is to learn new problem solving techniques, not just new syntax. Since you probably won’t be using the language on the job, you’ll almost certainly forget the syntax after a while. Start posting questions to mailing lists, blog about some of your sample work, and don’t be afraid to make a fool of yourself. The way I see it, if you’re still afraid to make a fool of yourself, then you clearly haven’t made a fool of yourself enough.


Written by Brandon Byars

May 13, 2008 at 11:09 pm

Posted in Languages

2 Responses

Subscribe to comments with RSS.

  1. Ruby and Python definitely belong to the same category as one another – they are very similar, really. Which category that is, you be the judge.

    Simon Brunning

    November 30, -0001 at 12:00 am

  2. Interest story!


    November 30, -0001 at 12:00 am

Comments are closed.

%d bloggers like this: