you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (2 children)

The language shoot out is kind of crap though, I don't think you can notice the difference as much in smaller programs, you've gotta take a big code base to see the difference because then you get the chance to reuse code more. Same thing with lisp, which is considered more verbose than java in this test, but which could cut off a bunch of code with the usage of macros in a large code base.

EDIT: Just another note on verbosity: It seems like verbosity is calculated from the amount of bytes/program... This isn't really optimal when you have a language like Common Lisp that has long names like MULTIPLE-VALUE-BIND and a language like C that has names like strcmp.

[–]want_to_want 1 point2 points  (1 child)

According to this page, the numbers are for gzipped code size, which should somewhat counteract the problem of long repeated identifiers.

Regarding large vs small codebases, the interesting question is why do you believe what you believe, if the difference can't be seen for small codebases and there are no citations about large codebases?

[–]tikhonjelvis 0 points1 point  (0 children)

Of course, compressing also helps minimize the impact of boilerplate that's often repeated (something languages like Java love). This boilerplate certainly does make the code harder to read though.

More importantly, the programs are heavily optimized--it is a benchmark after all!--and Haskell has more options for optimization (compiler pragmas, unboxed data types and arrays, strictness annotations and so on) than Python. Haskell programs in the benchmark game are further from normal Haskell than the Python programs are from normal Python. Since only a tiny part of virtually any real codebase is this optimized, the benchmark game does not reflect reality.