Live data from Hacker News

OCaml 4.03: Everything else

blogs.janestreet.com

81–84 of 84 posts

Re: OCaml 4.03: Everything else

#81
post #8

Earlier quoted context omitted.

I've only written Haskell, but I'll try to give a fair shakedown from my perspective: + OCaml is eagerly evaluated while Haskell is lazily evaluated. This makes it easier to reason about things like memory use in OCaml. + IO is reflected in the type signature of Haskell functions. You may find this annoying because it stinks to have to change a lot of type signatures just because, e.g., you want one of your utility f…

> IO is reflected in the type signature of Haskell functions. What you mean is, "effects are reflected". Haskell has a monadic effect system (IO is very rough-grained part of it), which can be combined via monadic transformers. Situations where you don't want to use OCaml: - you need good parallelism and using multiple processes are not enough (concurrency is fine, though) - you want a large pool of developers (also…

> What you mean is, "effects are reflected". Haskell has a monadic effect system (IO is very rough-grained part of it), which can be combined via monadic transformers.

Technically I'm on solid ground, IO _is_ reflected in the type system and not all effects are (memory use being the big omission, which we both mention). Saying "effects are reflected" is probably more helpful though.

> monadic transformers

There are ways combine capabilities without using monad transformers. For instance with typeclasses (if any non-haskellers are reading this here's an example: https://github.com/commercialhaskell/stack/blob/8b010060b0d7...).

> IMHO, the Haskell equivalent to Merlin/ocp-indent are not nearly as good, or at least were not as a few years ago

Editor tooling is still a big weakness of haskell:( A lot has been done on it though and progress is starting to pick up.

I agree 100% with your other points.

Re: OCaml 4.03: Everything else

#82

I really hope modular implicits will make it to the language one day. While OCaml libraries are no stranger to monads they usually only include `bind` and `return`. Since I'm coming from Haskell I'm used to a vast Applicative and Monad vocabulary and making do with just `bind` and `return` is rather painful. So having a generic library of Monad combinators that one could use with any Monad would be great. Also, being…

I have this library:

https://github.com/Chattered/ocaml-monad

and use it regularly when writing Ocaml. I'd like to get back to it and try to implement some MTL style interfaces (MonadState etc...). Edward Kmett says this is not likely to work, but that sounded like a wager to me.

Re: OCaml 4.03: Everything else

#83
post #59

If I were already sold on using Haskell or OCaml for a new project, what would be the big seller for OCaml being the choice? I haven't dug into SML or OCaml and I'm not expert with Haskell yet but from looking at them they don't look substantially distant from Haskell.

I would strongly recommend looking at Racket and/or Closure. I tried the Haskell world and what a hassle to get it working on more then one machine the same way. The package management in Haskell is still more painful then other systems and is overly taxing. I work at two locations both using the same exact Dell machine with OpenSUSE and both gave problems. I also tried it on two windows machines and ugh. OCamal also…

I'm messing with Clojure now and really enjoying it. Haskell was fun but hassle is definitely the right word for pretty much everything other than writing individual functions in it. Package management was really the thing that drove me to say "this is really cool, I'm going to come back when it's more friendly or I have more time."

Re: OCaml 4.03: Everything else

#84
post #76
post #34

Earlier quoted context omitted.

Many commercial companies (and startups) use OCaml, eg Facebook, Bloomberg, etc https://ocaml.org/learn/companies.html

I am aware companies, big companies, use OCaml. My point, perhaps not made clear, is that Jane Street is building useful libs, and contributing back to OCaml with 'batteries included' type libraries. Facebook creating a VM and programming language compatible with PHP may be useful to some, but is not addressing the more fundamental needs or issues like bringing multicore to OCaml.

I think that does a disservice to the much greater number of people who are not at Jane Street but contributing useful code and libraries. You also seem to imply that Jane Street is the one 'bringing multicore to OCaml' but that's not the case.

Jane Street certainly contributes a huge amount to the ecosystem, both in terms of code and other support, but they're not the only people pouring effort into it.

Post reply on HN