Ketil Malde wrote:

dons@cse.unsw.edu.au (Donald Bruce Stewart) writes:

...

Haskell now ranked 2nd overall, only a point or so behind C:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

Very impressive! And note that if you put zero weight on memory use, GHC wins by a large margin. (OTOH, if you take out lines count, things don't look quite as good :-)

Very impressive indeed. You don't even need to put zero weight on memory use for GHC to win. Personally, I used weights of speed=1, memory=1, code lines=2, as I believe that _programmer_ efficiency is just as important as _language_ efficiency. The one to beat was MLton under those weights, and GHC is now doing so handily. It might be worth noting that under the 1,1,2 weigting, and with "tcp-request-reply" properly deprecated (ie weight=0), the rankings are Haskell GHC SML MLton OCaml C gcc so that the functional languages show rather impressively, better than "portable assembler" (as C ought to be more widely known) Jacques

On 1/15/06, Isaac Gouy wrote:

...

Haskell now ranked 2nd overall, only a point or so behind C:

It was always obvious that the "Write the program as-if lines of code were not being measured" clause relied too heavily on contributors willingness to co-operate.

http://shootout.alioth.debian.org/gp4/faq.php#implementlist

Maybe we finally have enough motivation to move to some other measurement of program volume :-)

I was just thinking about that. Some code is very obfuscated due to contributors trying to conserve lines of code. I'm not sure how you could do this better, though... Maybe counting the number of "tokens" (not sure how you'd define that though) would reduce code such as foo;bar;baz... That's probably not all that much better though... In one way I think the readers would be better served if code-lines wasn't counted. At least all the code samples would be idiomatic and clear, so it's easier to click a language and see a nice somewhat representative example of how code in it looks. But on the other hand it is interesting to see how languages compare in terms of "elegance" (and LOC is at least a *simple* way to meassure it). Perhaps each language can have a "live" and an "elegant" version. So that you can at least see what an elegant implementation would look like for each language (but that version isn't benchmarked). /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

On 1/15/06, Donald Bruce Stewart wrote:

sebastian.sylvan:

...

On 1/15/06, Isaac Gouy wrote:

...

...

Haskell now ranked 2nd overall, only a point or so behind C:

It was always obvious that the "Write the program as-if lines of code were not being measured" clause relied too heavily on contributors willingness to co-operate.

http://shootout.alioth.debian.org/gp4/faq.php#implementlist

Maybe we finally have enough motivation to move to some other measurement of program volume :-)

I was just thinking about that. Some code is very obfuscated due to

No Sebastian, this is very obfuscated: http://www.cse.unsw.edu.au/~dons/pretty.html

;)

I think saying obfuscated is very unfair. We took advantage of some strengths of Haskell, such as type inference, to reduce the number of lines. No worse than, say, the SML MLton entries do -- and why not leverage this advantage, since our language can do it?

In fact, we have 1 line entries for some of the problems that are just not competitive, though very instructive. It would be nice to be able to publish those.

I wasn't talking specifically about Haskell, but all languages (don't like browsing around other languages only to see highly compact and ugly solutions, which really don't give me a good taste for the langugae). Still, some Haskell implementations are clearly obfuscated to save lines in certain circumstances (like: "thread im om = do (x::Int) <- takeMVar im; putMVar om $! x+1; thread im om" int he cheap concurrencybenchmark, most people don't write Haskell code with semi-colons, and when they do they usually sequence them vertically, not horizontally). /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

On 1/16/06, Donald Bruce Stewart wrote:

sebastian.sylvan:

...

On 1/15/06, Donald Bruce Stewart wrote:

...

sebastian.sylvan:

...

On 1/15/06, Isaac Gouy wrote:

...

...

Haskell now ranked 2nd overall, only a point or so behind C:

It was always obvious that the "Write the program as-if lines of code were not being measured" clause relied too heavily on contributors willingness to co-operate.

http://shootout.alioth.debian.org/gp4/faq.php#implementlist

Maybe we finally have enough motivation to move to some other measurement of program volume :-)

I was just thinking about that. Some code is very obfuscated due to

No Sebastian, this is very obfuscated: http://www.cse.unsw.edu.au/~dons/pretty.html

;)

I think saying obfuscated is very unfair. We took advantage of some strengths of Haskell, such as type inference, to reduce the number of lines. No worse than, say, the SML MLton entries do -- and why not leverage this advantage, since our language can do it?

In fact, we have 1 line entries for some of the problems that are just not competitive, though very instructive. It would be nice to be able to publish those.

I wasn't talking specifically about Haskell, but all languages (don't like browsing around other languages only to see highly compact and ugly solutions, which really don't give me a good taste for the langugae). Still, some Haskell implementations are clearly obfuscated to save lines in certain circumstances (like: "thread im om = do (x::Int) <- takeMVar im; putMVar om $! x+1; thread im om" int he cheap concurrencybenchmark, most people don't write Haskell code with semi-colons, and when they do they usually sequence them vertically, not horizontally).

Though often the case, using ; is not without precedent. A quick grep in the ghc source reveals many

Yeah sure, but it's quite obvious that in this case the source has been intentionally obfuscated to reduce the number of lines. Perhaps the use of several imports on one line separated by semi-colons is a clearar example of that, though. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

jupdike:

...

...

Maybe we finally have enough motivation to move to some other measurement of program volume :-)

...

I'm not sure how you could do this better, though... Maybe counting the number of "tokens" (not sure how you'd define that though)

I was thinking the same thing for the past few weeks: that lexemes or lexical tokens would be the ideal unit of conciseness in a programming language. This is revealing:

...

From the shootout, for ackermann (counted by hand, given the benefit of the doubt (i.e. to yield shorter count), excuse any mistakes): language lines lexemes (non-whitespace, non-comment tokens) Haskell 7 78 Python 10 79* OCaml 6 87 Standard ML 4 88

Ah! Just as I thought, SML really was trying very hard ;)

Tcl 12 89** Nice 7 93 Perl 9 95*** c/gcc 8 100**** Java 7 109 D Digital Mars 9 113 Scheme 11 113

-- Don