Some reasons on why OCaml and functional programming are great

OCaml is the language my partner and I decided to use for developing our compiler project described here. I had not touched OCaml before taking the course, but given CMU’s focus on teaching some core classes with a functional language (SML), it was not hard to adjust. However, it’d probably be a bit uncomfortable to work with this language at first for peopsle who’ve never touched functional programming. Since the time I was first introduced to the language, I’ve grown quite fond of it for reasons I’ll cover here.

Typing System

OCaml relies on the Hindley-Milner algorithm to infer the most general type for every expression in (near-)linear time. This is awesome because we are guaranteed no surprise casts happen without even writing boilerplate annotations! The resulting strong static checking catches entire bug classes—type mismatches, inexhaustive pattern matches, wrong arity, mislabeled records—before the program runs. Note that we still have polymorphic types like 'a list for more flexible functions without sacrificing safety.

Algebraic Data Types


1
2
3
 type shape =
  | Circle of float
  | Rect of { w : float; h : float }

Algebraic data types (ADTs), put simply, are data types formed by combining other types. The reason this is so nice is that illegal states become unrepresentable. With the above example, a circle can’t part with its radius! In addition, when we actually have to deal with an object of type shape, the OCaml compiler forces you to properly handle every constructor.

A classic role for ADTs is modeling data with multiple cases. Combined with pattern matching, they let you traverse those cases far more safely and concisely than the Visitor pattern.

Immutability First

One of the core concepts in functional programming is the idea of statelessness, where functions do not rely on or modify external states. A part of enforcing this is having bindings, records, lists, and other objects that are immutable by default.

Why is this nice? Reasoning and testing become that much more straightforward. No more worrying about a shared variable having hidden writes.

Something that this style of programming encourages is thinking about solving problems recursively. Consider how you might write a function that sums all even numbers in Python (imperatively). It’d be something like this:


1
2
3
4
5
 def sum_even(sum_list):
  total = 0
  for num in sum_list:
    total += num
  return total

In contrast, with OCaml:


1
2
3
 let rec sum_even = function
  | [] -> 0
  | p :: ps -> p + sum_even ps

Although this example is small, the stylistic gap is already evident. The functional version mirrors the mathematical definition of a list sum, spelling out a base case and an inductive case, whereas the imperative version must carry a mutable total that is updated on every loop iteration. As problems grow in complexity, those extra moving parts often turn an imperative solution into tangled bookkeeping, while the recursive, declarative style scales cleanly and remains easy to reason about.

“But won’t deep recursion break the stack?” OCaml’s tail‑call optimization addresses that: as we covered in the previous post, when the recursive call is in tail position, the compiler rewrites it as a simple jump that reuses the current stack frame.

Finally, another plus I’ll mention is that parallelism becomes safer: multiple threads can read shared data without locks since no one is making mutations.

While OCaml is considered a functional language, there do exist non-functional features one can opt for, like mutations and arrays.

If it compiles, it (probably) works! (Closing Thoughts)

All the traits we’ve discussed combine to form the mantra: “If it compiles, it (probably) works!” Runtime bugs from bad logic can still happen, but structural errors are virtually gone. This makes OCaml a reliable language to work with (that does not compromise speed).

Working in this functional style has reshaped the way I think about problems; framing a task as a recurrence now feels natural and often leads to cleaner, more predictable code than the state‑heavy loops I wrote before.

And why OCaml over its ancestor SML? Quality of life syntax. Small touches like the pipeline operator |>, labeled and optional arguments, and a nicer module system make coding that much smoother.