While this article is 10 years old, it contains a few very good points -- I've referenced it many times over the last 8 years. Specifically:<p>-- Scripting languages relative run time and memory consumption overhead will often be acceptable and they may offer significant advantages with respect to programmer productivity.<p>-- For all program aspects investigated, the performance variability due to different programmers is on average about as large or even larger than the variability due to different languages.
I've always kind of felt that any claim to empiricity in programming language comparison will be fatally undermined by a focus on only one task. The choice of task itself is very opinionated in a way that makes it difficult to apply the conclusions of this study more broadly.
I've seen so many benchmark comparisons that only focus on conciseness (that too involving lines of code), and speed. Yeah, they all re-affirm what is already known - C is fast, python/ruby is concise, C#/Java is somewhere in between and there are the ones which do well in both - haskell, clojure, etc. (And then there's APL)<p>All the benchmarks are algorithm and processor intensive, while quite a few applications are idling most of the time. How about a comparison regarding the standard libraries, ease of debugging, external tools, code readability, available support, external libraries, etc. In short - developer productivity.<p>I'm not saying performance is not important - it is quite critical, but there are other things code does as well (At least most of my code is mundane, and is just calling APIs, updating files, serializing objects, etc. Nothing too fancy.)
</rant>
In many respects, TCL is dead at this point ... there is still a lot of legacy use for it but few new users in comparison to Python, Ruby, etc. Rexx is dead outside of IBM shops, and was ever since Amiga and OS/2 died.
One section of the paper describes which algorithms the programers used. It appears that the solutions in scripting languages made heavy use of associative arrays, so the results might change if you swapped Tcl's hashing algorithm for Perl's.<p>The algorithms described don't seem very clever. I expect you could do much better by splitting the input number into digraphs or trigraphs, sorting those by frequency in the dictionary, and matching the rarest ones first.
Am I the only one tired of mathematical tests? I'd rather see a test comparing the relative speed and scalability of various web app implementations.<p>And don't give me that line about scaling not mattering, I have to cope with a cantankerous server and database at work, I know full well what my problem sets are.