Rough Haskell and OCaml comparison, was Re: novice's notes on learning OCaml

[Kragen Javier Sitaker]

Shae Erisson writes:
> "Richard Underwood/Uhtenwoldt" <ru at river.org> writes:
> > [quoting Kragen Javier Sitaker]
> >>   A simpler syntax with fewer levels of precedence.  Maybe
> >>   writing OCaml in S-expressions would be going too far, or maybe
> >>   not.  Clearly this would make it effectively a different
> >>   language.
> >
> > Do you know enough about Haskell to have a definite opinion about its
> > syntax?

Not really.  My vague opinion about its syntax is that it appears to
be a simpler syntax with fewer levels of precedence, and the
indentation thing sounds good.

> In my opinion, Haskell has advantages over OCaml in syntax,
> typeclasses, and community. I'd be happy to elaborate on any of
> these points if there's any interest.

I'm interested in your opinion especially on the syntax; I think I
know about the other two.

> OCaml has advantages over Haskell in ability to decrease execution
> time without much effort, but at the expense of abstraction.
> 
> In short, if you know C, you can make a roughly equivalent OCaml
> program that's anywhere from not quite as fast to faster than any
> given C program.

>From my limited OCaml experience so far, this seems to be true, the
OCaml code tends to be a great deal shorter (because more abstract)
and less likely to crash than the C.

> Haskell is, in my opinion, better at abstractions than OCaml, but at
> the expense of requiring mental whole program analysis in order to
> understand non-strict evaluation. Also in my opinion, mutable
> variables require more whole program analysis than non-strict
> evaluation, but I don't know how many people agree with me.

Maybe it depends on what you want to know about the program?  It seems
to me that lazy evaluation only requires whole-program analysis when
you want to know how fast something is or how much memory it needs,
while mutable variables potentially require whole-program analysis to
know what value some function computes.  (There are various ways to
limit the scope of analysis required, of course, so whole-program
analysis is not always needed.)

To the kind of functional programmer who "knows the value of
everything and the cost of nothing," the above paragraph should make
it clear that lazy evaluation is superior.  But, myself, I'm often
just as interested in the speed of my code as in whether it's correct,
partly because I've found that it's often easier to make incorrect
code correct than to make slow code fast.  It depends on the
circumstances.

Richard Underwood writes:
> So, write your unit test as
>     assert ([45; 50] = eval (atom [45; 50]));
>     atom x = Atom x
> Or am I missing something basic?

No, that's clearly what I should do, and it's just a
search-and-replace on the existing code.  I guess I was just annoyed
at how I inadvertently ended up committing to more than I knew when I
wrote the original unit tests, but a search-and-replace isn't that big
a cost to cancel that commitment.