lists:

I think it's a combination of 1) the expressiveness measure is too simplistic, measuring number of lines alone, or counting comments

It isn't measuring lines of code, it is measuring the Gzip compression Also, there's a few bogons in the data (it was graphed against 2005-6 results, and includes programs that produce the wrong output, and programs where the are duplicate entires per language). -- Don

On Mon, Jun 1, 2009 at 1:58 PM, Lyle Kopnicky <lists@qseep.net> wrote:

Why are Prolog and Mercury among the least expressive?

Well, I don't know about SML/NJ, since I don't see anything obviously wrong at http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=smlnj&lang... But as for Prolog - I can't help but think of a quote I saw in a recent paper in LtU, which went something like 'Our first prototype was written in Prolog, but when we realized that we were using none of the logic programming features, we decided to rewrite in Haskell.' -- gwern

Instead of GZip metrics for code size, maybe a good measure of imperative language code size would be the "cyclomatic complexity" metric. It would also be interesting to see results for Fortran, Java, C++, etc. across a range of old and newer compilers. Can one measure "cyclomatic complexity" for functional languages? However: From: http://en.wikipedia.org/wiki/Software_metric Modern software development practitioners are likely to point out that naive and simplistic metrics can cause more harm than good. ALSO: one is often more interested in "Software Quality" factors * 4.1.1 Understandability * 4.1.2 Completeness * 4.1.3 Conciseness * 4.1.4 Portability * 4.1.5 Consistency * 4.1.6 Maintainability * 4.1.7 Testability * 4.1.8 Usability * 4.1.9 Reliability * 4.1.10 Structuredness * 4.1.11 Efficiency * 4.1.12 Security Which seem only to be qualitatively "metricable" and not quantitatively "metricable". Benchmarks of any type only seem to be applicable to your program if your program is fairly similar to the benchmark. -- Regards, Casey

On Tue, Jun 2, 2009 at 1:03 PM, Paul Johnson <paul@cogito.org.uk> wrote:

Lyle Kopnicky wrote:

...

I think it's a combination of 1) the expressiveness measure is too simplistic, measuring number of lines alone, or counting comments, and 2) the problem set is skewed toward number-crunching, which is not (say) Prolog's strong suit.

Also there is a strong tendency to optimise the code for performance rather than conciseness (concision?). In the past this tended to bloat (e.g.) Haskell entries as simple intuitive code was replaced by arrays of unboxed integers and similar C-like constructs.

Well, they're supposedly measuring performance as well. If concise Haskell is non-performant, and performant Haskell is verbose, this ought to be reflected in the charts. But it managed to perform pretty well in both. I don't think Haskell got short shrift in this analysis. Perhaps other languages suffered a more "written verbosely for performance" problem. - Lyle