Slashdot Mirror
The Great Computer Language Shootout Revived
An anonymous reader writes "Doug Bagley's famous Great computer Language Shootout more or less died in 2001 out of lack of support by its own author.
A group of developers have decided to revive it and update it with the latest versions of each compiler and interpreter available on the Debian distribution.
The good news is, a wiki has been set up so that people can help improve the shootout, discuss the implemetations of the programs, and suggest optimizations."
Probably because most of us want to be expert in a few languages than mediocre in many. It's like human language. How many people do you know are fluent in more than one language? Two languages? By the time you get to fluency in three languages, they're getting rare.
You can't pick the language for the task, because in all probability you don't have the time to learn a new language for each task. There are many times when I have to write a piece of code in an "inappropriate" language simply because I don't have time to learn the appropriate language. I know what it's like to be in the middle of some C++ code thinking, "gee, [Java|Lisp|Ruby|etc] would be perfect here...".
As with human language, some people are naturals when it comes to being fluent in multiple programming languages. Unfortunately, I am not one of their number.
Don't blame me, I didn't vote for either of them!
Multi-language development is incredibly useful - the last program I wrote has a C/C++/OCaml server with a GUI client written in Delphi.
Unfortunately, it also means that nobody can easily maintain the program who isn't fluent in all four languages, which is why, while useful, it's also an incredibly bad idea for anything critical.
The program in question is a quick and dirty solution to a migration issue, and using the mixture of languages allowed me to leverage all their strengths and produce a fast and robust program in record time (the C++ and about half of the C were existing code that OCaml's FFI allowed me to reuse), but I would never consider it for production software - the up-front cost savings would be swallowed by the maintenance costs.
fputs() is an ANSI C standard function designed to write text to an output stream or file. Write() is not ANSI C compatable, requires knowledge of the length of the string (either truncating if the length parameter is too low, or writes garbage if the length parameter is too high), and is designed for binary output rather than text.
write() is POSIX/BSD/SVr4 which is certainly fine for the vast majority of platforms. Even with doing the strlen() and a const, it is cheaper than fputs() due to the locking fputs() puts on stdout (admittedly nothing compared to loading the binary into memory). Further, even if you wanted to use ANSI C, they should have just used puts().
Correct it then. The webpage containing the benchamarks has links available to contact the maintainers of the website so that you can submit a more efficient function.
Every single test for every single language is almost certainly flawed in some way. If they wanted to do it right, they should have allowed open submission and peer review of every test so that they could be written and rewritten then tested.
The point is, the person running this is certainly not an expert in every single language. I doubt very much that they can make a proper decision between four different and seemingly correct implementations of the hash implementation. Just submitting replacements doesn't make much sense because *my* implementation could raise just as many questions as the up right now.
This, of course, assumes that the HM class is not affected by the buf[] string being overwritten. If it is, then you'll have to find another way to eliminate the sprintf/strdup inefficiency.
Oddly enough, the "correct" implementation from a best practices standpoint may be slower by using std::string instead. It all depends on what your definition of "correct" is. That is why an open peer review process would be helpful as the feedback would educate people as to why certain design choices were made.
The question you have to ask yourself is, do the results on this page reflect reality in any way?
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
Can YOU become an expert in Lisp in one week?
I've actually spent a number of years using Lisp. I've been paid to write software in somewhere between a dozen and two dozen languages, depending on your definition of language, and I assure you that your "acquire complete mastery of a new language in a week" test is completely irrelevant.
If you haven't even started to look at a language until a week before you need to be a master, it's not the fault of the project. You simply aren't qualified for that particular job.
But, unless you never do anything until someone else forces you to do it, you usually have years in which to get to know a new language. Over that time, you will either determine that it is not useful enough to add to your toolbox or you will have added it to the extent you feel it warrants.
So all I'm talking about is the advantages of a site like the Great Language Shootout that gives you a lot of information with which to make your decisions over that period of years that I'm referring to.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
It's more than that.
In the real world someone is paying to get software done. That someone does not want to pay us to learn a new language just so a function doesn't need to be written because in language X it's a one liner. Write the equivalent function or find a suitable existing library. If you program in C/C++ the library probably does exist. In Haskell or Eiffel...
Also real commercial products do not exist in a vacuum. You will probably have existing code that does at least part of the job. The person paying the bills will not want to pay to port all of that code. They will want to leverage it.
That's why the new cool language du jour does not rule the world. It's frustrating if the language you want to use is demonstrably better but factor in the cost of finding more progammers that can use the language effectvely & most of the advantages you perceive evaporate.
What are you listening to? (http://megamanic.blogetery.com/)
As was pointed out in the many comments concerning Java's speed when compared to C++, that hash code for C++ is seriously screwed up. It leaks memory like crazy, and one of the examples doesn't even do the same thing as the Java example because the code uses hash_map::operator[]() to test for element existence, instead of hash_map::count().
Funny that you should say that, because hash tables are one of the easiest ways to "leak" memory in Java -- to have stray references floating around.
May we never see th
write(2) is a system call on UNIX systems, not a part of the C language or the C standard library. It has no place in a portable C program. You might as well argue that the program should have use DosWrite() (OS/2 system call) or $QIO (VMS system call).
Mea navis aericumbens anguillis abundat
Apparently they used Psycho to get the Python numbers. This is why the Python numbers look so good. However, Psycho is not the standard distribution of Python and it doesn't allow the full flexibility of standard Python. This should be noted in the results. They should create a set of results using the 'standard' Python distro as well. ...otherwise, why not just let us use Inline::C in Perl (or in Ruby) - basically this would allow you to put C code into your Perl/Ruby script (which wouldn't be fair).