Slashdot Mirror
Comparing the Size, Speed, and Dependability of Programming Languages
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."
Citation needed.
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
You dumb motherfucker there are things in the semantics specified by a language that makes one easier than the other to optimize and make fast. So while there are variations in implementations, stuff like Perl, Python and Ruby will never achieve the speed of C++.
SBCL is fast, but not as fast as hand coded C++ btw. SBCL is much faster than Ruby and Python, but that's partly because it allows stuff like optional static typing to help the compiler do its job. Ruby and Python as languages do not allow such things.
We are programmers. Who care what could THEORETICALLY EXISTS ? The only stuff that matters is what languages can DO NOW. And for NOW, speed of languages are divided in three categories : fast statically typed imperative, fast statically typed functional, slow dynamically types. C, C++, Java, C#. Haskell, Statically typed schemes and lisps, clean. ruby, python, perl, php, tcl.
I don't know if you've tried Microsoft's C#, or Apple's Objective C, but basically these are essentially big "F.U.'s" to developers.
Different customer base, same idea I guess.
So we already knew perl was the worst language in the world to write in and to have to maintain, but now we know that it's slow as hell, and no nearly as concise at it appears to be. Now that's what I call a study.
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.
There is no beauty in perl. Period.
Your example is spot-on, though. It can be completely obfuscated ASCII art or an unreadable single line.
/ \
\ / ASCII ribbon campaign for peace
x
/ \
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."
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.