Why O'Caml is not my favorite programming language (2007)

To compare, in F# you'd have:

> let add3 x = x + 3 val add3 : int -> int

Plain numeric literals are int (32-bit integer). To make it generic:

> let inline add3 x = - let one = LanguagePrimitives.GenericOne in x + one + one + one;; val inline add3 : ^a -> ^e when ( ^a or ^b) : (static member ( + ) : ^a * ^b -> ^c) and ^b : (static member get_One : -> ^b) and ( ^c or ^b) : (static member ( + ) : ^c * ^b -> ^d) and ( ^d or ^b) : (static member ( + ) : ^d * ^b -> ^e)

Perhaps not pretty, but inlining provides a quick way around some limitations on generics.

While strings are not arrays, they are sequences (IEnumerable in .NET). Sequences can be infinite, so there's no Seq.reverse. But:

> "hello" |> Seq.toArray |> Array.rev ;; val it : char [] = [|'o'; 'l'; 'l'; 'e'; 'h'|]

Doesn't sound like you read the article IMHO.

The article is from 2007, the syntax extension you mention is from GSoC 2008. And I think it's legitimate to attack a language's out-of-the box features even if someone somewhere has written an optional parser extension to address the problems.

Yawn ... The syntax of OCaml is tremendously regular once you understand it (and the examples he gives there are using the toplevel which indicates he's not used it very much).

Compare the syntax of OCaml (and ML in general) for:

(1) defining functions

(2) defining ordinary variables

(3) static variables

(4) variables scoped to two functions

with the same for your favourite imperative/OO language.

Here's the OCaml syntax:

(1)

    let f x = ...

(2)

    let v = ...

(3)

    let f =
      let v = ... in
      let f () = ... in
      f

(4)

    let f, g =
      let v = ... in
      let f () = ... in
      let g () = ... in
      f, g

... from 2006

Caml didn't change much in the last 4 years, so it could potentially interesting blog post.

Its not, though.