Plasma GitLab Archive
Projects Blog Knowledge

GODI Project:
Mailing List 
Why Ocaml? 
GODI is discontinued. This is the archived content of the former site

Why Ocaml

After more than 15 years of Ocaml and more than 30 years of ML programmers are still suspected of being crazy when they consider this functional programming language for their daily work. However, times are changing, although slow. Recently Microsoft cloned Ocaml, making it a prime language on their .NET platform. More and more companies try to benefit from Ocaml, mostly in the area of the financial industry and in the Internet business. Ocaml is interesting here because of the rapid speed of development it allows. There is usually a very rational decision in favor of Ocaml - in areas where you cannot just copy what your competitors do, but have to be quicker and better. I've collected some high-level arguments pro Ocaml here.

Free your thinking

After all, programming is also a form of thinking about problems. There is the question how to structure the solution, and to reason why it is finally working. This is not only a matter of mind, but it is actually very dependent on the target programming language. For example, in one of the dominant object-oriented languages you can design the program in terms of classes and their relationship, and of course this has consequences for the way you think about possible solutions. It is likely that you do this by using the terms and concepts the language gives you (e.g. class diagrams). The point here is that Ocaml gives you way more freedom than any mainstream programming language. Ocaml is a "multiparadigm language" - this means it is functional and imperative, it is procedural and object-oriented, allowing you to directly express many ways of thinking about a problem. For example, imagine you want to encode that a certain concept is included in another concept ("x is y"). Java can only express this as class hierarchy. In Ocaml, you can do it this way, too, but it also gives you another option: variant polymorphism. I do not want to discuss here which approach is better for which problem, but the essence is that Ocaml gives you more than one option.

Bigger commercial software projects are nowadays written in many programming languages. Why? Because there is no single language which is good at solving every problem. Each language focuses on a certain programming style, and is the best way of expressing a concise solution for a certain class of problems. This means that we are not talking here about an academic issue. We need access to many programming paradigms anyway. A language like Ocaml is actually badly needed, because it would give a more integrated answer here - instead of using many languages together, one can ideally focus on a single multiparadigm language, and reduce the friction caused by language barriers enormously. Well, in reality it won't be a single language, but it would already be gained a lot if we had fewer of them.


Ocaml does not only have expressive talents, but it also speeds up development. This is mostly the result of a division of labor: The programmer acts as creative designer of the code, and the compiler checks whether it matches the basic design rules. These checks, carried out by the type checker, are more extensive than in mainstream languages. There are many reports from programmers that the program immediately worked perfectly after the compiler checks were passed. Although there is no guarantee, the likeliness of such success is higher than in mainstram languages. The reason for this is that the mentioned design rules (the type system) allow the programmer to add statements about the logical skeleton of the program, to a degree that can be expressed in types and checked automatically. And if the compiler can find problems this is always quicker than manually debugging the code.

There are more features that contribute to the increased productivity. For example, Ocaml encourages the programmer to reduce stateful programming. Keeping states consistent is one of the big challenges of programming - for example, one variable of the state could store a container with elements, and another one could store the number of such elements. It is not always easy to keep both variables synchronized. One approach to address this problem is to encapsulate the state and to permit only privileged operations to modify it. This is still the only possibility in many languages. Ocaml, of course, provides a second option, which is less intrusive: One can enforce that the two variables of the state can never be changed individually, but only together. This disciplines the programmer, as adding code for modifying one variable cannot be done without addressing the other variable. This is the essence behind the so-called stateless programming, which does not mean that the state goes away, but that it cannot be modified arbitrarily any longer, and is subject to the rules of functional composition (i.e. passing whole values down to a function, or returning them from a function).

The runtime

Another big plus of Ocaml is the runtime environment. The Ocaml compiler generates machine code running at 100% speed. There are no costs for interpretation, or for JIT-compiling at runtime. Furthermore, Ocaml includes an excellent memory manager. Because some of the possible programming styles generate high memory allocation rates, it is important that the memory manager can keep up, and does not excessively consume time for deallocation (garbage collection). Another plus is that it is not necessary to pre-allocate memory as for Java runtimes. If the Ocaml program needs more memory, it just asks the operating system for it, and when memory can be freed, it is given back to the OS. This flexibility makes the runtime well suited for many tasks, from the short-living query client to the 24/7 running server cluster.

The Ocaml runtime is relatively small and well understood, and does not feel like a big monolith where you do not really know what is going on inside. As a result, the Ocaml runtimes are very predictable - code optimizations have usually the expected effect.

The runtime can easily be extended on the C level. This is very common, as it allows immediate access to a plethora of C libaries. The converse is also possible: Embed an Ocaml program into a C library.

Open Source

Finally, Ocaml is open source. The source code is freely available. Compared with some mainstream languages, this means that there is no company that owns the language (in the sense that Java is owned by Oracle, and C# is owned by Microsoft), and the development and promotion is not mainly driven by commercial interests.

This certainly effects that Ocaml has had a slower start, but eventually I'm sure it will be an advantage. It gives the user a number of rights the commercial vendors cannot grant: Full introspection into every detail, independence of company decisions, the right to modify Ocaml, and to run it on every platform.

This web site is published by Informatikbüro Gerd Stolpmann
Powered by Caml