Re: Glasgow haskell vs. Lispworks

Jon Harrop schrieb:
Joachim Durchholz wrote:
Haskell even has a formal semantics (not a complete one, but enough to
be useful).

OCaml does not. Hence an argument that an optimization is
not "semantics-preserving" is a non-starter in the context of OCaml.

Ah, I understand the context now.

Still, arguing about semantics-preserving transformations does make sense. Such arguments are far more difficult to resolve for a language without a formal semantics, of course, but that doesn't mean it is irrelevant. (After all, the conversion of source code to machine code is a semantics-preserving transformation, too, otherwise nobody would program in the language.)

1. Haskell is only fast in theory. In practice, it remains 3x slower.
Well, that's certainly interesting for some applications, but it's not
necessarily interesting for others.

Also, that speed difference isn't as clear as you make it out to be.

Haskell is >3x slower than the fastest languages on all of these benchmarks:

http://www.ffconsultancy.com/languages/ray_tracer/results.html
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=fannkuch&lang=all
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=fasta&lang=all
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=knucleotide&lang=all
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=regexdna&lang=all
http://shootout.alioth.debian.org/sandbox/benchmark.php?test=spectralnorm&lang=all

Yes, but none of these benchmarks take programmer time into account (nor are they geared towards this kind of benchmarking).

The numbers certainly come out differently if you ask about the performance
achievable with a given, limited programmer time budget.

I don't buy that for a second.

*shrug* look at the outcome of ICFP contests.
There are other references. I dimly remember a test run by DARPA where they asked different programmers to program a small task in their respective standard languages. Haskell came out with impressive results, including timing (and that's years ago, when optimization wasn't as sophisticated as they are today). Of course, those guys didn't care about a factor of 3, they cared about big-Oh differences.

> Look at these results for the regex-dna
benchmark running on my machine:

Python: 27LOC 1.67s
OCaml: 41LOC 3.770s
C++: 226LOC 3.941s
Haskell: 274LOC 6.738s

If it isn't bad enough that Haskell is 4x slower than Python, it is even
substantially more verbose than C++.

*shrug* proves very little. There's always the odd problem that's difficult to encode in any given language. More often, it's just a C++ programmer writing C++ code in another language.

> If that doesn't convince you that
Haskell is far from God's gift to development time maybe this 500kb web
page discussing Haskell implementations of that trivial benchmark will:

http://www.haskell.org/haskellwiki/Shootout/Regex_DNA

*shrug* I have seen enough concise Haskell code that no C++ could match.

It's the old assembly argument: if you want real speed, you can always
drop down to assembly, but most of the time, the advantages in
programmer speed allow you do to algorithmic optimizations that the
lower-level language cannot afford because getting the code right is
difficult enough.

That is just another reason why Haskell is fast in theory.

Just compare the team notes from the various ICFP contests. Halfway through the contest, C++ teams usually report about nasty pointer bugs that took them half a day to chase down, while the Haskellistas usually report "almost done" and start to think about algorithmic optimizations.

One of the contests did raytracing. IIRC the first three places were taken by Haskell and OCaml teams.
That's a general trend. OCaml tends to be faster, but the difference isn't so large that there's a clear-cut advantage. For those tasks where correctness was important (raytracing, finding a way through a labyrinth), Haskell tended to be more successful, otherwise, OCaml could play out its speed advantages.

In general, I don't think that speed is half as important as you make it out to be. Given enough time to apply all optimizations, OCaml could well be faster than Haskell; on the other hand, since programmer time is limited, it may still be better to work in Haskell because you get the web interface, the mail library, and the database access layer done and optimized while the hapless C++ programmers just got around the last pointer bugs and are just starting to think about optimizing the intersection finding algorithm. (I'm exaggerating, of course, and you're more interested in OCaml than in C++ anyway, but I do think if getting the algorithms done is more important than getting every algorithm fast, then Haskell is probably the more productive language.)

Regards,
Jo
.

Relevant Pages

  • Re: Verbose functional languages?
    ... Outside a few tiny niches like technical computing, OCaml is certainly not ... significantly updated language standard approaches. ... OTOH, I have no use for Haskell, I don't ... world" technique if anyone came to this discussion stating that they had ...
    (comp.lang.functional)
  • Re: Learning functional programming
    ... learn some Haskell, but I have to admit I never really liked Haskell (I ... You could try OCaml, from the ML family. ... above all a practical and pragmatic language. ... but I think its practicality remains ...
    (comp.lang.functional)
  • Re: Glasgow haskell vs. Lispworks
    ... OCaml does not. ... Hence an argument that an optimization is ... That is an enormous cost in terms of programmer time and is reflected in the ... fact that the Haskell is an _order of magnitude_ longer. ...
    (comp.lang.functional)
  • Re: What language would you use for teaching functional programming?
    ... In particular I am interested in finding a language that allows my ... I'm already inclined towards OCaml, but don't let it bias your ... My opinions will be biased by this. ... IMO Haskell would make the best *contrast* to Scheme being the most fiercely pure and of the three and the most unusual. ...
    (comp.lang.functional)
  • Re: Learning functional programming
    ... learn some Haskell, but I have to admit I never really liked Haskell (I ... You could try OCaml, from the ML family. ... above all a practical and pragmatic language. ... devastation caused when a comet hits earth. ...
    (comp.lang.functional)
Loading