On Feb 12, 1:28 pm, Michael Gardner <[email protected]> wrote: > On Feb 12, 2011, at 3:12 PM, Isaac Gouy wrote: > > > Yeah but it's not too hard to see why the Lisp programmer Juho > > Snellman opined on HN "the [sic program] implementations seem to have > > totally dived off the deep end of complexity". > > That's why this kind of competition is not interesting to me. As it only > compares the fastest programs, there's every incentive to submit horrifically > complex, optimized-to-the-hilt solutions that would almost never get used in > the real world. > > Rather than ask "what's the fastest this can be done in language X?", we > should ask "how fast are the idiomatic ways of doing this in language X" and > possibly "how hard is it to do it faster, when those are not good enough?".
Looking at the benchmarks game web page showing the "fasta" programs: - 4 different Clojure programs are shown - 2 different Java programs are shown - 4 different C programs are shown etc http://shootout.alioth.debian.org/u32/performance.php?test=fasta > Possibly just including code size/complexity with the performance metric > would do the trick, though measuring that cross-language is a challenge all > its own. There is a column showing compressed source code size for each program. And then there's http://shootout.alioth.debian.org/u32/code-used-time-used-shapes.php -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
