5 ms·

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 hac

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.

e_d_g_a_r 11y ago
What do you mean hacked together? It looks like most any other ML for the most part. And what poorly thought out semantics?
jallmann 11y ago
ML actually has a formally specified semantics. Haskell does not.
- brians 11y ago
  OCaml doesn't either.
  - jallmann 11y ago
    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.
- codygman 11y ago
  Do you mean: http://sml-family.org/sml97-defn.pdf http://sml-family.org/sml97-defn.pdf
  - jallmann 11y ago
    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 https://github.com/CakeML/cakeml [2] http://www.cl.cam.ac.uk/~so294/ocaml http://www.cl.cam.ac.uk/~so294/ocaml
alextgordon 11y ago
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.
- issaria 11y ago
  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 https://wiki.haskell.org/Name_clashes_in_record_fields
- elihu 11y ago
  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.
  - kuschku 11y ago
    Or one could use the lisp-way – and just call the functions <record-name>-<field-name>. This avoids those problems.
    - gmfawcett 11y ago
      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.
elihu 11y ago
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.
- ufo 11y ago
  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.
creichert 11y ago
Both are great languages and worth learning. All programming languages have quirks.

e_d_g_a_r 11y ago

What do you mean hacked together? It looks like most any other ML for the most part. And what poorly thought out semantics?

jallmann 11y ago

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

brians 11y ago
OCaml doesn't either.
- jallmann 11y ago
  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.
codygman 11y ago
Do you mean: http://sml-family.org/sml97-defn.pdf http://sml-family.org/sml97-defn.pdf
- jallmann 11y ago
  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 https://github.com/CakeML/cakeml [2] http://www.cl.cam.ac.uk/~so294/ocaml http://www.cl.cam.ac.uk/~so294/ocaml

alextgordon 11y ago

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.

issaria 11y ago
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 https://wiki.haskell.org/Name_clashes_in_record_fields
elihu 11y ago
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.
- kuschku 11y ago
  Or one could use the lisp-way – and just call the functions <record-name>-<field-name>. This avoids those problems.
  - gmfawcett 11y ago
    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.

elihu 11y ago

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.

ufo 11y ago
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.

creichert 11y ago

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