read


read or learn more

#_(< (count common-lisp) (count clojure))

Apr 5, 2011

There has been some talk about the number of forms available in Clojure compared to Common Lisp. I find this line of thought puzzling. This is the same line of thinking that has been thrown at Common Lisp for ages — and the argument grows no more valid over time.1 The only reason that we can have such a discussion is because forms and functions in Common Lisp and Clojure are countable in the first place. How do you measure the size of a language’s conceptual model? Is the Var or the function the right currency with which to tally language size? If so, then how many Vars are Java’s checked exceptions worth?

A well-formed Forth program consists of hundreds of special-purpose words, but no one would say that Forth is a bloated language. Instead, it’s important to know that a language should always have the right number of forms and functions to be properly expressive. Should Clojure eliminate useful functions for the sake of Var count? Who pays the bill in that case? Well, of course, the Clojure programmer does. It’s simple to write many of Clojure’s core functions, so why do we need most of them? We can instead force the programmer to write and re-write common functions over and over again. This is a Scheme perspective. Clojure is not Scheme.

Any function, form, or Var in Clojure’s distribution is there for two reasons: 1) it is useful and 2) it provides abstraction.2 Rich is very thoughtful3 in including or excluding new features into the language. In the war between practicality and purity in Clojure’s offerings, it’s the former that wins.4

Clojure has the right number of Vars™ to provide an expressive programming experience. No less.

:f

thanks to Michael Patterson, Edmund Jackson, fossi, and Pepijn de Vos for reading a draft of this post and providing feedback.

  1. I’ve often found that people rallying against Common Lisp’s “bloat” fail (or refuse) to recognize that the language was designed to allow the programmer to do anything not simply the right thing (as defined by the language designers). It’s doubly perplexing when advocates of Common Lisp, who should know better, point their gnarled fingers at Clojure’s supposed “bloat”. ↩

  2. Abstraction takes the typical cognitive form that we’re all familiar with, but it also helps to abstract performance characteristics. This distinction is the subject of another post. ;-) ↩

  3. I find myself using this word a lot these days. ↩

  4. It’s even better when a nice balance can be found, which Clojure strives for. ↩

Related posts:

  1. On Lisp -> Clojure: ProloG (pt. 1)
  2. On Lisp -> Clojure (Chapter 5)
  3. On Lisp -> Clojure (Chapter 3)
  4. On Lisp -> Clojure (Chapter 2 – redux)
  5. On Lisp -> Clojure (Chapter 4)

7 Comments, Comment or Ping

  1. Phil

    “It has… how would you say it?… too many notes.”

    Apr 5th, 2011

  2. Stanislav Datskovskiy

    The real issue, of course, is bloat in non-orthogonal functionality rather than bloat per se.

    A volume of Knuth’s TAOP might be heavier than an intro text on Java, but only the latter is an example of any kind of bloat.

    I suppose I ought to have mentioned that, but it seems self-evident to me.

    Apr 5th, 2011

  3. fogus

    @Stanislav

    I would be interested to learn your thoughts regarding Clojure’s bloat in non-orthogonal functionality.

    Apr 5th, 2011

  4. Stanislav Datskovskiy

    @fogus,

    The presence of Java, first and foremost.

    As for the language itself: the built-in collections, for starters. Along with the associated syntax clobbering.

    Apr 5th, 2011

  5. fogus

    @Stanislov

    Fair enough. It’s unlikely that these particular elements will change (well, not any time soon that is). However, can you see the parallels between the age old argument against Common Lisp (and most Lisps in general) in your points about syntax and collections?

    Apr 5th, 2011

  6. JD

    Aha – that’s why I had trouble caring when I read about Clojure being as “large” as Common Lisp. Size doesn’t matter, relevance does. In fact, sharing Java’s class library should actually count for something – it’s an actively maintained, current set of libraries, as opposed to Common Lisp’s moribund library.

    Apr 5th, 2011

  7. Stanislav Datskovskiy

    @JD,

    I find the libraries available today for Common Lisp (http://www.cliki.net/Current%20recommended%20libraries) to be well-written and quite useful. Of course, I do not know what your needs are, and I cannot speak for you.

    I am rather curious, though, what you mean by “moribund.” Do you believe that my Common Lisp systems will grow old, gray, arthritic, and mysteriously grind to a halt? Or something else? As far as I’m concerned, the language is alive and well.

    Apr 6th, 2011

Reply to “#_(< (count common-lisp) (count clojure))”