The Hexagonal Wheel Paradox

By Robert Fischer | Published: October 16, 2008

Programmers, as a whole, never learn from their mistakes.
Corollaries:

  1. Any scripting language, given enough time, will become a poor reinvention of Perl.
  2. Any functional language, given enough time, will become a poor reinvention of Lisp.
  3. Any object-oriented language, given enough time, will become a poor reinvention of Smalltalk.
  4. This post will, in the end, have no effect whatsoever.

No related posts.

This entry was posted in Classic, Humor, Programming Language Punditry. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • Johannes R.

    5. Any correct observation, given enough time, can and will be expressed as an imprecise generalisation.
    6. Any generalisation has the effect of amplifying itself becoming a self-fulfilling prophecy. Only looking at the details will reveal insights of the expected evolutionary progress.

  • Brian Hurt

    I’m going to disagree with point #2 you made, and by extension your entire thesis. Consider the arc followed by functional programming the last 20-30 years- you have Lisp->Scheme, ML-> CAML-> Ocaml, and ML->Miranda->Haskell (more or less, ignoring a lot of complexity). Lisp is defined by three characteristics- 1) support for functional programming (first class functions), but with imperative features, 2) dynamic typing, and 3) “syntaxless” S-expressions. Scheme is headed away from Lisp by being much more “pure functional”. Ocaml by having more of a syntax than just s-expressions and by being statically typed, and Haskell breaks all three- purely functional, statically typed, and complicated syntax.

    The reason for this is that the functional language community is aware of Lisp- not just in the “know it exists and know some of the buzzwords” sense that the OO community generally means when it says it’s “aware of functional programming”, but in the “have actually used it for non-trivial projects (oftentimes numerous non-trivial projects) and know what about it works well, and what about it works poorly” sense. In other words, they don’t just know of Lisp, they generally know Lisp. And thus are not inclined to reinvent it- because they already have it. The Ruby folks reinvented Smalltalk because they didn’t know Smalltalk.

    The aphorism is “those who do not know history are doomed to reimplement it- badly”. The corollary is then that those who do know history are not doomed to reimplement it- but are instead capable of building on history and improving on it, and thereby making progress (of some sort).

  • Scott Vokes

    So, what Brian is saying is that functional programmers learn from their mistakes. :)

    What languages are building on Smalltalk, the prototyping languages? I haven’t used Self or Io (I’m getting into Lua now, but it’s not pure OO by any means), but it certainly seems like there is room for growth.

  • Brian Hurt

    I want to point out that it’s not something special about functional programming that makes them not reinvent the wheel- it’s that, as a general rule, functional programmers know their history, and that’s what is special- knowing history, not functional programming.

  • http://www.linkedin.com/in/robertfischer Robert Fischer

    Well, what’s special about functional programming is that it’s got a predominantly academic base. Programming Language Ph.D. students have a vested interest in learning their history. Corporate programmers have a much less vested interest.

  • Scott Vokes

    Brian says, “functional programmers know their history.” This is *exactly* it. Many programmers couldn’t care less about learning lessons from history, and it leads to a great deal of inertia and reinvention of the wheel. (Programmers who do care are often written off as academics.)

  • http://www.linkedin.com/in/robertfischer Robert Fischer

    To be fair to the programmers who couldn’t care less, learning lessons from history often has a poor sales pitch. You have to work to prove a financial benefit in learning a language that you aren’t ever going to be paid to code, usually with some hand-wavy argument based on “increased productivity” or “better performance” or some such. Industry awards the doers, not the thinkers: DHH didn’t become famous because he studied all the previous approaches to web application frameworks and what they did right and what they did wrong and trying to synergize a best-of-breed by adopting all the coolest tricks — he became famous by building something from relatively simple building blocks that practically worked better than the existing industry-adopted technologies. (Well, that and being a one-man hype machine…)

  • nbloomf

    I think it helps that the kinds of academics who work in FP tend to be more mathematician than computer scientist, and mathematicians have a *very* strong sense of history. In that universe of problems, a single project can depend on the work of several to hundreds of people working over decades. (c.f. classification of finite simple groups, Wiles’ proof of Fermat’s last theorem, et. al.)

  • Categories