Interesting writeup. I’ve been using functional languages for many years at work, and over the last 15 or so years I did the round trip from SML through Haskell and recently back to the ML family with OCaml. The jump from SML to Haskell was largely due to the flurry of activity in the Haskell community that seemed to increase about, oh, 5-6 years ago - around the time of RWH and a number of good articles and presentations demonstrating recent developments in the compilers (such as the parallelism libraries). My move to increase the amount of OCaml in my workload is mostly due to the ability to clearly reason about space/time performance of code. A consequence of laziness in Haskell is that it is non-trivial to reason about space and time requirements, as well as how to tune for them via strictness annotations or the use of strict versions of data structures or library implementations. After working through the process a few times, I found it refreshing to return to the ML family and find that I could reason about time/space in my code. I’ll probably split my projects between Haskell and OCaml from here on out - they both have their place, and the both have their limitations/pain-points.
I agree about the cost model, but one aspect of Haskell that I find far superior in a practical sense is the lack of side-effects. From this perspective, OCaml’s standard library is a nightmare. The built-in string type, for instance, is mutable. On the other hand, it’s easy enough to write module signatures for Functor, Applicative, Monad, etc, and build your own IO monad (either using Free or by wrapping () -> a).
I agree that it’s a huge mistake to have a default mutable string type, but I found that having side-effecting functions return unit was enough to help me avoid having them sneak in where they didn’t belong. I was expecting it to be a lot more chaotic since OCaml doesn’t rely on the IO monad, but I was pleasantly surprised how good a job unit was able to do on its own.
I used it last year for a small tool and wrote up a summary of my experience: http://technomancy.us/170
I liked it a lot; it helped me better articulate some of the things that commonly cause unnecessary problems when using Clojure, but mostly it was just a ton of fun. I was surprised how quickly I was able to get something useful working in OCaml with minimal experience. The new book is great, and the tooling has improved dramatically since I have it a try ~two years ago.
The main downside is that every time I see nil used in any other language I’m filled with lamentation over how much better things could be.
Interesting writeup. I’ve been using functional languages for many years at work, and over the last 15 or so years I did the round trip from SML through Haskell and recently back to the ML family with OCaml. The jump from SML to Haskell was largely due to the flurry of activity in the Haskell community that seemed to increase about, oh, 5-6 years ago - around the time of RWH and a number of good articles and presentations demonstrating recent developments in the compilers (such as the parallelism libraries). My move to increase the amount of OCaml in my workload is mostly due to the ability to clearly reason about space/time performance of code. A consequence of laziness in Haskell is that it is non-trivial to reason about space and time requirements, as well as how to tune for them via strictness annotations or the use of strict versions of data structures or library implementations. After working through the process a few times, I found it refreshing to return to the ML family and find that I could reason about time/space in my code. I’ll probably split my projects between Haskell and OCaml from here on out - they both have their place, and the both have their limitations/pain-points.
I agree about the cost model, but one aspect of Haskell that I find far superior in a practical sense is the lack of side-effects. From this perspective, OCaml’s standard library is a nightmare. The built-in string type, for instance, is mutable. On the other hand, it’s easy enough to write module signatures for Functor, Applicative, Monad, etc, and build your own IO monad (either using Free or by wrapping () -> a).
I agree that it’s a huge mistake to have a default mutable string type, but I found that having side-effecting functions return unit was enough to help me avoid having them sneak in where they didn’t belong. I was expecting it to be a lot more chaotic since OCaml doesn’t rely on the IO monad, but I was pleasantly surprised how good a job unit was able to do on its own.
Have to admit that I interpreted the title as lamenting OCaml; turns out it’s really positive.
How many lobsters are using OCaml?
I used it last year for a small tool and wrote up a summary of my experience: http://technomancy.us/170
I liked it a lot; it helped me better articulate some of the things that commonly cause unnecessary problems when using Clojure, but mostly it was just a ton of fun. I was surprised how quickly I was able to get something useful working in OCaml with minimal experience. The new book is great, and the tooling has improved dramatically since I have it a try ~two years ago.
The main downside is that every time I see nil used in any other language I’m filled with lamentation over how much better things could be.