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."
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.
I must ask why the author assumes that verbosity is bad and why lack thereof makes it a "joy to use."
I think verbosity in moderation is necessary. I have read many an article with developers arguing that they don't need to document their code when their code is self-documenting. Do you make all of your variables and class/function/methods a single character for the sake of verbosity? I hope not. And I would think that reading and maintaining that code would be far less than a joy.
I don't even need to argue this, according to his graphs we should all be using Regina, Mlton or Stalin (a scheme implementation). But instead languages like Java and Perl and C++ prevail. And I would guess that support and a mediocre range of verbosity are what causes that.
Great work in these graphs! But in my opinion, verbosity when used in moderation--like a lot things--is far better than either extreme.
My work here is dung.
Programming languages don't have attributes like size and speed: implementations of these languages do. Take Common Lisp for example: SBCL is blazing fast, while CLISP is rather pudgy (albeit smaller). Any conforming Common Lisp program will run on both. Or consider Python --- IronPython and CPython have different performance characteristics. (I'm too lazy to link these now.)
Point being, describing a programming language as "fast" makes about as much senese as describing a natural, human language as "smart".
Functional languages in practice often implement nlog n algorithms in quadratic time or memory. One of those in a bench mark is devastating. We really understand how to optimize imperative languages well, we don't have the same level of knowledge / experience regarding functional.
I agree this is a pity, but there doesn't seem to be any easy solution. Hopefully this gets fixed over the next generation.
What's so special about it? It looks just like a regular perl program to me. /ducks
Perl is all of the above; it is what you want it to be. That's the beauty of it. It can be a completely obfuscated ASCII art drawing or it can be a very concise, to-the-point one-liner or anything in between. It's the Swiss army chainsaw.
"I have never let my schooling interfere with my education." --Mark Twain
On the plus side, both versions of Python can claim many of the smallest programs in the collection. Ruby (8, 1) might also compete for titles, but unfortunately its performance is so bad its star falls off the performance chart.
Then why the fuck is the Ruby community hyping it so much, and drawing nieve young developers in to a trap?
Not flamebait.
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 (i.e. declaring the data types and their sizes, private / static etc. & whatever the hell makes a program light weight and fast) optionally? It's my hope that if I stick with Ruby one day it I won't be forced to learn Python because performance won't be "Ruby's big issue" in every discussion, but really, that is *just* a hope. I hope this isn't a mistake.
"You know you don't act like a scientist, you're more like a game show host." Dana Barret
Nowhere near true. Objective-C is more verbose than C, yet still more expressive, and largely self-documenting to boot.
I fell hard for FORTH in the mid-80's - it was the programming language of some instrumentation I had to work with. I never did program the instrumentation, but got all the books on the language and interpreters/compilers (the distinction blurs in FORTH...) for it for a number of computers. I did some useful utilities for the PC using "HS/FORTH". I benchmarked it against some other solutions for a course in comparitive computer languages about 1985, and for heavily stack-based (ie very recursive) programs, nothing could touch it. I'm talking QuickSort faster than C.
But I have to admit: though I busted butt, re-writing and re-re-writing programs to make them as clear and readable as possible, though I re-read the remarkable "Thinking FORTH" by Leo Brodie many times (and would recommend it to anybody who wants to understand the craft of programming, whether they want to learn FORTH or not)....despite it all, most of my FORTH programs were hard to read a few months later.
There were things it was really good at - that is, the programs WERE readable later, the problem and language were a match - and others where I could just not seem to decompose the problem into FORTH words that fitted well together without a lot of "glue" to manipulate the parameters on the stack.
That was the most frequent problem with my FORTH programming - one ends up trying to manage several parameters on the stack and doing a lot of stack "DUP SWAP ROTATE" - actions to line up the parameters to hand to the next word. I would re-compose the words and the parameters they wanted to clean up some code, and find I'd made some other code all hard to read.
FORTH was also profoundly command-line oriented, and when the word went all GUI-centric on me with no good "Visual FORTH" or "Tk/FORTH" on the horizon, I slipped from grace. I can't see getting back to it now, either; lets face it, a huge bonus for any programming language choice is its popularity, so that others will maintain your code, so that you can get help and code fragments with a quick google.
But I still think that FORTH should be a completely MANDATORY learning experience in all University and Tech CompSci degrees. You can jump from C to Perl to Python far more easily than to FORTH - it really comes at problems from another angle and working with it for years has been an enormous asset to my non-linear thinking when it comes to problem-solving.
And perhaps if more students learned it, FORTH would rise in popularity for some problems, out of its decades-long sinecure in embedded systems (it started off programming radio telescopes, and undoubtedly still does...) Since it is inherently object-oriented (yes, an assembler-sized OO language from the 1970's, you heard that correctly) it would be an excellent interpretive, experimentation-friendly scripting language for applications. I'm currently needing to do a lot of VBA in Excel at work, and I have a strong suspicion I'd be twice as productive in "FORTH for Applications". It's a tragedy Bill Gates fell for BASIC (of all languages) instead.
When the first 4K TRS-80 showed up at my high school, I had the option to learn BASIC, Z80 machine code, or APL up the street at the local university.
One of my early exercises with BASIC was writing a set of nested for loops which called a subroutine (gosub). I put the next statement that controlled the for loop iteration inside the subroutine, and the return statement for the subroutine inside the nested for loops. It still worked! At that point I understood that there were mechanistic languages and languages with a solid conceptual basis.
APL's reputation for inscrutability was only halfway deserved. Often the problems arose when you were trying to shoe-horn a data structure that didn't want to be an array into an array, because that was your only hammer. Later APL supported nested arrays, which increased the data structuring options, but I think by then the PR battle was lost.
In the original APL, it was kind of painful to pass more than two arguments to an APL function. This lead to programmers passing in flags to the function encoded in the array's rank, which were extracted to the tune of rho rho rho, while imaging the knapsack folding problem in Colossal Cave Adventure. As brutal as any language I've used. But you have to give APL a bit of a pass in some respects. Like vi, it was designed in 1963 to work well within the constraints of a paper teletype.
The next level of inscrutability arose because the APL primitives could often be combined in novel ways to yield surprisingly powerful algorithms. IIRC, the IBM 370 APL included a JIT compiler for certain common APL idioms. A one line program I wrote in APL to find primes (sieve of Eratosthenes) ran ten times faster than the compiled PASCAL program by the CS student sitting next to me.
Understanding APL was a lot easier if you were familiar with functional programming languages, but these hadn't been invented yet. Hey, I didn't know this: the Wikipedia page credits APL as a direct influence on FP, which I first heard of in 1982. Father knows best.
So you encounter this unfamiliar pattern of 15 familiar symbols for the first time, and you brain is polluted with horrible iterative solutions from BASIC or PASCAL, and the beauty of the expression is denied to your limited frame of consciousness.
Like solving a Suduko? Hardly. It takes me twenty minutes to solve a typical five star Sudoku. It used to take me about the same amount of time to puzzle out an unfamiliar APL one liner, which might be anywhere from 10 to 40 characters. There is one small difference: after decoding the APL algorithm, I usually slapped myself across the head and moaned to myself, "I am unworthy to drool on the shoe laces of the grand designer, but I will learn!" Never got that feeling from Sudoku.
Wrestling with the higher art of APL was like giving your ignorance a root canal. Sometimes the root canal made me barf up my milk: when the highest art of APL was applied to shoe horn a data structure unsuitable to array representation into an array representation anyway, like the Beethoven scene in Clockwork Orange.
The third case is where the one liner isn't all that difficult, but it's doing it in more dimensions than the brain wishes to visualize. This is a case where a picture is worth a thousand words. Your 20 character APL function would have been better presented as a caption on a one page UML diagram. Never figured out how to embed a UML diagram in an APL lamp statement on my VT100 terminal.
Another problem APL suffered was too much kinship with Forth. To thrive in APL, you needed to create hundreds of tiny APL functions, which the implementations of the day mashed together into a single unmaintainable workspace.
And the system interface tended to suck.
But other than that, what's not to like?
I could have composed instead a tedious, but germane post on Shannon's first law: concision is a function of preconception. It's a rare breed of programmer who thrives in a language which provides su