Slashdot Mirror

← Back to Stories (view on slashdot.org)

Comparing the Size, Speed, and Dependability of Programming Languages

Posted by Soulskill on from the it's-not-the-size-of-the-float dept.

In this blog post, the author plots the results of 19 different benchmark tests across 72 programming languages to create a quantitative comparison between them. The resulting visualizations give insight into how the languages perform across a variety of tasks, and also how some some languages perform in relation to others. "If you drew the benchmark results on an XY chart you could name the four corners. The fast but verbose languages would cluster at the top left. Let's call them system languages. The elegantly concise but sluggish languages would cluster at the bottom right. Let's call them script languages. On the top right you would find the obsolete languages. That is, languages which have since been outclassed by newer languages, unless they offer some quirky attraction that is not captured by the data here. And finally, in the bottom left corner you would find probably nothing, since this is the space of the ideal language, the one which is at the same time fast and short and a joy to use."

3 of 491 comments (clear)

  1. Re:Ruby by Foofoobar · · Score: 1, Troll

    Why can't they make a language, or extend a language like Ruby, such that one can program it as a scripting language, but then add verbosity optionally

    They did. It's called PHP. Notice how much better it scales in that benchmark.

    --
    This is my sig. There are many like it but this one is mine.
  2. Re:Ocaml by TheTyrannyOfForcedRe · · Score: 0, Troll

    There are two explanations for that. #1 You haven't put enough work into learning them. #2 You're not smart enough to be a programmer.

    --
    "Liechtenstein is the world's largest producer of sausage casings, potassium storage units, and false teeth."
  3. Anti-functional FUD by ygslash · · Score: 0, Troll

    Functional languages in practice often implement nlog n algorithms in quadratic time or memory.

    * False *

    We really understand how to optimize imperative languages well, we don't have the same level of knowledge / experience regarding functional.

    * False *

    Did parent poster read tfa?

    Does introducing functional features kill performance? No, it does not...

    In fact, the great success of functional languages in the shootout supports the intuition of just about everyone who has learned to program well in both imperative languages and functional languages - that the expressiveness of the functional paradigm makes it easier, not harder, to optimize speed, if that's what you need.

    People whose brains have rusted in place from too many years of strictly imperative programming will say anything to protect themselves against admitting the need to learn something new.