Forgot your password?
Programming IT Technology

Comparing the Size, Speed, and Dependability of Programming Languages 491

Posted by Soulskill
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."
This discussion has been archived. No new comments can be posted.

Comparing the Size, Speed, and Dependability of Programming Languages

Comments Filter:
  • what about APL (Score:2, Insightful)

    by goombah99 (560566)

    APL was faster than C and there has never been a more terse language.

    • Re:what about APL (Score:5, Informative)

      by mdmkolbe (944892) on Sunday May 31, 2009 @12:04PM (#28158747)

      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.

      • Writing APL (Score:3, Funny)

        by DrYak (748999)

        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~

  • by eldavojohn (898314) * < minus bsd> on Sunday May 31, 2009 @10:46AM (#28158223) Journal
    This plots verbosity against slowness making:

    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.

    • by xZgf6xHx2uhoAj9D (1160707) on Sunday May 31, 2009 @10:50AM (#28158241)
      I agree totally about the need for verbosity. I'm a fan of Donald Knuth [] in this regard.
      • by timeOday (582209) on Sunday May 31, 2009 @01:32PM (#28159441)
        I'm not sure we're sharing a definition of "verbosity. Perhaps the useful definition here is "the inverse of expressiveness." Of course expressiveness is inherently relative to what is important in a given application. For most purposes, assembler is hopelessly verbose, or lacking in expressiveness, since most of what you're writing out is meaningless detail. But for certain other purposes (performance) those details become crucial, so for that application only assembler has the necessary expressiveness. Again, I am not contradicting myself by saying assembler is both lacking in expressiveness and high in expressiveness, it depends on the application. I've heard German is a fantastic language for writing technical legal documents, whereas the Inuit language is supposedly very good for describing cold weather and snow.
    • Verbosity = ( 1 / Expressiveness )

    • by Timothy Brownawell (627747) <> on Sunday May 31, 2009 @11:18AM (#28158425) Homepage Journal

      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.

    • by jbolden (176878) on Sunday May 31, 2009 @11:30AM (#28158517) Homepage

      Look where those languages are on the chart.

      Java mostly against the left wall (i.e. mostly as fast as C). Perl right against the bottom (i.e. very small code).

      It appears to me what this showed was that people like the walls.

    • by ucblockhead (63650) on Sunday May 31, 2009 @11:49AM (#28158649) Homepage Journal

      The author is not talking about verbosity in bytes. He's talking about verbosity in code points. Talked about in this way, a thirty character variable name is no more verbose than a single character variable name.

      • Re: (Score:3, Informative)

        by bcrowell (177657)

        The author is not talking about verbosity in bytes. He's talking about verbosity in code points. Talked about in this way, a thirty character variable name is no more verbose than a single character variable name.

        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.

    • Re: (Score:3, Interesting)

      by nametaken (610866)

      It didn't seem to me like being concise or verbose was a help or hindrance aside from his comment. Per those graphs I could say I want something as fast as Java (how often have you heard that on /.), but a little less verbose... "oh, csharp might be worth a look".

      I found it interesting.

    • by Twinbee (767046)

      Perhaps Java, C++ and Perl prevail because they're more established. It doesn't mean they're necessarily objectively better.

      The other factor is that although variable names are often useful if they're long, 'verbosity' can/should count the number of 'words' (and symbols?) in the code, which is obviously shorter than a line, and longer than a single character. I hope he's taking this into account.

    • by tknd (979052) on Sunday May 31, 2009 @12:20PM (#28158895)

      There's good verbosity and bad verbosity. Let's take for example java's System.out.println. This is bad because it is such a common function that you are bound to use it over and over again but good of course because you know it is not a keyword (it comes from the System.out library). The result is something twice as long as it needs to be and chews up screen space. As a human reader of the source, this becomes cumbersome and harder to read the full program.

      Languages that can allow you to pull in identifiers from other scopes can solve this issue while reducing the bad kind of verbosity. For example in perl there is something called Exporter which allows defined symbols by the source package to be imported into the current scope through syntax like:

      use Some::Package qw( someFunction );

      Now instead of Some::Package::someFunction, for the rest of the file I can just do someFunction since I've already declared I'm importing it at the top. If the reader is interested in knowing where someFunction comes from, searching from the top of the file will reveal the use Some::Package qw( someFunction ); line.

    • Re: (Score:3, Insightful)

      by bcrowell (177657)

      The justice or injustice of your comment depends strongly on what metric they're using for size, and a lot of the replies to your comment have been speculating about what the metric really is. Okay, if you start with the game's FAQ [], it looks like there are three different metric they actually computed:

      1. size of the source code, in bytes
      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 appli
      • by cryptoluddite (658517) on Sunday May 31, 2009 @03:17PM (#28160277)

        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.

    • Re: (Score:3, Informative)

      by s_p_oneil (795792)

      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.

      • by ArcadeNut (85398) on Sunday May 31, 2009 @04:42PM (#28161025) Homepage

        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.

        This is where so many programers go wrong. The code is self documenting in the respect that you know it's checking the age of something to see if it was 7 days ago, but you have no idea WHY it's checking that. Why not 6 days ago? What if it's 8 days ago?

        Comments should say WHAT and WHY you are doing something not HOW you are doing it. The HOW is the code itself. If someone was to look at that code, do they know what your intent was? Were you looking for something that was exactly 7 days old, or something 7 days old or older.

  • It would have been right in the corner for conciseness. One-line programs are fairly standard, but can accomplish quite a lot.
  • Related site... (Score:4, Informative)

    by viyh (620825) on Sunday May 31, 2009 @10:57AM (#28158283) Homepage
    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): []
    • Re:Related site... (Score:5, Insightful)

      by alvinrod (889928) on Sunday May 31, 2009 @11:34AM (#28158533)

      What's so special about it? It looks just like a regular perl program to me. /ducks

      • Re: (Score:2, Insightful)

        by RenHoek (101570)

        I think that any language that allows such obfuscation is NOT a good language. A programming language should be brief, powerful but still readable in all circumstances.

        • Re:Related site... (Score:5, Insightful)

          by viyh (620825) on Sunday May 31, 2009 @11:49AM (#28158651) Homepage
          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.
        • Re:Related site... (Score:4, Insightful)

          by CastrTroy (595695) on Sunday May 31, 2009 @12:33PM (#28158983) Homepage
          Run Javascript through an obfuscator, and see how readable it is. "readable in all circumstances" can't possibly exist. Anybody could make unreadable code in any language.
  • Scala (Score:3, Interesting)

    by Laz10 (708792) on Sunday May 31, 2009 @11:01AM (#28158307)
    I am surprised how they manage to get scala to perform so much worse than pure java.

    Scala compiles to pure java .class files and uses static typing and the makes claim that the bytecodes are almost identical.

    I wonder if the benchmarks are executed in the same environment. has a Gentoo label behind the java benchmarks, but not the Scala one.

    • Re:Scala (Score:5, Insightful)

      by jbolden (176878) on Sunday May 31, 2009 @11:34AM (#28158531) Homepage

      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.

    • Re: (Score:3, Interesting)

      by kipton (135584)

      I am surprised how they manage to get scala to perform so much worse than pure java.

      Scala does generate optimized Java byte code. Pretty much any Java code can be directly ported to Scala with nearly identical performance.

      The Scala benchmarks perform worsethan Java's, on average, for two main reasons. The first is that some of the tasks have been implemented using higher level code (think memory allocation and closure generation), trading conciseness for performance. The second is that the Scala benchmarks haven't been tuned and tweaked to the extent that the Java ones have.

      Then there are

    • Re: (Score:3, Insightful)

      by DetpackJump (1219130)
      I was curious about that too, so I'm looking at the code. The Java implementation seems to be importing a non-java library, jgmplib. Anyone know what is going on here?
  • Java (Score:3, Funny)

    by Allicorn (175921) on Sunday May 31, 2009 @11:06AM (#28158331) Homepage

    Oh but Java is a plodding, stumbling, lumbering, slug of slowness. All thoroughly indoctrinated Slashdotters know that already. No need to RTFA...

    • Re: (Score:3, Interesting)

      by Timmmm (636430)

      "Oh but Java is a plodding, stumbling, lumbering, slug of slowness."

      Java does well in these kinds of synthetic tests because it doesn't have to invoke the garbage collector. All the *real life* java programs I use are significantly slower than roughly equivalent C++ programs. E.g. compare NetBeans to Visual Studio, or Azereus to uTorrent. I tried Eclipse once but it was unusably slow.

      Find me a speedy desktop Java program and I'll change my mind about it.

  • 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!"

  • Pet peeve (Score:5, Insightful)

    by QuoteMstr (55051) <> on Sunday May 31, 2009 @11:11AM (#28158375)

    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".

    • Point being, describing a programming language as "fast" makes about as much senese as describing a natural, human language as "smart".

      Yeah, will if human language isn't smart, just what language DO you suggest we use???

      Goddam Vorons... troll ever fucking thread they read.

    • The article does confuse a language with it's implementation. GCC, for instance, is NOT a language!
      • Re: (Score:3, Informative)

        by someone1234 (830754)

        I thought it compares implementations.
        If you look harder, you'll see multiple different implementations of the same language.

    • Re:Pet peeve (Score:4, Insightful)

      by jilles (20976) on Sunday May 31, 2009 @04:16PM (#28160795) Homepage

      Yes of course you are right. And more recently we actually have languages with coherent and consistent behavior across implementations (somewhat of a novelty, just look at C implementations). There's several Ruby interpreters that run the Rails framework now. The fastest one (or so it is claimed often) is JRuby, which runs on top of the Java virtual machine, which has has quite many implementations on a wide variety of hardware optimized for running on e.g. embedded hardware or on CPUs with thousands of cores and impressive levels of compatibility given these differences. So saying language X is faster than language Y is a quite meaningless statement these days. Faster on what, and under what conditions and at what required level of stability, and with what kind of benchmark? Most C programs are fast, except they have all but 1 core on the CPU idling because threading and concurrency are very hard to bolt on to a C program. Which is why some performance critical messaging servers are done in languages like Erlang.

      Most C programmers believe it is the closest thing to native aside from assembler. Probably correct if you ignore 40 years of progress in the hardware world but downright naive in light of modern day X86 processors. Technically x86 is not a native instruction set anymore but a virtual machine language that happens to have an in hardware translation to the 'real' instruction set. Like all such translations, it comes at a cost of lost flexibility, and indeed performance. But it is worth avoiding having to rewrite all those pesky compilers. So rather than shatter the assumptions C programmers make, they actually support them by sacrificing transistors. 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. That in a nutshell is why the LLVM project exists to do the same for C programs (and indeed many other languages, including Java).

      Of course you have to take into account the levels of abstraction and indirection provided in application frameworks as well. Those come at a cost and that cost is typically high in scripting languages (but you get so much in return). Java is often unfairly compared to C. I say unfairly here because it is usually a comparison of application frameworks rather than the language implementation. Java is in 'laboratory' conditions quite fast, even comparable to C and applies all the same performance optimizations (and then some). Except, nobody programs Java that way (except some dude at work who managed to produce the suckiest Java class ever, different story) . Similarly, C mostly lacks the rich frameworks that are common in the Java world. Transcode a C program to Java and you end up with a code base that is still pretty fast (e.g. quake 2 has a Java port). Stupid people in both camps believe that it is an either-or type decision between the two and that it is somehow inherent to the language what you end up with. Clever engineers know that 95% of their code is not performance critical at all (i.e. cpu idling most of the time), and that it makes a hell of a lot of sense to do whatever is necessary to get that 5% performing as best as possible if the cost in terms of stability, productivity, security, portability, etc is low enough. That's why server-side c is not a commonly required job skill.

      That's why Apple used the llvm platform to port Mac OS X to mobile phones and why Google chose to implement a heavily customized Java vm on top of familiar C/C++ components to emulate their success. Good engineers know when to choose what. Both iphone and android are excellent achievements that move beyond the stupid status quo of wondering which language is better.

  • by RichMan (8097) on Sunday May 31, 2009 @11:11AM (#28158377) []

    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

    • Re: (Score:3, Interesting)

      by wonkavader (605434)

      If the code size attribute is measured in number of lines, I suspect that forth, which is practically an assembly language, will rank very low (near the top of the graph, if not at the very top), though it ought to be very fast (near the left). It depends so much on stack operations that I suspect its left to right ranking would depend a great deal on the processor it's running on.

      I love forth. I learned it many years ago. But I've never been in a position to use it for anything, which is a shame.

    • I wrote a little "literate" FORTH tutorial if any readers of the above comment are interested in it: jonesforth [].
    • by rbrander (73222) on Sunday May 31, 2009 @01:29PM (#28159419) Homepage

      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.

    • Re: (Score:3, Interesting)

      by skeeto (1138903)
      If you like Forth, you should check out Factor [], which is basically a modernized version of Forth (dynamically typed, no *very* low level filesystem junk that Forth has). I've recently started playing with it.
  • by jackb_guppy (204733) on Sunday May 31, 2009 @11:16AM (#28158405)

    Where Cobol and RPG, the languages that run business?

  • Ocaml (Score:4, Interesting)

    by LaminatorX (410794) <> on Sunday May 31, 2009 @11:39AM (#28158575) Homepage

    Every time I see one of these things, OCaml always rocks it. I wonder why it never caught on to a greater degree?

    • Re:Ocaml (Score:4, Insightful)

      by 16384 (21672) on Sunday May 31, 2009 @12:03PM (#28158731)
      I don't about the rest of you, but functional languages don't fit my brain, and to me it's not worth the struggle. On the other hand, procedural/OO languages are no trouble at all, and I can learn new ones quickly. I don't understand why anyone would choose lisp, scheme, etc. Maybe they were born with bigger stacks, because when working with functional languages I'll go into stack overflow mode in a jiffy :-)
      • Re:Ocaml (Score:4, Interesting)

        by Daniel Dvorkin (106857) * on Sunday May 31, 2009 @12:17PM (#28158867) Homepage Journal

        I semi-agree -- procedural languages are much closer to the way most people think, and that's why pure functional languages have remained a niche. OTOH, the power and expressiveness of functional programming is really amazing. It seems to me that this is a major reason for Python's success: it's basically a procedural language (of which OO is a subset) that makes a functional style easily available.

    • Re:Ocaml (Score:4, Interesting)

      by Anonymous Coward on Sunday May 31, 2009 @12:30PM (#28158953)

      To be honest, I have the same reaction. I love OCaml, and am frustrated by the fact it hasn't been adopted more. It seems like a no-brainer to me.

      I've been following it over time, and I think the reasons for it have become clearer to me.

      1. I think the biggest reason is hard to articulate well, but basically I think the OCaml developers are sort of unresponsive to the community, which has been embryonic as it is, and as a result there's a sense that it's not moving in directions it should be. Numerical applications, for example, are one domain where OCaml interest has really been high, but the developers have been pretty unresponsive to concerns about matrix implementations. Comments by the developers on concurrency have also puzzled a lot of people. I don't mean to sound like a troll, but I have gotten the sense over time that while OCaml is wonderful as it is, it's not changing or moving anywhere, at least as quickly as it should be (in a bad way). Haskell is a good comparison to me in this regard, as it's a language that is also functional, but not as useful in applications than it is theoretically. However, Haskell has a wonderfully strong community, it is almost a model of how a language and its implementations can grow in a productive way.

      2. OCaml is occupying a difficult position, in that people who want cold, hard performance with stable implementations will go somewhere else (e.g., C); people who want theoretically elegant implementations will go somewhere else (e.g., Lisp, haskell), and people who want something simple will go somewhere else still (e.g., Python, Ruby). OCaml in many ways occupies all three places, but not quite as well as any one of them.

      Having said all of that, it's important to keep in mind that Microsoft is sort of pushing F# for 2010. F# is essentially a Microsoft implementation of OCaml for the CLR--very very close to OCaml--so maybe if F# takes off, there will be a big push toward OCaml.

      It's one of the few times I could say that Microsoft is really on target technically, and might actually move the numerical computing field forward.

      • Re:Ocaml (Score:4, Interesting)

        by david.given (6740) <dg AT cowlark DOT com> on Sunday May 31, 2009 @02:44PM (#28160047) Homepage Journal

        A while back I tried implementing a project in OCaml, because it looked awesome, and I wanted to explore it.

        I found a lot to like about it; it's fast, reasonably clear, has got lots of awesome functional programming features that I actually found myself using while also having a powerful set of imperative programming features for the rest of the logic, and in general worked rather well.

        However, I kept finding myself running again and again into problems caused by the same conceptual design issue, which eventually led to me giving up in frustration.

        The problem was this: an OCaml program is structured as a series of statements, each of which mutates the program in some manner (usually by adding a definition to it). The last statement in the program typically invokes something (such as a 'main' function). The compiler ensures that your program is consistent after every statement. This means that you can't do forward declarations.

        There is an and construct that allows you to define several items of the same kind in a single statement, which is typically used to implement mutually recursive functions, but that doesn't help if you need to items of different kinds to be mutually recursive: for example, a class and an algebraic data type (which I needed to do lots, in order to implement 'object or None' semantics).

        I found this issue everywhere I looked in OCaml; the language semantics require your code dependency graph to be a tree with no cycles, and you have to structure your program strictly in bottom-up form. So not only can you not have two mutually dependent modules, you can't even put your 'main' at the top of the file for clarity.

        Now, my OCaml skills aren't particularly great, so there may be a way round this, but I spent a lot of time looking for a solution to this and didn't find one. This, and other lesser issues to do with code style and namespacing, smell unpleasantly like an academic language that hasn't really learnt to scale gracefully, and I wonder whether it would be a comfortable choice for implementing large projects. These days I'd be inclined to consider Haskell or Clean instead.

  • HAI (Score:4, Funny)

    by Anonymous Coward on Sunday May 31, 2009 @11:41AM (#28158597)
  • by ledow (319597) on Sunday May 31, 2009 @11:52AM (#28158667) Homepage

    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

  • Ruby (Score:5, Insightful)

    by RiotXIX (230569) on Sunday May 31, 2009 @11:54AM (#28158689) Journal

    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.

  • by cabazorro (601004) on Sunday May 31, 2009 @12:03PM (#28158737) Homepage Journal

    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.

  • by e**(i pi)-1 (462311) on Sunday May 31, 2009 @12:06PM (#28158775) Homepage Journal
    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}];

    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

        fprintf(stderr,"Unsupported file format (need PPM raw)\n");

      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");

      i = 0;
      ptr = image;
      while(!feof(in) && i<3*x_size*y_size){ *ptr++ = fgetc(in); i++;}

    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.
  • by bcrowell (177657) on Sunday May 31, 2009 @12:11PM (#28158809) Homepage

    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.

  • by FlyingGuy (989135) <> on Sunday May 31, 2009 @12:21PM (#28158899)

    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.

    • What does have to do with performance is the talent of the compiler / interpreter author, nothing more, nothing less.

      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 compi

    • Re: (Score:3, Insightful)

      by Twylite (234238)

      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.

      The empirical evidence then tells us that the authors of assemblers are more talented than those of C compilers, who are in turn more talented that the authors of compilers/interpreters of JITs and dynamic languages. Put another way, you're wrong.

    • by Kjella (173770) on Sunday May 31, 2009 @04:02PM (#28160675) Homepage

      I don't think that's the primary scale. I think my primary scale is:

      What level of detail control is the programmer required to and permitted to have?
      How easy is it for a developer to shoot himself (or others) in the foot?
      How often must the developer work around poor or missing language features?

      For example, there's no lower level than assembly but it has no high-level features. Java is high level but has no low-level memory and byte manipulation to speak of. I prefer C++/Qt, I have all the practical high-level functions for the quick gains, yet I can down dive to detailed C/C++ management.

      In terms of "how easy is it to shoot himself in the foot?" I think C/C++ could do much better. Doing all sorts of pointer manipulation is error prone and zero-terminated char arrays are the thing of the devil. And while C++ has exceptions I've never seen them applied consistantly and well like in Java.

      Finally, I think there should only be the need for ONE standard library, not a five library mashup that's kinda standard. Everything else should be modules usually building on top of that library. Java, C# has done it - I emulate it with Qt in C++ because I think STL/boost/whatever is not very good.

  • 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.

  • by coppro (1143801) on Sunday May 31, 2009 @03:57PM (#28160617)
    Okay, there's many problems with the benchmarks here, including in the labeling.
    • The uses of each language aren't analyzed. I've never encountered a desktop application written in Perl, nor have I ever seen a C++ web framework (I'm sure both exist, but they aren't common)
    • Dependability isn't analyzed. The title specifically says 'dependability'. I can excuse them because well-written Erlang smokes the competition in terms of reliability (Some Erlang-based servers have been running with 100% uptime for years).
    • This is not a comparison of multiple programming languages. It's a comparison of a haphazard set of environments. For instance, C and C++ are not distinguished, but the various compilers are. On the other hand, C# and F# are grouped the same, even though they operate in the same VM, with the same JIT optimizer, and so on (and Mono, on the other hand, is nowhere to be found.

    I'm sure there are others, but I have work to do.

  • by atripp (104393) on Sunday May 31, 2009 @05:41PM (#28161395)
    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: [] 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.

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.