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."
This site is awesome. It's very simple. They have over code in over 1200 different languages that spits out the lyrics to the "99 bottles of beer on the wall" song. Check out the perl example (yes, it really does work): http://99-bottles-of-beer.net/language-perl-737.html
"I have never let my schooling interfere with my education." --Mark Twain
http://en.wikipedia.org/wiki/Forth_(programming_language)
--
Forth is a simple yet extensible language; its modularity and extensibility permit the writing of high-level programs such as CAD systems. However, extensibility also helps poor programmers to write incomprehensible code, which has given Forth a reputation as a "write-only language". Forth has been used successfully in large, complex projects, while applications developed by competent, disciplined professionals have proven to be easily maintained on evolving hardware platforms over decades of use
--
Forth is still used today in many embedded systems (small computerized devices) because of its portability, efficient memory use, short development time, and fast execution speed. It has been implemented efficiently on modern RISC processors, and processors that use Forth as machine language have been produced
--
Citation needed.
no citation needed. it's matrix driven so it naturally optimizes loops better.
ML, Haskell, Scheme, Fortran and Common Lisp are on the list. You probably didn't notice them because they are listed by their implementation name (e.g. mlton/O'Caml, GHC, Stalin/Gambit/Ikarus/Chicken, G95, SBCL/CMUCL, etc.). The Shootout front page lists which implementations implement which languages.
If you would like APL to be on the list, then submit benchmarks for APL to the Shootout (the blog got its data fro there). The Shootout is mainly driven by user submissions. They do have some fairly strict rules about how to submit. However, if you can name an implementation (along with enough guidelines to make installing it easy) and provide a reasonably full set of benchmarks, then the language will generally be added.
One tip about submitting though: try to make life as easy as possible for the guy who runs it. He doesn't have time to figure out typos or to fix "easy" bugs in some programming language they he may not even know.
I thought it compares implementations.
If you look harder, you'll see multiple different implementations of the same language.
Patents Drive Free Software as Hurricanes Drive Construction Industry
I'd say that for a bytecode interpreted, turtles-all-the-way-down language, Squeak smalltalk performance is stellar (things are relative). Remember that Squeak manages to be faster than Ruby while implementing MOST of its core features in itself. It doesn't use lots of C code like Ruby do. Ruby has lots of core classes, like Array, FULLY implemented in C.
So Ruby is quite the crappy language. Slower than Squeak while having core stuff written in C.
Isn't that the 'dlang' reference?
Where's Ada?
One item in the list is gnat which is one particular implementation of Ada. So, there is at least one Ada implementation on the list. I did not recognize any others.
--- Liberty in our Lifetime
A good compiler probably knows a lot of optimization's that many assembler programmers don't know or don't really want to use, because the code would look too cryptic / too difficult to understand afterwards or bloated, although it's faster. The compiler knows, how to feed the pipelines of the CPU the right way, I doubt that all assembler programmers know that.
Besides that if someone programmed a whole OS in assembler, I assume it would take a long time, until it's done, it would be full of bugs and take an eternity to remove those without incorporating new ones.
Many performance problems in C++ are probably due to bad programming anyway, like people not noticing, when (copy-)constructors are unnessarily called very often and all that stuff, because if you do it right, it's can be extremely fast.
Besides that usually only a fraction of code is performance-relevant anyway, and so it doesn't make sense to optimize everything for speed, but only those parts that really consume time, e.g. because they are called so often. That's what profilers are for.
( The most important optimization is to pick the right algorithm and datastructures for the right task anyway. )
With the impure languages optimization becomes much much easier.
Funny you should say that. I'm just starting my dissertation work on parallelizing purely functional languages. (Yes, I know that topic was nearly beaten to death in the 1990's and earlier.)
But anyway, optimizing the *parallelization* of a functional language can be a lot easier (in some ways) when the language *is* pure. At least, according to my background reading so far.
verbosity != self-documented
Ruby example:
do_something() if some_time 7.days.ago
To me, this line of Ruby code is perfectly clear and self-documented. It is also about as short as you could make it. If I had to write the same code in Java, it would be long enough that I would feel it required a comment.
It's *not* several layers of objects.
System is the package containing the 'out' object, which is of type "PrintStream". println() is simply the method that outputs a line of text to the standard output, followed by a newline character for the current system.
Now, compare this to C++: std:: is the namespace, which is the same as "System". However in C++, this code: "using std::cout;" will allow you to omit the name space when you use the object. "cout" is an object of type ostream, like "out" in Java. And then, "operator
So in both languages, we're dealing with 3 different things: a namespace, an object, and a function call. Some people think C is better because you can just write printf(), but I disagree because I cringe whenever I need to type silly things with libraries such as BASS_DoThis(), BASS_DoThat(), etc. Namespaces are *way* better.
2. "gzip bytes," which they define as follows: "We started with the source-code markup you can see, removed comments, removed duplicate whitespace characters, and then applied minimum GZip compression." ... actually #2 seems to me like a very reasonable measure of expressiveness
I'm not so sure about that. For instance, their preprocessing effectively gives Python free blocks, by removing repeated spaces but not removing { and } from other languages. What they should do is:
1. remove all comments
That's it. You don't need to remove whitespace at all... gzip will compress 10 spaces to roughly the same as 1 space, if it's regular, but reducing 4, 8, 12 runs of spaces to 1 will affect the compression. You don't need to rename variables, because AReallyLongVariable used a dozen times will be amortized away if it is used often... it won't affect the gzip size much more than calling it 'a1'. They should also use maximum compression (that's the point of compressing it in the first place, to reduce it to the essential structure)... they should use 7zip or rar. So IMO their preprocessing of the source is creating a misleading metric.
Try this link
Objective C tutorials
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
That's a myth.
Find free books.
That's incorrect. He is talking about verbosity in bytes. Take a look at his source code and the data file he used, which are linked to from TFA.
Find free books.
Exactly. As an example:
for item in list:
print list
for(object o in list) {
Item item = (Item) o;
System.Out.Println(item);
}
for(std::list<Item*> it=list.begin();it!=list.end();it++) {
cout << (*it)->name << "\n";
}
Three languages. Same identifiers. Big difference in both verbosity and readability.
The cake is a pie
Static imports?
http://java.sun.com/j2se/1.5.0/docs/guide/language/static-import.html
http://lolcode.com/
All of these numbers are based on what completely flawed microbenchmarks from a site that used to be called "The Language Shootout". The numbers have been thoroughly debunked several times in the past. See this thread, for example: http://www.javalobby.org/java/forums/t86371.html?start=30 Or just google for "language shootout". It's not that the people who run this are just incompetent (making dumb mistakes like including JVM startup times). It's that they actively allow and even encourage cheating. For example, at least one of the "C" benchmarks actually uses hand-coded assembly (libgmp), and rather than stick to the obvious "program must be written in the language it's listed under" rule, the site maintainer suggests that the "Java" benchmark could be changed to also use assembly. This is all documented in the thread listed above. After several of these debunkings over the years, they had to change the name from "the language shootout" to something else, as any quick google will show that these benchmarks are completely bogus. Nothing to see here, move along.
Scala, just as type-safe as C++ with good performance and excellent JVM integration:
scala> val list = List(3, 4, 2, 1)
list: List[Int] = List(3, 4, 2, 1)
scala> list foreach println
3
4
2
1
You know very well this is a big deal for the future of programming.
Sam ty sig.
copy(alist.begin(), alist.end(), std::ostream_iterator(cout)); .
Not to mention std::for_each and std::transform from
Probably just me, but I find your C++ example code slightly unfair.
I recall seeing a study that showed that bugs per line of code(*) was fairly constant across languages. (Anyone know what study that was?) Thus the fewer lines of code(*) in your program the fewer bugs. Thus more expressive languages are better.
I do not remember the source of the study, but you got it wrong anyway.
The result of study was that amount of bugs per [effective] line of code depends solely on programmer. Different languages have different code density, yet programmer makes literally same amount of bugs regardless of language.
I have seen apparently perfect one-line Perl programs - which had 3+ bugs in them. If the same person wrote it say in Java, then it would have been say 25 lines of code, but very highly likely number of bugs remained the same.
All hope abandon ye who enter here.