Why We Use OCaml

I had written a synchronous interface for some functionality, that had quite a bit of input data. It called an external web api twice, once to post some data, then a recursive check to periodically ping the API until some changes took effect (yes, none of this was ideal, but I couldn't change the API).

I later realized that the code calling this interface needed to do some work in between these two calls. To refactor it into two calls would be a lot of work, and require a lot of book keeping, passing variables around or recalculating them, etc, and bloat the code.

Instead, I just wrapped the second call in a closure, changing the interface; now rather than returning the result of that second function, it just returned that second function, which the calling code could invoke after it did its work.

That is, I went from

  calling_func() ->
    Val = interface();
    ...

  interface() -> 
    ...//Do stuff to calculate vars
    do_work1();
    do_work2(Var1, Var2, ...);

  calling_func() ->
    SynchFunc = interface();
    ...//Do whatever needs to happen between the two calls
    Val = SynchFunc();
    ...

  interface() -> 
    ...//Do stuff to calculate vars
    do_work1();
    fun() -> do_work2(Var1, Var2, ...) end;

  calling_func() ->
    Val = interface(fun() -> ... end);

  interface(Func) ->
    ...//Do stuff to calculate vars
    do_work1();
    Func();
    do_work2(Var1, Var2, ...);

  interface() -> interface(fun() -> pass; end)

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...