Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comparing the Size, Speed, and Dependability of Programming Languages

Soulskill posted more than 5 years ago | from the it's-not-the-size-of-the-float dept.

Programming 491

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

cancel ×

491 comments

Sorry! There are no comments related to the filter you selected.

what about APL (2, Insightful)

goombah99 (560566) | more than 5 years ago | (#28158219)

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

Re:what about APL (-1, Troll)

rbarreira (836272) | more than 5 years ago | (#28158421)

APL was faster than C

Citation needed.

Re:what about APL (1, Informative)

Anonymous Coward | more than 5 years ago | (#28158591)

APL was faster than C

Citation needed.

no citation needed. it's matrix driven so it naturally optimizes loops better.

Re:what about APL (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28158661)

APL was faster than C

Citation needed.

I know it's trendy to say citation needed .. so yeah, doubleplus trend points for you, aren't you so cool! but you can always do your own goddamned research too. in this case it'd be an easy quick google search. you do know that, right?

Re:what about APL (1)

Anonymous Coward | more than 5 years ago | (#28158701)

Generally it's up to the one who makes the claim to provide the evidence, but whatever floats your boat.

Re:what about APL (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28158863)

Generally it's up to the one who makes the claim to provide the evidence, but whatever floats your boat.

And if this were a scientific paper or a formal debate I'd agree with you. Meanwhile, don't pretend like you have no idea what I am saying or why I am saying it, because that just makes you a douchebag. You're not really that much of a douche, are you?

Nobody on Slashdot cared about that until it got trendy to say "citation needed" as though this were Wikipedia and you know it. There's formal and then there's informal discussion and Slashdot isn't terribly formal so don't bitch when it's not treated formally. If you're interested in something, and it's that goddamned easy to find, you'll find it. You'll find it with Google faster than you'll type out your lame "citation needed" gripe. That's if you are interested in the citation and not in bitching about how someone posted of course.

Re:what about APL (0)

Anonymous Coward | more than 5 years ago | (#28158853)

It is trendy to say [Citation needed] as some asshats think the wikipedia references are funny and intelligent. So that AC failed...

It would be too nice if they would put in the effort to put in references for their conflicting position or to back up original poster... But it is so much easier to make snarky comments, eh?

Re:what about APL (1)

DavidHumus (725117) | more than 5 years ago | (#28158743)

One language that might be terser is J: see jsoftware.org.

For instance, Newton's method is written

N=: 1 : '- u % u d. 1'

(see http://www.jsoftware.com/jwiki/Essays/Newton's [jsoftware.com] Method)

However, about the claim of APL being faster than C, this is only true if you're talking about development time (which may be the most important metric). An interpreted language like APL or J might approach the execution speed of C for operations on large arrays but the interpretive overhead will always impose a performance penalty.

Re:what about APL (1)

goombah99 (560566) | more than 5 years ago | (#28158813)

APL has compilers

Re:what about APL (4, Informative)

mdmkolbe (944892) | more than 5 years ago | (#28158747)

If you would like APL to be on the list, then submit benchmarks for APL to the Shootout [debian.org] (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.

Why is Verbosity Bad? (5, Insightful)

eldavojohn (898314) | more than 5 years ago | (#28158223)

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.

Re:Why is Verbosity Bad? (5, Insightful)

xZgf6xHx2uhoAj9D (1160707) | more than 5 years ago | (#28158241)

I agree totally about the need for verbosity. I'm a fan of Donald Knuth [literateprogramming.com] in this regard.

Verbosity is bad because (3, Insightful)

Limerent Oil (1091455) | more than 5 years ago | (#28158387)

Verbosity = ( 1 / Expressiveness )

What kind of verbosity? (5, Interesting)

Timothy Brownawell (627747) | more than 5 years ago | (#28158425)

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.

Re:What kind of verbosity? (1)

dwater (72834) | more than 5 years ago | (#28158875)

> Needing 5 lines of setup for each API call is annoying, particularly if those 5 lines are usually the same.

Doesn't this sort of thing help with testing though? I guess it 'depends', but if you are testing some part of the code, then it's much easier to pass in the things it needs so that you can control it's environment - otherwise you're trying to dissect the code from within, sometimes even needing 'friend' type relationships or perhaps even making it impossible(?).

I think they call it 'dependency injection' or something like that...yup,it's in this [youtube.com] talk. I guess it's just one form of 'setup' and there are other times when it's pointless.
...or did I misunderstand the talk?

Re:What kind of verbosity? (1)

gdshaw (1015745) | more than 5 years ago | (#28158973)

I look at it this way. Verbosity that I the programmer /choose/ to add in the interests of readability is generally good.

Verbosity required by the language, the standard libraries, or some sadist who happened to write the coding standard, is almost invariably bad.

Re:Why is Verbosity Bad? (0)

Anonymous Coward | more than 5 years ago | (#28158465)

My guess is that the benchmarked code is assumed to have pretty much the same "verbosity density", so code size then directly reflects the ability of the language to express ideas concisely. Example...

Pascal:
itemCounts[ProductIdFromName(name)] := itemCounts[ProductIdFromName(name)] + 1;

C:
itemCounts[ProductIdFromName(name)]++;

Re:Why is Verbosity Bad? (1)

maxume (22995) | more than 5 years ago | (#28158471)

Counting characters is a lot less interesting than counting symbols. Of course, a language with too many symbols will be more obscure than one that makes somewhat repetitive use of a smaller set of symbols, so the whole thing is still pretty subjective.

Re:Why is Verbosity Bad? (2, Insightful)

ClosedSource (238333) | more than 5 years ago | (#28158683)

Overloading symbols is often a negative aspect. C would be a much easier language to read if "*" had a single meaning.

Re:Why is Verbosity Bad? (4, Insightful)

jbolden (176878) | more than 5 years ago | (#28158517)

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.

Re:Why is Verbosity Bad? (4, Funny)

A beautiful mind (821714) | more than 5 years ago | (#28158691)

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

True enough, but my favourite is Larry Wall.

Re:Why is Verbosity Bad? (5, Insightful)

ucblockhead (63650) | more than 5 years ago | (#28158649)

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:Why is Verbosity Bad? (2, Interesting)

nametaken (610866) | more than 5 years ago | (#28158695)

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.

Re:Why is Verbosity Bad? (1)

Twinbee (767046) | more than 5 years ago | (#28158713)

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.

Re:Why is Verbosity Bad? (2)

lethargic8 (1179029) | more than 5 years ago | (#28158745)

Perl prevails?

Re:Why is Verbosity Bad? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28158781)

Regina(Rexx) is a pretty fast and clear language. My only issue with it is how other functionality has been added such as SQL and network connections as their implementation(or maybe their documentation since there seems to be very little) doesn't seem quite as clear as using, say, PHP or Ruby. If they'd get more than a couple of developers working on the project, it could be easily transformed into something far more useful.

That said, for 2 years I ran a website entirely off of Regina(or maybe it was ooRexx..basically the same thing) and despite the limitations of the machine it was running on, it performed faster than any other scripted site I ever visited. These days with the heavy AJAX and java implementations, it'd run circles around them.

Re:Why is Verbosity Bad? (1)

mdmkolbe (944892) | more than 5 years ago | (#28158815)

I recall seeing a study that showed that bugs per line of code(*) was fairly constant across languages. (Anyone know what study that was?) Thus the fewer lines of code(*) in your program the fewer bugs. Thus more expressive languages are better.

At least that's what the study claimed.

(*) Assuming you don't "cheat" by not breaking your lines where normal programmers would.

Re:Why is Verbosity Bad? (2, Insightful)

rah1420 (234198) | more than 5 years ago | (#28158963)

(*) Assuming you don't "cheat" by not breaking your lines where normal programmers would.

And that's why I've often used "ELOC," or Executable lines of code.

An
ELOC
metric
for
this
would
count
this
as
a
single
sentence. :)

Re:Why is Verbosity Bad? (1)

Len (89493) | more than 5 years ago | (#28158861)

There seems to be an assumption in the article that "verbose" means "difficult to write" or "hard to understand". This isn't always true, in my experience. APL, for example, can be used to write programs that are masterpieces of concision, but understanding them is like solving Sudoku puzzles. Which can be fun, but isn't a productive use of a programmer's brainpower.

Re:Why is Verbosity Bad? (3, Insightful)

tknd (979052) | more than 5 years ago | (#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.

What? APL is not in the chart! (1)

AliasMarlowe (1042386) | more than 5 years ago | (#28158229)

It would have been right in the corner for conciseness. One-line programs are fairly standard, but can accomplish quite a lot.

javascript for example (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28158237)

there was a time, not long ago, you could actually click on an article on the front page to read the comments. Now you get page load errors unless you allow scripts from fsdn.org. why ?

Re:javascript for example (1)

gardyloo (512791) | more than 5 years ago | (#28158357)

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

Related site... (4, Informative)

viyh (620825) | more than 5 years ago | (#28158283)

This site [99-bottles-of-beer.net] 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 [99-bottles-of-beer.net]

Re:Related site... (4, Insightful)

alvinrod (889928) | more than 5 years ago | (#28158533)

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

Re:Related site... (1, Insightful)

RenHoek (101570) | more than 5 years ago | (#28158633)

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... (4, Insightful)

viyh (620825) | more than 5 years ago | (#28158651)

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... (3, Insightful)

CastrTroy (595695) | more than 5 years ago | (#28158983)

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.

Re:Related site... (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28158623)

So we already knew perl was the worst language in the world to write in and to have to maintain, but now we know that it's slow as hell, and no nearly as concise at it appears to be. Now that's what I call a study.

Scala (3, Interesting)

Laz10 (708792) | more than 5 years ago | (#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.
http://shootout.alioth.debian.org/ has a Gentoo label behind the java benchmarks, but not the Scala one.

Re:Scala (4, Insightful)

jbolden (176878) | more than 5 years ago | (#28158531)

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:Scala (1)

DoofusOfDeath (636671) | more than 5 years ago | (#28158855)

Functional languages in practice often implement nlog n algorithms in quadratic time or memory

We should probably distinguish between pure and impure functional languages.

Impure languages like SML and (I think) MLTON can modify arrays in-place, eliminating one of the major causes of slowness when implementing certain algorithms in a pure functional language.

Re:Scala (3, Interesting)

kipton (135584) | more than 5 years ago | (#28158819)

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 a couple benchmarks where Scala's performance is hugely worse than Java. This seems to be because the Java benchmark was implemented using optimized native libraries (big integers as I recall) or using a better algorithm. Again, Scala could achieve equivalent performance in principle, but someone needs to invest the time to update the benchmark implementations.

Re:Scala (3, Insightful)

DetpackJump (1219130) | more than 5 years ago | (#28158941)

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?

Re:Scala (1)

Ichoran (106539) | more than 5 years ago | (#28158961)

I am surprised that the benchmarks perform so much worse *without* being significantly more compact. If you're going to write compact functional code, you have to accept a bit (or a lot) of overhead. But there's no reason a Scala program should be both longer and slower than a Java one except through inattention.

Java (2, Funny)

Allicorn (175921) | more than 5 years ago | (#28158331)

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

The perfect language exists, you ignorant clod! (5, Funny)

tomhudson (43916) | more than 5 years ago | (#28158335)

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

Re:The perfect language exists, you ignorant clod! (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28158621)

I don't know if you've tried Microsoft's C#, or Apple's Objective C, but basically these are essentially big "F.U.'s" to developers.

Different customer base, same idea I guess.

Re:The perfect language exists, you ignorant clod! (1)

BorgCopyeditor (590345) | more than 5 years ago | (#28158939)

Looping constructs: "Sit on it and rotate!"

Or the syntactic sugar shorthand: "Sit and spin!"

Where are the old standards? (0)

Anonymous Coward | more than 5 years ago | (#28158369)

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.

Re:Where are the old standards? (2, Informative)

mdmkolbe (944892) | more than 5 years ago | (#28158639)

ML, Haskell, Scheme, Fortran and Common Lisp are on the list. You probably didn't notice them because they are listed by their implementation name (e.g. mlton/O'Caml, GHC, Stalin/Gambit/Ikarus/Chicken, G95, SBCL/CMUCL, etc.). The Shootout [debian.org] front page lists which implementations implement which languages.

Pet peeve (5, Insightful)

QuoteMstr (55051) | more than 5 years ago | (#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".

Re:Pet peeve (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28158463)

You dumb motherfucker there are things in the semantics specified by a language that makes one easier than the other to optimize and make fast. So while there are variations in implementations, stuff like Perl, Python and Ruby will never achieve the speed of C++.
SBCL is fast, but not as fast as hand coded C++ btw. SBCL is much faster than Ruby and Python, but that's partly because it allows stuff like optional static typing to help the compiler do its job. Ruby and Python as languages do not allow such things.

We are programmers. Who care what could THEORETICALLY EXISTS ? The only stuff that matters is what languages can DO NOW. And for NOW, speed of languages are divided in three categories : fast statically typed imperative, fast statically typed functional, slow dynamically types. C, C++, Java, C#. Haskell, Statically typed schemes and lisps, clean. ruby, python, perl, php, tcl.

Re:Pet peeve (1)

kurt555gs (309278) | more than 5 years ago | (#28158515)

C++ will never archive the speed of a good Assembly program.

Re:Pet peeve (0)

Anonymous Coward | more than 5 years ago | (#28158559)

What is your point ? did you believe that a C++ programmer would be shy to drop down to assembly when needed ? because they do.
Ton of multimedia lib such as codecs are written with assembly bits. Like the fastest software-only H264 decoder.

C++ programmers do not believe in the silver bullet. Dumb shits like Rubyists do.

Re:Pet peeve (1)

ultrabot (200914) | more than 5 years ago | (#28158773)

What is your point ? did you believe that a C++ programmer would be shy to drop down to assembly when needed ? because they do.
Ton of multimedia lib such as codecs are written with assembly bits. Like the fastest software-only H264 decoder.

C++ programmers do not believe in the silver bullet. Dumb shits like Rubyists do.

From the article:

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.

Now, I understand the kinship ruby community feels with smalltalk... Squeak performance sucks too, albeit not as badly as ruby.

Re:Pet peeve (1, Informative)

Anonymous Coward | more than 5 years ago | (#28158859)

I'd say that for a bytecode interpreted, turtles-all-the-way-down language, Squeak smalltalk performance is stellar (things are relative). Remember that Squeak manages to be faster than Ruby while implementing MOST of its core features in itself. It doesn't use lots of C code like Ruby do. Ruby has lots of core classes, like Array, FULLY implemented in C.

So Ruby is quite the crappy language. Slower than Squeak while having core stuff written in C.

Re:Pet peeve (1)

Murdoch5 (1563847) | more than 5 years ago | (#28158567)

True, but it's not practical to use Assembler for much any more, maybe a short uC program but other then that, there is not alot of use for it.

Re:Pet peeve (4, Insightful)

Anonymous Coward | more than 5 years ago | (#28158605)

A badly-written Assembler program will never achieve the speed of a reasonably-written C++ program. And most people cannot write good Assembler code.

Re:Pet peeve (1)

moon3 (1530265) | more than 5 years ago | (#28158817)

You've probably never heard of Intel's Optimizing C++ compiler.

Hell, C++ is the true production language running everything from Gears of War, Counter Strike to Mozilla, Internet Explorer, Flash, VLC and high-end production web servers like YouTube etc. Depending on how you use it, but it can be as easy as Basic yet powerful and fast as assembler. Take no substitute.

Re:Pet peeve (0)

Anonymous Coward | more than 5 years ago | (#28158951)

I would not want to compete with the latest compilers (of any strongly and statically typed language) with my leet assembly skills..

Re:Pet peeve (1)

DoofusOfDeath (636671) | more than 5 years ago | (#28158543)

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.

Re:Pet peeve (1)

sunderland56 (621843) | more than 5 years ago | (#28158551)

The article does confuse a language with it's implementation. GCC, for instance, is NOT a language!

Re:Pet peeve (2, Informative)

someone1234 (830754) | more than 5 years ago | (#28158835)

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

Re:Pet peeve (1)

Twinbee (767046) | more than 5 years ago | (#28158757)

I don't agree. The concise and almost 'joyful' programming languages like Ruby *lend* themselves to generally running slower for the reason that it's much harder to create a fast compiler for them than the others. It's still possible, but much, much harder to do so.

Forth, the RPN notational programming language (4, Informative)

RichMan (8097) | more than 5 years ago | (#28158377)

http://en.wikipedia.org/wiki/Forth_(programming_language) [wikipedia.org]

--
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:Forth, the RPN notational programming language (2, Interesting)

wonkavader (605434) | more than 5 years ago | (#28158839)

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.

Re:Forth, the RPN notational programming language (1)

rubycodez (864176) | more than 5 years ago | (#28158901)

even though it can generate code that runs faster than compiled C on certain platforms, can it really be used for truly huge projects? is there a modern word processor or DBMS or CADD system written in FORTH?

Where are the real lanaguages??? (4, Interesting)

jackb_guppy (204733) | more than 5 years ago | (#28158405)

Where Cobol and RPG, the languages that run business?

Re:Where are the real lanaguages??? (5, Funny)

DoofusOfDeath (636671) | more than 5 years ago | (#28158595)

Where Cobol and RPG, the languages that run business?

They were so far off the top and right axes, the algorithm discarded them as outliers.

Re:Where are the real lanaguages??? (1)

ceoyoyo (59147) | more than 5 years ago | (#28158615)

Top right.

I wasn't aware... (0)

Anonymous Coward | more than 5 years ago | (#28158845)

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

C best language out there (0, Offtopic)

Murdoch5 (1563847) | more than 5 years ago | (#28158413)

Personally I'd pick C as being the best all around programming language to work with, and that is C NOT C++. C has all the features needed in a great programming lang (PL) . You can interface close enough to the hardware for complete control, you can inline assembler right into the code. The preprocessing feature work awesome, using macros to replace short functions, even the library's a user has access to. The syntax is great to work with, it's a quick to temp up PL, you can really make a functional program in less then 2 min that has meaning, with out comments mind you.

C is available on all modern platforms, C has the best compiler of all time on it's side GCC, The GTK / Gnome environment is even based off C. C has everything needed in PL to make it the number 1 pick of all time. Needless to say it's also stood the test of time.

Re:C best language out there (2, Funny)

Anonymous Coward | more than 5 years ago | (#28158603)

It would be better if it was extended to support classes.

Re:C best language out there (0)

Anonymous Coward | more than 5 years ago | (#28158657)

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

Re:C best language out there - what about for web? (1)

walterbyrd (182728) | more than 5 years ago | (#28158733)

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.

Re:C best language out there (1)

wonkavader (605434) | more than 5 years ago | (#28158889)

I like C, too, but one chooses ones language for the task at hand.

Ocaml (3, Interesting)

LaminatorX (410794) | more than 5 years ago | (#28158575)

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 (0)

Anonymous Coward | more than 5 years ago | (#28158717)

Maybe b/c people assumed the language was an OHors designed to specifications of OComitee?

Re:Ocaml (3, Insightful)

16384 (21672) | more than 5 years ago | (#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 (3, Interesting)

Daniel Dvorkin (106857) | more than 5 years ago | (#28158867)

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 (4, Interesting)

Anonymous Coward | more than 5 years ago | (#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.

HAI (4, Funny)

Anonymous Coward | more than 5 years ago | (#28158597)

CAN HAS LOLCODE? [lolcode.com]
KTHXBYE

I think it depends more on what you want to achiev (5, Interesting)

ledow (319597) | more than 5 years ago | (#28158667)

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. My University taught me Java. I read a one-page cheat sheet and never attended a single class and passed with flying colours. Why? Because it was a C-a-like with OO (admittedly quite new to me at the time) and a horrible class structure to do even the most basic of operations. But a damn lot of people there just did not understand WHAT the computer was doing when they asked things of it and I was constantly sorting out other people's messes of programs.

So I quite like that this article has come up. Sue me if I want to automate stuff in bash script, or demo stuff in BASIC because it's quick and easy, or write stuff in C because I can see what's damn well going on. Ask someone the memory, I/O or CPU use of a program in BASIC or C and you can give a good estimate in a few minutes provided they understand the recursion - I have literally done this on paper before I wrote a program to find the most "efficient" way of storing stuff on a low-mem machine (32Mb of very slow RAM) to squeeze the largest results out of it. Doing the same in other languages is virtually impossible without running the damn thing. Perl, Java, all the "modern" languages are just glitz and libraries and shortcut keywords on top of a language I could get on with perfectly well if it wasn't for the crap.

Ruby (4, Insightful)

RiotXIX (230569) | more than 5 years ago | (#28158689)

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.

Re:Ruby (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28158837)

In fairness, and as one of the commenters pointed out YARV performs better than the std Ruby interpreter it'll be replacing.

OTOH, lua/luaJIT beats Ruby and Python on all fronts; a lightweight, simple, speedy and expressive language. If we had to pick one scripting language on its merits rather than the personal predjudices of "I know language x" or hype, lua would be it.

Re:Ruby (0)

Anonymous Coward | more than 5 years ago | (#28158871)

Peter Griffin:

When I'm through with our schools our students will be so smart they will be able to program their VCRs without spilling piping hot gravy all over myself.

RiotXIX:

Then why the fuck is the Ruby community hyping it so much, and drawing nieve young developers in to a trap?
(...)
It's my hope that if I stick with Ruby ...

Heh, sucker.

Re:Ruby (1, Troll)

Foofoobar (318279) | more than 5 years ago | (#28158969)

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

They did. It's called PHP. Notice how much better it scales in that benchmark.

Be aware of your contexts. (2, Insightful)

cabazorro (601004) | more than 5 years ago | (#28158737)

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.

Ada (1)

danwesnor (896499) | more than 5 years ago | (#28158755)

Where's Ada?

Re:Ada (4, Informative)

Ada_Rules (260218) | more than 5 years ago | (#28158893)

Where's Ada?

One item in the list is gnat which is one particular implementation of Ada. So, there is at least one Ada implementation on the list. I did not recognize any others.

ccomparison of C and CAS (2, Insightful)

e**(i pi)-1 (462311) | more than 5 years ago | (#28158775)

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.

Where's brainfuck? (1)

xtrafe (1262576) | more than 5 years ago | (#28158785)

I, for one, am disappointed that a whole treasure trove [voxelperfect.net] of languages was ignored by this study.

Where's D? (1)

Twinbee (767046) | more than 5 years ago | (#28158787)

I wish D was one of the contenders. It'd be shown pretty far to the lower left I'm betting.

Re:Where's D? (2, Informative)

wonkavader (605434) | more than 5 years ago | (#28158879)

Isn't that the 'dlang' reference?

Re:Where's D? (1)

Twinbee (767046) | more than 5 years ago | (#28158975)

Oops oh yeah. Hopefully my original post will get modded into oblivion ;)

C vs C++ (1)

masmullin (1479239) | more than 5 years ago | (#28158795)

C++ got a better score. Am I reading this right?

some random observations (3, Interesting)

bcrowell (177657) | more than 5 years ago | (#28158809)

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.

This is totaly stupid (4, Interesting)

FlyingGuy (989135) | more than 5 years ago | (#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.

Logarithmic x axis (1)

Twinbee (767046) | more than 5 years ago | (#28159005)

These graphs are great, but it would be nice to see the X axis expressed logarithmically for a greater range of time tests.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>