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."
APL was faster than C and there has never been a more terse language.
Some drink at the fountain of knowledge. Others just gargle.
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.
It would have been right in the corner for conciseness. One-line programs are fairly standard, but can accomplish quite a lot.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
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
I am surprised how they manage to get scala to perform so much worse than pure java.
.class files and uses static typing and the makes claim that the bytecodes are almost identical.
Scala compiles to pure java
I wonder if the benchmarks are executed in the same environment.
http://shootout.alioth.debian.org/ has a Gentoo label behind the java benchmarks, but not the Scala one.
Oh but Java is a plodding, stumbling, lumbering, slug of slowness. All thoroughly indoctrinated Slashdotters know that already. No need to RTFA...
OMG!!! Ponies!!!
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."
Plain ASCII. The shorter and faster it is, the more joy it is to use.
What can compare to the joy and speed of, for example, the command "Go fuck yourself!"
Even shorter and faster syntax: the command "F.U.!"
And for conciseness of comments - "SHIT!" and "oops!" and "WTF???"
Looping constructs: "Sit on it and rotate!"
If-else constructs: "Dat so? F.U. 2!"
foreach: "You, your mamma, and the horse you rode into town on!"
Exit statements : Just fuck off!"
c-style assertions: "Eat shit and DIE!"
#defines: "#define YOU One dumb motherfucka"
conditional #includes "#ifdef YO_MAMMA"
real-time peremption: "I OWN you, beotch!"
I have both fsdn.com and slashdot.org blocked, and can *still* read the comments. Apparently there's a conservation of Javascript thing going on . . ..
I'm a bit rusty on my languages too, but what about ML, Haskell and other pure functional languages? Scheme?
And what about the old standards? Fortran, Cobol and Common Lisp still do a lot of the world's work. C/C++, while a member of the family, doesn't encapsulate them.
I guess expressiveness gets at the idea that programmer hours are more important than compiler or runtime hours for most applications, but the link isn't real clear. And maintainability--probably the most important characteristic of any language long term--isn't covered very well either.
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".
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
--
Verbosity = ( 1 / Expressiveness )
Where Cobol and RPG, the languages that run business?
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.
Long meaningful identifiers are useful. Needing 5 lines of setup for each API call is annoying, particularly if those 5 lines are usually the same. Requiring lots of redundant long keywords to "look more like English" is annoying. Large standard libraries that let you remove most of the tedious parts from your code are useful.
Every time I see one of these things, OCaml always rocks it. I wonder why it never caught on to a greater degree?
CAN HAS LOLCODE?
KTHXBYE
It would be better if it was extended to support classes.
"C is available on all modern platforms, C has the best compiler of all time on it's side GCC"
Since when is GCC the best compiler of all time? I'm no expert but I've seen a lot of people complain about GCC, and I'm sure I've read that Intel has a much faster C Compiler.
This kind of fits in with my thinking.
When I was starting out in programming, I just wanted results. I wasn't concerned about performance because the computer was a million times faster than me. I was most concerned about how many "non-vital" keywords were necessary to describe what I wanted the machine to do (e.g. "void main(...)" isn't *vital* because it's just boilerplate. However "if", "for", "while" etc. would be vital - and even for/while are just cousins), and how many of the vital keywords (i.e. those that specifically interfered with the way my program would *actually* operate... a "static" here or there would hardly matter in the course of most programs) were "obvious". Java failed miserably at this... I mean, come on: System.out.println() and the standard wrapping take up too much room.
So, BASIC was an *ideal* first language (sorry, but it was, and the reason nobody uses it much now is because EVERYONE has used it and moved on to something else - doesn't mean it "breaks" people). In this regard, even things like C aren't too bad - 30-50 keywords / operators depending on the flavour, all quite simple - you could memorise them perfectly in an afternoon. However things like Forth and Perl can be hideous.
And even C++ is tending towards the stupid. Believe it or not, even things like bash scripting come out quite well under that test. And, to me, that correlates with the amount of effort I have to put in to write in a particular language. If I just want to automate something, bash scripting is fast and easy. Most of the stuff I write is a "one-job program" that will never be reused. If I want to write a program to work something out or show somebody how something is done programmatically, BASIC is a *perfect* prototyping language (no standard boilerplate, no guessing obscure keywords, etc.). If I want to write a program that does things fast, or accurately, or precisely, or for something else to build upon, C is perfect.
I see no real need to learn other languages in depth past what I'm required to know for my work. I have *zero* interest in spending weeks and weeks and weeks learning YAPL (Yet Another Programming Language) just to spent 90% of that time memorising obscure keywords, boilerplate and the language's shortcuts to things like vectors, string parsing, etc. If I was going to do that, I'd just learn a C library or similar.
I think that these graphs correlate quite well with that thinking. Let's be honest, 99% of programming is reusing other code or shortcuts - short of programming in a Turing machine, C is one of the simplest languages to learn because it *doesn't* have a million shortcuts... you want to iterate over an array or create a hash / linked list, etc. you have to do it yourself from basic elements. In modern programming, that means a one line include of a well-written library. As far as I was concerned when learning it, even the "pointer++ increases by the size of the pointer" was far too smarty-pants for me, but incredibly useful.
But with C++, I instantly lost interest because it's just too damn verbose to do a simple job. Java OOP is slightly better but still nasty once things get complicated and the underlying "functional" language is basically a C-a-like.
I'm a fuddy-duddy. Old fashioned. If I write a program, the damn computer will damn well do instruction 1 followed by instruction 2 with the minimum of flying off into libraries and class systems. If I want 4 bytes of memory to change type, then I will damn well have them change type. And I'll even get to specify *what* 4 bytes of RAM if I want and I'll clean up after them if it's necessary. That's how I think, so things like C match perfectly when I want to code. The fact that C is damn powerful, fast, low-level and so common also add to it's appeal.
I worry about what will happen when people *only* code in OOP languages. The abstraction is so large that people forget that they are still telling a computer to handle bits and bytes and suddenly they get lazy. M
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
C has never caught on for web development, unless you consider C#.
I thing that browser based applications are going to be even more common in the future.
Contexts can be deceiving.
Be careful not to use these charts to decide what language to learn or what language is better for a given solution.
Let's remember the web server ecosystems: cgi, c#, perl, java, python, php, ruby.
A given algorithm implemented in you language of choice can give you the upper hand
and instant notoriety; but running the whole operation (labor/maintenance/testing) goes far beyond
controlled environment testing.
Lately I've been thinking that
the more powerful solution (language wise) is the one that you can build and tear down from scratch in less time/effort.
That gives you more confidence to try new/innovative solutions.
my 2 cents.
- these are not the droids you are looking for -
Where's Ada?
Computer algebra systems are high level programming language. Writing good code does not need
documentation. The code itself shows what is done. Here is an example which takes two pictures
and procuces a GIF movie interpolating them:
A=Import["image1.jpg"]; B=Import["image2.jpg"];
width=Length[A[[1,1]]]; height=Length[A[[1]]];
ImageInterpolate[t_]:=Image[(t A[[1]]+B[[1]] (1-t)),Byte,ColorSpace->RGB,ImageSize->{width,height}];
Export["mix.gif",Table[ImageInterpolate[k/50],{k,0,50}],"GIF"]
It takes over a minute to process. A simple C program doing the same is a multiple times larger but also
needs multiple less time to process. But it needs to be documented because even simple things like
reading in a picture
fgets(buffer,1025,in);
if(strncmp(buffer,"P6",2)){
fprintf(stderr,"Unsupported file format (need PPM raw)\n");
exit(1);
}
do fgets(buffer,1025,in); while(*buffer == '#'); // get picture dimension
x_size = atoi(strtok(buffer," "));
y_size = atoi(strtok(NULL," "));
fgets(buffer,1025,in); // get color map size
c_size = atoi(buffer);
if((image = (char *) malloc(3*x_size*y_size*sizeof(char)))==NULL){
fprintf(stderr,"Memory allocation error while loading picture\n");
exit(1);
}
i = 0;
ptr = image;
while(!feof(in) && i<3*x_size*y_size){ *ptr++ = fgetc(in); i++;}
fclose(in);
But C it is worth the effort. For more advanced image manipulation tasks for example,
Mathematica often can no more be used, due to memory or just because it takes too long
(Math link does not help here very much since objects like a movie (a vector of images) can just
not be fed into computer algebra systems without getting into memory problems, which deals with a movie as a whole).
For computer vision stuff for example, one needs to deal with large chunks of the entire movie).
While the simplicity of programming with high level programming languages is compelling, speed often matters.
There is an other nice benefit of a simple language like C: the code will work in 20 years. Computer algebra
systems evolve very fast and much what is done today does not work tomorrow any more in a new version. Higher
level languages evolve also faster. And large junks of internal CAS code are a "black box" invisible for the
user. Both worlds makes sense: the low level primitive, transparent and fast low level language and the slower, but
extremely elegant high level language.
I, for one, am disappointed that a whole treasure trove of languages was ignored by this study.
I wish D was one of the contenders. It'd be shown pretty far to the lower left I'm betting.
Why OpalCalc is the best Windows calc
C++ got a better score. Am I reading this right?
First off, he presents the big chart twice. The second version is meant to compare functional languages with imperative languages, but it's also small enough to fit on my screen, so if you're browsing the article, you might want to look at that one first.
His "obsolete" sector is really more like a special-purpose sector. For instance, Erlang shows up in the obsolete sector, but that's because Erlang wasn't designed to be especially terse or fast. Erlang was designed to be fault-tolerant and automatically parallelizable. Io also ends up looking lousy, but Io also wast designed to be terse and fast; it was designed to be small and simple.
The biggest surprise for me was the high performance of some of the implementations of functional programming languages, even in cases where the particular languages aren't generally known for being implementable in a very efficient way. Two of the best-performing languages are stalin (an implementation of scheme/lisp) and mlton (an implementation of ml). However, as the author notes, it's common to find that if you aren't sufficiently wizardly with fp techniques, you may write fp code that performs much, much worse than the optimal; that was my own experience with ocaml, for instance.
The choice of a linear scale for performance can be a little misleading. For instance, csharp comes out looking like it's not such a great performer, and yet its performance is never worse than the best-performing language by more than a factor of 2 on any task. Typically, if two languages differ by only a factor of 2 in speed, then speed isn't an important factor for choosing between them. The real thing to look out for is that some of the languages seem to have performance that's a gazillion times worse than normal on certain specific tasks.
Many of the languages are hard to find, because they're listed by the names of their implementations. In particular, g95 is an implementation of fortran.
Find free books.
...that only languages that only remain in usage due to rewriting the programs written in them being too expensive to justify doing so counted as "real languages".
I like C, too, but one chooses ones language for the task at hand.
These sorts of things never fail to to amaze me.
The verbs, nouns, semantics and such used in a given programming language have nothing, I repeat... NOTHING to do with performance!
What does have to do with performance is the talent of the compiler / interpreter author, nothing more, nothing less.
C implements ++ and so forth and so on. Pascal does not, you have to express it as var := var + x or in some implementations as inc(var) or inc(var,100). The smart compiler / interpreter author would implement those in the fastest possible way regardless of the particular language.
The one metric that has real meaning is programmer enjoyment. Do you prefer terseness over verbosity or something in between. Does this languages flow amke you truly appreciate working with it.
The only other real metric that has any true meaning is again the talent of the compiler / interpreter author. Was the the language parser built so that it can unfold complex statements that are often required to express certain ideas and perform certain operations. Does the language implement your favorite expression, eg: ++ , or something like that, which again harkens back to programmer enjoyment.
So what it really leaves us with is, "Do you enjoy using that language?" and only you, the programmer can asnwer that question.
Hey KID! Yeah you, get the fuck off my lawn!
These graphs are great, but it would be nice to see the X axis expressed logarithmically for a greater range of time tests.
Why OpalCalc is the best Windows calc
I got to 'void main' and stopped reading.
I agree with you for the most part, but I've found that in C it is really difficult to do keep track of large numbers of different physically-representable constructs. If you end up doing this you get to have a lot of "fun" with structures within structures, especially if you decide to change something at a fundamental level. So, for that kind of purpose I tend to switch over to C++ for it's C-like OOP goodness.
However, I strongly believe that OOP languages are frequently used inappropriately. I believe Java is a perfect example of this, as you pointed out it is not necessary to represent the concept of "output data to the console" as several different layers of objects. On a side note, switching to C++ pisses me off in some applications since C++ doesn't include support for C99 complex numbers (representing these numbers w/ classes is, IMHO, stupid).
Servers are cheap and are becoming cheaper all the time. It's much cheaper to load balance between multiple servers or upgrade current servers when necessary, than it is to pay programmers to code in a verbose language, especially for new companies or products that aren't doing millions of transactions everyday.
Performance isn't all about processor efficiency.
Ha ha. Good joke. You've forgotten the most important feature "needed in a great programming lang": higher-order and first-class functions with proper closures. Oh wait, C doesn't have that.
Any truly great statically typed language will also have at least algebraic data types, parametric polymorphism (even C++ only has ad-hoc polymorphism), type constructors and functions, maybe even a Turing complete type system (heh). C doesn't have any of those.
Even aside from types, great languages should include tail-call optimization, pattern matching and hygienic macros (CPP macros are a bad joke).
Now don't get me wrong. C is a great portable assembly language. It's close to the metal, widely known and easy to read. But as far as programming languages go, C feature poor.
that's where
Of course the "right" tool is always context-dependent. If I were a grad student already familiar with that CAS system and needed to process a dozen images for a project I know which language I would chose: the CAS. If it takes me 5 minutes to write it in CAS and half an hour to process the images I'm out 35 minutes of my time. Say it only took me 30 minutes to write the C code and seconds to do the processing. I would still go with the CAS because I can go grab a coffee while the processing happens and I don't have to fight with C.
If I had thousands of images to work with I would take the time to learn a faster executing language.
Also imagine that maybe I don't _have_ to make this program, but I have an idea that I think could give interesting results. I'm much more likely to go ahead and write the code if it is fast and easy to do so. Maybe the implementation isn't the fastest, but I can see if it does something interesting. I could always go back and implement it in C if I found it really useful. I may just brush off the idea all together if it meant a long, painful coding process.
I have to say I was really surprised by Lua, and especially LuaJIT.
It has me wondering why it's not used more often. It seems like a really simple, clean language, with a fast implementation.
Why isn't it used as often as say, Python, Perl, or Ruby?
I know it's been used in game scripting, but why not elsewhere?
I know very little about Lua--I hadn't paid much attention to it now, but are there people who have considered using it over another traditional scripting language? Why did they adopt it or not adopt it? Lua seems very nice.
Zing!
What's there trollish in that post? It's just a shortcut to say some evidence is needed for that extraordinary claim, especially considering APL is usually an interpreted language.
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
Then you just have to build in the features you need, I've personally made some major libs for C, I made a polymorphic array with poly data type support and special list methods etc..., C is very flexible language.
The problem with all the high level one is that you get everything given to you and you don't nessary understand it. For instance, polymorphism, how many programmers actually understand it.
Actually the thing I'm most interested in doing is making my own language, I know it would be primitive and hard but I would think it would be enjoyable.
I think your statement is strictly speaking true but not useful in practice.
Here's what I mean: strictly speaking, with unlimited intelligence on the compiler's part, the compiler can understand what a program does and rewrite it completely as it wishes to conform to the same behavior. This means any turing-complete language can have the same performance, with a sufficiently intelligent compiler
In practice and in current times, however, a language's features determine how well the state-of-the-art in compilers can optimize a program. To give a very simple example... You don't see compilers inserting statements to free memory in Java programs, even though that would sometimes make them faster than running them with a garbage collector as happens in practice.
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
You realise C++ does exactly what you describe, with the exact same keywords as C, right?
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.
Just to nitpick ... I can output to the console with one character if I choose. It's quite easy.
import static com.jezner.libraries.io.Console.p;
public class Test {
public static void main(String[] args) {
p("I am writing to the console");
}
}
All the p method does is encapsulate the "System.out.println()" method. Using a static import, you don't need to reference any objects. But you knew that, didn't you?
The wikipedia article that you referenced for parametric polymorphism contradicts your claim that C++ only has ad-hoc polymorphism. The higher-order article also points out that C supports one type of higher-order function, a function that takes another function as an argument. First-class functions cannot be implemented without reflection or some ability to compile code at runtime (JavaScript's eval for example); not having them in a natively compiled language like C makes sense.
Calling C feature poor is the same as calling "the metal" feature poor.
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.
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
"It would be better if it was extended to support classes."
That's what Satan whispered into Strostuf(sp?)'s ear and see where that led us - 2 decades of hell and still counting...
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
So would C++
*ducks*
Performance is created by the compiler, not the language. A C program compiled with a shitty compiler is going to run slower than a Ruby one in a good VM, even though C is running native on the CPU. For that matter, what if I take the C code and compile it with the CLR as a VM target?
I wish people would stop trying to compare languages by performance, it does not make any sense. The only language it makes any sense for at all is assembler.
Dork
Yeah! Get off my lawn!
"I like it when the red water comes out.."
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).
~I'm sure he would definitely like to. But he broke the necessary keyboard~
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I'm sure there are others, but I have work to do.
It seems odd to me that the Smalltalk implementations are all so far to the right and so far up, especially the latter. Smalltalk is usually considered to have a very high amount of bang per LOC, at least 15 times more than C++. If they are considering superclasses in the code size count are they considering libc for gcc, or the entire dotNet libraries for C#?
I have to wonder how good the smalltalkers were that implemented the benchmarks. Until you get your head around it, smalltalk code is bloated. Then as you learn to think the right way your code shrinks to a beautifully expressive minimalism.
First-class functions most definately do not require reflection or run-time compileation. I know because I've implemented them in two different compilers I've written. If you don't believe me, look in any compiler book that covers the implementation of closures.
C being a natively compiled language is no excuse for it not having first-class functions with proper closures. (Technically C already has first-class functions, but they carry no dynamic closures.)
In all of these features you mention (e.g. polymorphism in C++, higher-order functions in C), their implementations are broken half implementations of the full ideas. Even if they are technically present, they don't fulfill the spirit of the ideas.
And yes, "the metal" is feature poor when it comes to expressiveness. It's not a question of whether I can make the machine do what I want, but rather how hard I have to work to make the machine do what I want.
At least half the things I mentioned cannot be easily implemented as libs in C. E.g. I'm guessing your polymorphic array isn't statically type checked which is what is usually meant with parametric polymorphism.
You could build them with layers on top of C (e.g. "cfront" the original C++ compiler), but you could say that about any Turing complete language. After all a compiler is just a front-end for machine code. The question isn't what features could be added, but rather what features it has.
I actually agree without about the problems of getting everything given to you. Which is why everyone should implement their own compiler or even interpreter for a high level language early in their carrier. (Take a class or read a book on it though. If you try to invent it on your own, you won't get as much out of it because you would have learned how you would implement it and not how it is actually implemented by the experts.)
C is the only programming language you need if you are a competent programmer. A good assembler is nice if the compiler isn't up to snuff.
I agree with you, that I wont get much hands on value out of building my own compiler / language but the amount of knowledge I can gain from taking ont he project would be execellent.
Your also right in assuming the polymorphic array, I called the Marray, was not staticly typed. The array was a complex method of varable agrument lists and macros and etc... It took probley 50 + hours of work but I was able to finish it. and it was a very good project to future my understanding of C which went from good to excellent. I believe in understanding a language in and out and around before learning another.
Personally I'd rather only know 5 extrememly well like the back of my hand then know 12 only moderitly well.
the kind that applies the detail you are looking or right now, but no others. Oh, yes, I really mean right now, whether or not you know what it is. That's ideal.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
require 'hornetseye'
include Hornetseye
a = MultiArray.load_rgb24 'image1.jpg'
b = MultiArray.load_rgb24 'image2.jpg'
output = MEncoderOutput.new 'test.avi', 15
for k in 0..50
output.write a * ( k / 50.0 ) + b * ( ( 50.0 - k ) / 50.0 )
end
I happen to develop a Ruby library which can be applied to this problem. In this case it generates the 50 transitional frames (640x480) in less than 10 seconds. I tried GIF first, but generating GIF is indeed very slow, since it requires global colour-indexing. So this may be the real performance problem in your example. Even so you should use Ruby
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.
Is FORTH the language of programmable HPs?
Improper use of pointers in C is the number 1 cause of programs that appear to work when they really don't.
C++ can indeed be used as a "better C". And some features such as inheritance are best left alone or used very sparingly. It's not a bad choice of language used carefully but it gives the programmer a lot of room to go wrong or over-complicate the solution. Also for a long time many compilers were buggy or failed standards compliance in one way or another - they're better now, but still not 100%.
You are correct that browsers are the future, simply due to the easy of deployment and lack of needed installing.
However, not all applications can be web-ified, and all browsers need programing and a OS to run on. C is a good choice for the necessarily low-level parts of a computer system. C++ may also be a choice, but I find its features unnecessary in the lowest levels of a OS, its more geared towards the higher levels such as GUI and application toolkits.
In sort: like COBOL, C is not going anywhere and will still be actively used for the forseeable future, but also like COBOL, its role will be more specialized.
You should not draw too many conclusions about the results of those two without taking into account the fact that both are whole-program optimizing compilers. Those two systems just do not support separate compilation of individual source files; if you change one line of one file in your program, every file must be recompiled.
This type of compiler has a performance advantage over the more common separate compilation systems, simply because it can inline anything anywhere, and thus optimize far more aggressively. But it's next to useless for developing large software systems, and thus mostly really useful only for writing smallish programs, in very high-level style, that perform some really expensive computations really fast.
Are you adequate?
Java is smoking fast as long as the machine running it has a TB of ram for each hello world app.
Got Code?
It's funny that you made an error in the simplest one....
Yep, that's why Lua kicks ass too. Simple, easy to learn/memorize yet very powerful.
OCaml programs aren't shorter than scripting languages, and they're limited to a curses interface at best. Together with its speed, OCaml gives off the impression of being a language you'd reach for when you write high performance, low interaction programs---like automated financial trading agents. Not many of us do that. And so not many of us use OCaml.
I looked everywhere in that graph, but I did not see Objective-C. How come that was not included?
...If I want to write a program that does things fast, or accurately, or precisely, or for something else to build upon, C is perfect...
I'm a fuddy-duddy. Old fashioned. If I write a program, the damn computer will damn well do instruction 1 followed by instruction 2 with the minimum of flying off into libraries and class systems. If I want 4 bytes of memory to change type, then I will damn well have them change type. And I'll even get to specify *what* 4 bytes of RAM if I want and I'll clean up after them if it's necessary. That's how I think, so things like C match perfectly when I want to code. The fact that C is damn powerful, fast, low-level and so common also add to it's appeal.
Well, you're also obsolete. As I understand it, optimizing compilers for C are quite free to reorder your operations, so you better learn what is considered correct programming and not just depend on the computer doing precisely what you tell it to do.
nuf sed
Table-ized A.I.
Java is killer language :-P
JMule user : http://www.jmule.org
The benchmark list compiler names and not language names. And this quite right as compiler implementations are compared.
Ada is therefore GNAT. And the other questions often asked: Fortran is g95.
Martin
PS: Of course the hole Blog is therefore wrong. It's title should relay be The speed, size and dependability of programming languages implementations.
Only languages implementations of the The Computer Language Benchmarks Game [1] are used. Read there rues and you know.
Martin
[1] http://shootout.alioth.debian.org/
Only languages implementations of the The Computer Language Benchmarks Game [1] are used. Read there rues and you know.
Martin
[1] http://shootout.alioth.debian.org/ [debian.org]
Well, we had two choices open. We can't blame Satan that choose the fast but difficult option.
Then go on the ghc mailing list and educate the people who write the compiler for Haskell and let them know, they are are getting nailed by several of these problems.
There are no such problems with the GHC compiler. As with any serious compiler, there are plenty of performance tuning issues. But those issues would be the same - or perhaps even more knotty - if GHC were written in, say, C.
And I'm sure you realize that neither you nor I will soon be educating the gurus who work on GHC. :)
Seriously, I'm and old c/c++ hand, lately turned to Python for most work because I enjoy it. But the reality is that very few of us get much choice - we have to use whatever system the PHB got swayed by back in the day.
So I wouldn't get too upset by this article, even if Java is your pride and joy - I doubt we'll see a stampede to Stalin. Java programmers will remain java programmers, just like those poor buggers who started out in Cobol are still hacking away in Cobol.
Do as you would be done to.
Computer algebra systems are high level programming language. Writing good code does not need
documentation. The code itself shows what is done.
Yes, but why does it do what it does?
Documentation doesn't say "what" the code does, it says "why" it does so. Why do you want to interpolate those two pictures? Why output them as a GIF and not as a MNG? What are the requirements of your application? What happens if the images are not in the good format? etc.
I guess you need some doc after all...
Can you explain how C++ does not support parametric polymorphism in its entirety? From the Wikipedia article you quoted:
Today it exists in Standard ML, OCaml, Ada, Haskell, C++, Visual Prolog and others. Java, C#, Visual Basic .NET and Delphi (CodeGear) have each recently introduced "generics" for parametric polymorphism.
Based on the descriptions of how parametric polymorphism works, C++ seems to support it 100%. Are you sure you aren't meaning C#, which has "generics" instead of "templates?"
I read a one-page cheat sheet and never attended a single class and passed with flying colours.
I can imagine how that experience would taint you against it. I took a few similarly lame classes at a good university.
But with C++, I instantly lost interest because it's just too damn verbose to do a simple job.
That is provably false. Since almost every C program is a valid C++ program, C++ is by definition, no more verbose than C.
Java OOP is slightly better but still nasty once things get complicated and the underlying "functional" language is basically a C-a-like.
Java is not a functional language.
I worry about what will happen when people *only* code in OOP languages. The abstraction is so large that people forget that they are still telling a computer to handle bits and bytes and suddenly they get lazy.
OOP has nothing to do with this. I can't think of an OOP language that does not allow you to handle bits and bytes.
[Java was] a C-a-like with OO
So is C++. Throughout your post you talk about how disorganized the class libraries are. If you ever code enterpreise-level software, or need to code something quickly, you will appreciate those libraries. Implementing everything yourself will result in bigger, slower code and longer development cycles.
I recommend learning C# since it has a very organized class library, and using that to dig into what OOP really is. I've even done OOP in assembly language - it's a design paradigm, with zero overhead, a few keywords, and some damn powerfully expressive shortcuts.
(Queue someone posting outdated information about virtuals to try and counter the "zero overhead" part)
Documentation doesn't say "what" the code does, it says "why" it does so.
It's also woth noting that, at some point (usually around the function level in larger projects) it can be useful to say what the code is supposed to do. Being able to see what the code does is all well and good, but you can't tell whether something is a bug or not unless you know what the code is intended to do (so you can determine whether it is actually doing it correctly). For short functions, or small projects, it is often obvious what the code is supposed to be doing from context and function names (presuming we have good function names); as things scale larger, however, exactly what a particular complex function is exactly supposed to do becomes less clear, and a little documentation is a good idea.
Craft Beer Programming T-shirts
Sieve of Eratosthenes is a good example because it has been solved but the discussion of the flaws in older solutions are quite subtle. http://www.haskell.org/pipermail/haskell-cafe/2007-February/022666.html
The "flawed" version was written by David Turner over 30 years ago. At that time, his version was meant to illustrate the expressiveness of pure functional languages, not to achieve speed.
The discussion you reference was as much about what algorithm is "the genuine sieve of Eratosthenes" as about speed. You can read all about it in O'Neil's paper that came out of that discussion, "The Genuine Sieve of Eratosthenes".
But yes, there are subtle issues in the speed of sieve algorithms. And yes, this is a good example. Compare O'Neil's work to the imperative papers she references. You can see how much easier it is to achieve the same results in a functional setting than in an imperative one.
Can you explain how C++ does not support parametric polymorphism in its entirety?
Sure! There are two main differences.
The form of polymorphism defined by templates in C++ is based on expanding and compiling a separate copy of the template code for each and every type that the template gets instantiated with. This is different than Standard ML, OCaml and Haskell where only one copy of the code gets compiled.
As an example, try to compile the following in C++:
#include <utility.h>
#include <iostream>
using namespace std;
template<typename a>
a foo(int n, a x) {
if (n == 0) return x;
else return foo(n-1, make_pair(x, 17)).first;
}
int main(int argc, char** argv) {
cout << foo(argc, argv[0]);
return 0;
}
If I constructed that example right, you C++ compiler will either reject that program or go into an infinite loop trying to compile it. This is because depending on the value of argc, the foo template must be instantiated for string and pair<string,int> and pair<pair<string, int>, int>, etc.
On the other hand the equivalent Haskell program poses no problem to the compiler:
import System
foo :: Int -> a -> a
foo n x =
if n == 0
then x
else fst (foo (n-1) (x, 17))
main = do
args <- getArgs
print (foo (length args) (head args))
The second difference is that in the implementations of parametric polymorphism seen in languages like Haskell, the parametric argument must be treated opaquely. In C++ the template argument types are known at compile time and the language allows your program to use that knowledge (e.g. template based type dispatch). This can be seen as either an advantage (yea! I can do more things) or a disadvantage (boo! the template/function type doesn't express all the assumptions about the type that the template/function makes). Regardless of whether it is an advantage or disadvantage, it is a natural consequence of whether or not the code gets expanded for each and every type.
At the end of the day C++ template polymorphism is to parametric polymorphism as macros are to functions. Both templates and macros are based on expanding code(*) and thus may inspect their arguments at compile time. On the other hand parametric polymorphism and functions do not expand code and at compile time must treat their arguments as opaque.
P.S. Some things said here may change with the introduction of "concepts" in C++0x.
(*) Except templates keep a cache of recent expansions to ruse where macros usually do not.
This is from Dead Poets' Society, isn't it?
I sound my barbaric yacc.
Towards the Singularity.
So is every program written in such a language going to include a JIT compiler? None of those features you describe are going to be available in any language that has performance comparable to C.
The only real difference between Java and C execution model (aside from better defined semantics in Java) is that Java does the translation in software, at run-time, taking into account performance characteristics of both the running program and the underlying hardware.
Java is a garbage-collected language. Garbage collection comes at a cost in performance AND memory. This cost may not be huge in most benchmarks, but there are some benchmarks where it is going to be. Which isn't to say the guys who came up with java were dumb... It so happens that you cannot be safe from pointer errors in a language where the programmer can free memory.
Also java has all that cool introspection/reflection functionality... The rather weaker but similar run time type information in C++ is a compile time switch, because it causes a significant memory overhead in some cases (when there are many small objects).
Some features have a price. You may want to pay that price (hell, I mostly program in python these days!), but don't delude yourself you're not paying any.
So is every program written in such a language going to include a JIT compiler?
No! None of these features require a JIT. (e.g. Haskell/GHC compiled programs do not include a JIT.)
Which of these features do you think requires a JIT? If you want, I can explain how it can be implemented without one. (Frankly implementing them with a JIT would be a silly way to do things.)
Enjoyable post. Thanks.
Now don't get me wrong. C is a great portable assembly language. It's close to the metal, widely known and easy to read. But as far as programming languages go, C feature poor.
I would agree with this-- and with all these now deprecated functions (replaced with "safe" ones) designed to eliminate programmer bad habits, it's become something of a nightmare...
This is meant to be an easy example and a solved one, how this happens very naturally. I know this is easy to fix, that's why it is easy to see. The "expressive", "natural" version being quadratic is the point. As for easier, agreed. I don't think functional languages are worse by any means, but we (meaning programmers) are less skilled at this point at avoiding these sorts of inefficiencies.
Ha ha. Good joke. You've forgotten the most important feature "needed in a great programming lang": higher-order and first-class functions with proper closures. Oh wait, C doesn't have that.
Any truly great statically typed language will also have at least algebraic data types, parametric polymorphism (even C++ only has ad-hoc polymorphism), type constructors and functions, maybe even a Turing complete type system (heh). C doesn't have any of those.
Even aside from types, great languages should include tail-call optimization, pattern matching and hygienic macros (CPP macros are a bad joke).
Now don't get me wrong. C is a great portable assembly language. It's close to the metal, widely known and easy to read. But as far as programming languages go, C feature poor.
test