Re: [Haskell] The speed, size and dependability of programming languages
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. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
On Tue, Jun 2, 2009 at 1:03 PM, Paul Johnson p...@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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] The speed, size and dependability of programming languages
Hello haskell, Interesting blog post comparing speed and expressiveness of many languages: http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
Thanks for the link. I find the expressiveness results odd. How can SML/NJ be among the least expressive languages, while MLTON and OCAML are among the most expressive? How is Smalltalk less expressive than Java? Why are Prolog and Mercury among the least expressive? 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. On Mon, Jun 1, 2009 at 1:18 AM, Bulat Ziganshin bulat.zigans...@gmail.comwrote: Hello haskell, Interesting blog post comparing speed and expressiveness of many languages: http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
On Mon, Jun 1, 2009 at 1:58 PM, Lyle Kopnicky li...@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=alllang=smlnjlang2=ghcbox=1 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[2]: [Haskell] The speed, size and dependability of programming languages
Hello Lyle, Monday, June 1, 2009, 9:58:14 PM, you wrote: Thanks for the link. I find the expressiveness results odd. How can SML/NJ be among the least expressive languages, while MLTON and OCAML are among the most expressive? optimization tricks? How is Smalltalk less expressive than Java? libraries? Why are Prolog and Mercury among the least expressive? programming style? -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
gwern0: On Mon, Jun 1, 2009 at 1:58 PM, Lyle Kopnicky li...@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=alllang=smlnjlang2=ghcbox=1 There's one thing wrong: Last Updated: Tue Mar 20 18:02:38 PDT 2007 Don't use the gp4 results: they're obsolete. Use the u32, u64, u32q or u64q results. -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The speed, size and dependability of programming languages
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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
