Hacker News Reader

Comment by almosthaskeller | Hacker News Reader

Looked into a static FP language recently. Was torn between OCaml and Haskell. Leaned more toward Haskell than OCaml. Mainly because OCaml feels like it was hacked together, with a lot of very strange and inconsistent syntax and poorly thought out semantics. That said, I haven't chosen either yet, because Haskell has its own share of oddities that I'm still not comfortable with. But at least it feels more pure and consistent and well thought out in its syntax and semantics.

View on HN

Ocaml and Haskell are both good languages. Haskell probably has a bigger community and more momentum at this point. I switched from Ocaml to Haskell long ago because I wanted parallelism.

The implementation philosophy of the two languages is pretty different, despite being superficially similar in terms of syntax. Ocaml is pretty predictable -- you can look at code and have a pretty good idea of what kind of code the compiler is going to generate.

Haskell is a lot more opaque. Between laziness and a more rigid type system, ghc can do some pretty crazy code transformations. In general, this is a good thing, but it can make performance questions harder to figure out.

I think that Ocaml is easier to learn, but Haskell is more fun, and I've learned more from using it.

Haskell libraries also tend to have more levels of abstraction then Ocaml ones, in my experience. Ocaml libraries don't tend to use things like monad transformers or lenses.

After many years of struggling with Haskell, I've all but given up on it, because of the broken record semantics. They seem to be able to find time to implement monad comprehensions or whatever paper fodder is most in vogue, but you still can't have two datatypes with the same field name in the same module. It's not a serious language.

A record field accessor is just a normal function, are you also expecting define methods with the same name within the same module? If you want an elegant solution, write a typeclass. You have to write you java in the haskell way. https://wiki.haskell.org/Name_clashes_in_record_fields

That is also true of Ocaml, and probably every other ML derived language that treats accessor functions as ordinary functions (rather than using the C-style dot operator). There is a type-directed name resolution proposal that would remove this limitation in Haskell, but it would probably make the typechecker a lot more complicated.

The can't-reuse-field-names thing is annoying, but claiming that it "isn't a serious language" because they made a design choice that doesn't meet your exact expectations seems kind of closed-minded to me.

Or one could use the lisp-way – and just call the functions <record-name>-<field-name>.

This avoids those problems.

The Ocaml way would be to define the functions in separate modules (A.foo, B.foo, etc.). There are convenient syntaxes for declaring which modules are in scope in a given expression, as well as support for first-class modules (you can define functions that take modules as parameters). The module system is sophisticated, and is arguably the "power feature" of Ocaml.

This is what you generally see in larger haskell programs which might have a name clash (at least it's what I use):

    data F = F { fName :: String }
    data P = P { pName :: String }

Yes, this is one of the cases where ML modules are elegant, since you can put the definition of the type into its own module, so it becomes F.t and P.t and you avoid field name clashes.

> ML derived language that treats accessor functions as ordinary functions

OCaml is not in that tradition—field projection uses dot notation and has historically not been an ordinary function (although maybe that has changed in later versions).

You're right, and that is still the case.

OCaml has had type-directed record disambiguation for a few versions now. So you can quite easily reuse field names these days.

That's cool, I didn't realize they had done that. I haven't used Ocaml in quite awhile -- it's good to hear the language is still getting better.

Having two datatypes with the same field name in scope doesn't work well with type inference. OCaml permits it, but it requires type annotations, and in practice it seems like developers solve the problem the same way Haskell does -- separate modules.

That said, working with modules is a lot nicer in OCaml than in Haskell, so it's a less painful solution.

What do you mean hacked together? It looks like most any other ML for the most part.

And what poorly thought out semantics?

ML actually has a formally specified semantics. Haskell does not.

OCaml doesn't either.

Sure, for a subset of the language. But the point is, a hand-wavy complaint about PL semantics (which can be precisely defined) doesn't make sense when comparing languages in this context.

Do you mean:

http://sml-family.org/sml97-defn.pdf

That's the one for Standard ML, yes. There are others for SML, some using proof assistants [1]. Other (S)ML extensions have formal semantics as well, and OCaml itself is partially specified [2].

[1] https://github.com/CakeML/cakeml

[2] http://www.cl.cam.ac.uk/~so294/ocaml

Both are great languages and worth learning. All programming languages have quirks.

Reply on news.ycombinator.com