programming-languagesfunctional-programmingcomparisoncode-size

If functional languages are really concise, why don't they have a better rank in the language shootout game?


I compared the languages at the language shootout game by their code size only. Here is a summary of what I got (shortest first, grouped by similar score).

  1. Python, Ruby, JavaScript, Perl, Lua, PHP, Mozart/OZ
  2. OCaml, Erlang, Racket, Go, Scala, F#, Smalltalk
  3. Pascal, Clean, Haskell, Common Lisp, C#, Java, C
  4. C++, Ada, ATS

I wonder why. The winners seem to be plain old dynamic languages. Erlang, Racket (née PLT Scheme), and F# are doing OK. Haskell and Common Lisp don't look more concise than claimed-to-be-verbose Java.

UPDATE:

I've found an insightful post on this topic with charts. I also found a similar comparison of languages for a larger program (a simple ray tracer). Altogether, I wouldn't say I got "the" answer, but I got some food for thought.


Solution

    1. No language is always superior to another (well, there are a few exceptions... ;) ), so same applies for a group of broadly categorized languages. The benchmarks cover a broad array of topics, and X may be less suited for one than Y.
    2. The source code is gzipped, we don't really know how many lines of what length the programs were (yeah, it's an indicator)
    3. A considerable number of functional languages still do much better than the widespread imperative, static languages - it's not that functional programming languages aren't succinct, but the dynamic languages allow even more succinct programs
    4. At least in Haskell, much potential for conciseness comes from abstractions you can build yourself - but you do have to build them yourself and include them in your solution. A clever Haskell hacker may implement a monad in 20 lines that allows solving a small problem in 20 lines instead of 30 - the abstraction doesn't pay off for a small program, but could save many lines in a larger (eg. 200 lines instead of 300) program. I guess the same applies for Lisps (only macro instead of monad)
    5. Don't take the fanboys too seriously. FP is awesome and worth looking into, but it doesn't cure cancer and doesn't magically shorten any code by 25%
    6. They can still beat dynamic languages for some areas: For example, tree-like data structures and their processing is expressed extremely naturally in many functional languages, thanks to algebraic data types and pattern matching.