I've used Haskell to build JavaScript tools and analyses[0], among other things[1], and have been using OCaml for the past nine months to develop a software-defined networking controller called frenetic[2]. Off the top of my head, here are a few areas where OCaml has an edge on Haskell:

1. The module system. OCaml's module system is a language in and of itself. It not only allows you to define modules that export certain identifiers and types, it also allows you to write functors, which are essentially functions in the module language that can take a module as an argument and produce a new module as a result. This is a great way of reusing code in a project as well as defining external APIs in a general but natural way. OCaml's module system the closest I've seen to realizing the dream of building software by taking some modules from here or there and composing them together.

2. Mutation. Unlike Haskell, OCaml allows mutation. Specifically, OCaml allows value mutation in certain contexts, while both Haskell and OCaml do not allow variable mutation. What this means is that in both languages, if you have an identifier, you cannot change the value that the identifier points to; you can only shadow the identifier with a new binding. But in OCaml, you can declare certain fields of your types to be mutable. You can also wrap values in a "box" which allows you get the same feel that you would out of variable mutation. While in general it's a good idea to limit your use of mutation, sometimes you know it's ok and you just want to do it. OCaml lets you do that, but it requires you to be explicit about it rather than just letting you do it willy-nilly.

3. gdb-able. If you know how to use gdb (and even valgrind I believe), you can use it to debug your OCaml programs. If you try and use these tools with Haskell, you will get nothing but nonsense until you learn how to read the matrix. This fact by itself for some people will make OCaml a candidate for systems programming over Haskell.

4. Subtyping. Certain features of OCaml's type system allow you to do subtyping, complete with type variable annotations to indicate covariance or contravariance. This is a feature that Haskell's type system does not have, so in a sense this is a strength of OCaml. However in my experience, this feature of the type system is hard to use and reason about, and I've seen little (maybe no?) code in the wild that takes advantage of it, with the exception of some simple inference the type system can do in this respect related to polymorphic variants[3].

All that being said, Haskell's still my hobby language of choice. But for building real systems, I'm warming to idea of OCaml as a viable candidate language.

[0]: http://www.cs.brown.edu/research/plt/dl/adsafety/v1/

[1]: https://github.com/seliopou/typo

[2]: https://github.com/frenetic-lang/frenetic

[3]: https://realworldocaml.org/v1/en/html/variants.html#polymorp...

One more thing: OCaml is strict by default, Haskell is lazy by default. The later allows for some nice code idioms[0], but makes reasoning about performance and memory characteristics very difficult[1].

[0] indexedList :: [a] -> [(Integer,a)] indexedList l = zip [1..] l

[1] http://www.reddit.com/r/haskell/comments/15h6tz/what_isnt_ha...

http://www.haskell.org/pipermail/haskell-cafe/2013-September...

http://stackoverflow.com/questions/2064426/reasoning-about-p...

Or even:

indexedList = zip [1..]

Love how ML-like languages let you express just the bare essence of an operation.

Yea, I didn't do that just to make it clearer: if you aren't used to ML, I Imagine that this would be very confusing.

Neat reply, thanks.

In regards to #2, this sounds like the ST monad, are they comparable at all?

What makes OCaml easier to debug with GDB opposed to haskell specifically? I don't have experience doing either, but that's a curious statement, I would have assumed they were similar (both native code w/ some sort of GC...)

OCaml allows you to use mutation pervasively without marking your type. Haskell requires you mark your type with `IO`, `ST`, `State`. You can see Haskell as advantageous because it means that if you have a type without one of those markers you can be certain there is no observable mutation occurring. You can also see Haskell as disadvantageous because those markers are a little annoying.

The ST monad lets you transition from regions which allow mutation to pure regions and then back again.

Basically, all OCaml code runs in IO. You can still only modify things that you've marked as modifiable (analogous to an IORef), but there is no constraint on where you can modify them from.

(In case it's unclear, I'm agreeing with tel and rephrasing.)

One advantage that gives you, is that you can easily define a monad on top of that and not worry about monad transformers. Jane Streets async library does that in its Deferred module https://ocaml.janestreet.com/ocaml-core/111.17.00/doc/async/...

But I like transformers... a lot!

Your Haskell program doesn't use the C stack, so using gdb may tell you something about the Haskell runtime you're using or some C library you called into, but it won't tell you much about the state of your actual program.

Haskell uses lazy evaluation by default, which makes it hard to reason about the space usage (or termination) of a particular program. OCaml on the other hand is not lazy by default (but supports it if you need it). At least that is one of the reasons why I chose to learn more OCaml than Haskell.

Why do you think termination is easier to reason about in eager languages? I think it's quite the opposite: in lazy languages functions compose, in strict ones they don't necessarily. For example, you cannot compose a "take ten values" and "square all elements" function in a strict language if the argument you apply their composition to has infinite length (e.g. is cyclic).

With a lazy language its not always obvious if a certain expression needs to be evaluated now or not. In particular I was writing some list comprehensions in Haskell, trying to solve some of the project Euler problems, and when I introduced a bug I got an infinite loop. When I fixed the bug I got the correct answer thanks to lazy evaluation, but the buggy code and the correct code looked awfully similar. Maybe it is just my inexperience with lazy languages that caused trouble (I came from C), and learning two radically new concepts: functional programming and lazy evaluation was too steep of a learning curve. Or perhaps list comprehensions aren't really supposed to be (ab)used like that. Unfortunately I don't have that code anymore, it would've made it more clear what I'm refering to...

Maybe it is because you didn't show an example, but that doesn't seem like something caused by lazy evaluation. It is pretty easy to get into infinite loops due to logic errors in Project Euler type problems even when using imperative loops.

Because I can walk through a strict program in my head (or on paper), and see every value, what is being calculated, and what is being stored. With a lazy language, I can't necessarily do that. The entire memory of my program can quickly fill up with thunks. The optimizer determines when things actually get calculated, and I need a much deeper understanding of my code to figure out the space constraints.

Just writing code? I guess I can agree that lazy evaluation makes it easier, but performance still needs to be considered.

The eager vs. lazy distinction is not relevant here. There are some programs that under eager application semantics will not terminate, but under lazy application semantics they will, and vice versa. What complicates reasoning about termination is the presence of mutation. In a lazy language, you'll never have mutation so you don't have to worry about those complications. You could have an eager language with no mutation (e.g., Elm[0]), but for the most part eager languages include some form of mutation and so you may have a harder time proving termination.

[0]: http://elm-lang.org

I don't think that's right. There is a basic theorem in (untyped) lambda calculus that says that if a term has a normal form, then any evaluation strategy, including strict and non-strict, will reduce that term to that normal form. Since non-strict evaluation can "skip" arguments that may have no normal form, there are expressions in non-strict languages that terminate while their strict counterparts don't. The opposite scenario does not exist: if a term has to be evaluated, it has to be done in both the strict and non-strict versions. (And in simply typed lambda calculus, all reduction sequences terminate.)

For (actual) programming languages without mutation and with more than just lambdas and application for control flow, it is right:

    f x y = y
    f (raise Done) Ω

Under lazy application semantics this program will never terminate. Under eager application semantics it will.

It doesn't necessarily have to be that way.

You can have both composable functions and non-wasteful semantics without turning the whole language into a lazy mess.

Note that this approach will also allow you to abstract over different data sources more easily.

It has polymorphic / open variants and a very powerful module system. It is also an impure functional programming language, so you can write straightforward and reasonably fast imperative code in it, if you need to.

A few mentioned in this article are true modules and polymorphic variants. Both can be partially modeled in Haskell, but it's tougher. I feel that almost nobody would disagree that these are advantages of OCaml.

Most people also suggest that strict evaluation and impurity are good traits of OCaml. This is more a contested point, however, as lazy evaluation and strict evaluation are more like duals than one being definitely better than the other. Furthermore, unrestricted side effects are a major tradeoff between convenience and safety—it's up to your use case to decide what's best.

Finally, OCaml obviously has an "O"bject system in it. My understanding is that serious OCamlers shy away from it for reasons of complexity and low value. The major stuff is provided by the module system and doesn't have anything particularly "object" about it.

I would say Ocaml code is much easier to understand as a beginner than Haskell. Even with context I've never been able to just look at some production haskell and get the gist quickly. Ocaml takes work, but I at the very least have an idea of what's going on after giving a chunk of code a once-over.

Here's an example: http://llvm.org/docs/tutorial/OCamlLangImpl1.html

Haskell tries to be exceedingly (some might argue excessivly) clever. OCaml strives to be pragmatic and predictable.

Do you have any specific examples? I ask as someone that has landed on the Haskell boat but still keeps an eye/ear on the Ocaml one ;)

Very small and seemingly innocent changes in a Haskell program can vastly change the runtime characteristics, especially if they introduce a space leak or alter the compiler's strictness analysis.

That isn't a factor at all in OCaml - in fact the compiler is fairly "dumb".

The MLs seem to have better module systems. Or, they have a module system.