This article is discussed at several places:

• caml.inria.fr
• Hacker News
• Reddit

To summarize: yes, OCaml is not a Lisp, and no, it is not perfect (what does that mean?). I don’t think the points mentioned in the blog post are relevant for day-to-day O’Caml programmers.

Having studied O’Caml, I think it is an interesting language which can help you build programs you would not even dare write in, say, C/C++/Java: for example, have a look at
Frama-C.

For an up-to-date description of O’Caml, I encourage you to read about its features: the language promotes strong static type checking techniques which allows implementations to focus on producing performant, yet safe, runtimes.

Important: I am no OCaml expert: if you are one of them and see I wrote something horribly wrong, please correct me. I’ll edit this post accordingly.

Static type checking

• False Sense of Security

  This is true, but obvious.

  Static typing gives you proofs you can trust about a subset of your program’s properties. Unless you accept to go all formal, an average (non-toy) program will be subject to programming error bugs which can be witnessed only at runtime.

  That’s when dynamic checking techniques can be applied: the OCaml compiler has flags to generate executables with debugging information, and so on… Or, it can generate code that blindly trust the programmer and erase type information as much as possible. Programmers who wants robust programs should implement dynamic checks explicitly.

  The same thing applies to e.g. Common Lisp, but reversed: dynamic types first, with optional type declarations and compiler directives second.

• Few Basic Types

  Still applies: the core language has not changed (or not dramatically).

• Silent Integer Overflow

  This is the norm in most languages that integer overflow are checked by hands.
  I don’t know of any library that would type-check operations to verify whether overflow can occur.

• Module Immutability

  1. Author mentions Functors but I fail to see how his example cannot be implemented. Reading the First Class Modules chapter of https://realworldocaml.org, it seems that modules can be used to compose and build new modules. Of course, modifying an existing module requires source code modification, but again, this is not unusual among programming languages.

  2. “Semantically, functions are compiled INLINE”

  The reddit thread above disagrees, saying that binding are resolved at link time. However, this is an implementation detail and I think that the emphasized Semantically relates to the way functions are resolved. Example:

   let f x y = x + y ;;
   let g a b = f b a ;;
   let f x y = x * y ;;
   exit (g 2 3) ;;
  

  The above program compiles, and when executed, returns 5, because g is defined with the first version of f, just as-if the calling function g inlined the call to f. This is not “bad”, by the way, it is just consistent with O’Caml’s name shadowing rules.

  To summarize: yes, modules are immutable. But they are also composable.

• Polymorphism Causes Run-time Type Errors

  I can’t reproduce the mentioned error. I suspect it to be a compiler error.

No Macros

Indeed, there are no macros but preprocessors (OcamlP4, OcamlP5, …).

• Wrappers (with-open-file)

  Knowing how UNWIND-PROTECT can be useful, this is indeed painful to see it absent from more languages. Here are some options:

  1. Improving Exception Management In OCaml
  2. Extend OCaml Syntax

• Places

  I don’t think generalized references exist in OCaml.

Minor Language Suckiness

• Record field naming hell

  True, but you should use modules:

  1. Two fields of two records have same label in OCaml
  2. Resolving field names

• Syntax

  Still applies (but really, this is just syntax).

• No Polymorphism

  Still applies, but somehow there are people who prefer that instead of Lisp’s numerical tower (I don’t know why). I suppose it helps with type inference.

• Inconsistent function sets

  See the OCaml Batteries Included project.
  In particular, BatArray, for an example of map2 for arrays.

• No dynamic variables

  Can be implemented:

  1. http://okmij.org/ftp/ML/dynvar.txt
  2. http://okmij.org/ftp/ML/index.html#dynvar

• Optional ~ arguments suck

  By language restriction, you can’t mix optional and keywords arguments in Common Lisp.
  Does it mean it sucks? (off course, this can be changed with macros (see e.g. my answer)).
  See O’Caml’s documentation for optional and named arguments in O’Caml.

• Partial argument application inconsistency

  I don’t think it this is really annoying in practice.

• Arithmetic’s readability

  It holds, but you can use R or Python for numerical problems if you prefer.

• Silent name conflict resolution

  Still applies, but note that this is well documented.

• No object input/output

  Still applies.

Implementation, libraries

These keep changing every day: there is no definitive answer.

Finally,

“You should try OCaml (or, better yet, Haskell) even if you think
it sucks and you are not planning to use it. Without it, your
Computer Science education is incomplete, just like it is incomplete
without some Lisp and C (or, better yet, Assembly) exposure.”

… still applies.

Seeing that the page it quite old (2007): which of the bullets points listed there are still true today?

• False Sense of Security. This is nonsense.

• Few Basic Types. OCaml now has bytes and byte arrays but no built-in unicode strings, 16-bit integers, unsigned integers, 32-bit floats, vectors or matrices. Third-party libraries provide some of these.

• Silent Integer Overflow. Unchanged but it was never a problem.

• Module Immutability. His recommendation that functions and modules should be mutable is a grim throwback to Lisp and a really bad idea. You can supercede modules using include if you want to but you cannot mutate them, of course.

• Polymorphism Causes Run-time Type Errors. This is a big problem with OCaml and it has not been fixed. As your types evolve polymorphic equality, comparison and hashing will start to fail when they encounter types like functions and debugging the problem is very hard. F# has a great solution to this problem.

• No Macros. Ironically, when he wrote this OCaml actually had full support for macros but they have now decided to pull the feature out.

• Wrappers. This was a real problem and it has not been fixed. There is still no try ... finally construct in the OCaml language and no wrapper implementing it in the stdlib.

• Places. Unchanged but a non-problem.

• Record field naming hell. Structure your code properly using modules.

• Syntax. Unchanged but a non-problem.

• No Polymorphism. This was mostly nonsense when he wrote it and nothing has changed.

• Inconsistent function sets. OCaml still doesn’t have a cons function. That’s fine. I don’t want Lisp stuff in my language, thank you.

• No dynamic variables. Was a good thing about OCaml. Is still a good thing about OCaml.

• Optional ~ arguments suck. Optional arguments rock. I badgered Microsoft to get them to add optional arguments to F#.

• Partial argument application inconsistency. Eh?

• Arithmetic’s readability. This has changed since I stopped using OCaml ~8 years ago. Apparently now you can do Int64.((q * n - s * s) / (n - 1L)).

• Silent name conflict resolution. He was trying to do full-blown software development in the REPL as you would in Lisp. Don’t do that in OCaml. Use files and batch compilation resorting to the REPL only for testing, running disposable code and interactive technical computing.

• Order of evaluation. This was wrong when he wrote it. Order of evaluation is undefined in OCaml.

• No object input/output. He cited a third-party library that already solved this “problem”.

• Compiler stops after the first error. Eh?

• No stack trace for natively compiled executables. Fixed.

• Debugger sucks. I never used the debugger. Static type checking catches almost all of my bugs.

• GC sucks. I found OCaml’s GC to be superb except for one major problem: the global lock prevents parallel programming.

• No implicit forward declarations. Mutual recursion is explicit by design in all MLs. The only wierdness is that type definitions are recursive by default whereas let bindings are non-recursive by default.

• Function round is absent. OCaml still has a bare bones stdlib but third party libraries like Jane St’s Core provide round and friends.

• Lists. List.map is still not tail recursive. I submitted patches to fix serious bugs like this and had to wait years before they appeared in releases. Lists are still immutable, of course. And so they should be.

• Speed. I believe the compile times for big polymorphic variants have been fixed.

• Pattern matching. A triumph of hope over reality. The Lisp community have failed to do this. Hence my 10th rule: any sufficiently complicated Lisp program contains an ad-hoc, informally-specified and bug-ridden implementation of half of OCaml’s pattern match compiler.

For instance: is it still true that it is impossible to print a generic object?

When he wrote that you could not simply do:

print value

but you could invoke the pretty printer from the top-level as a library call, giving it the necessary type information. And there was a macro that you can use to annotate data structures in order to have pretty printers autogenerated.