OCaml Language Sucks | Hacker News Reader

OCaml Language Sucks

sds.podval.org

29 pointsb-man17 comments

When I was in the Film Club at St. Andrew's College in 1977... (yeah, yeah, walked to school barefeet in a blizzard, only Aurora, Ontario really did have winter blizzards!) Anyhow, Dr. Rupert Ray, the "Master" running the club gave us a piece of advice: When reviewing a film, review the film you saw and not the film you would wish you saw.

So for example I think criticism like The conspicuous absence of macros cannot be obscured by the presence of preprocessors is witty, but it is really reviewing a language that is a dialect of Lisp with a glaring defect rather than reviewing a language that may or may not provide a different solution to the problems that macros solve.

A very thorough argument, albeit with a trollish/link-bait title. Also, please note that the author maintains a Lisp implementation (CLISP) and might have an axe to grind; generally, never take a Lisper's opinion on an ML dialect, or an MLer's on Lisp; the two groups are mutually hostile and philosophically incompatible (kinda like Skinheads vs Trekkies)

For what it's worth - I'm a professional lisp dev who greatly admires the ML family and its ilk (Haskell, Miranda, etc).

I'm not very good with them (yet), but I can appreciate the safety guarantees of a good type system (as long as it has decent inference and can avoid the ridiculous verbosity of Java).

As a rule of thumb, if I want to hack something up quickly, and I use Lisp (or python/perl). If I want something safer, easier to maintain (not necessarily extend though ...), etc I like languages with stronger typing and more powerful static analysis.

argument #1 : "OCaml sucks because it is not LISP". argument #2 : "OCaml sucks because it is not LISP". ...

Oh, and seriously? This one is good for a chuckle. I am convinced that it's an instance of the pattern above. I don't know what version of LISP that does this the author has in mind, but it's not the 50s any more -- we no longer leave batch jobs on punchcards at the computer in the morning to obtain the results in the evening. I would hate if my compiler spat so many errors that the initial, and only pertinent one, scrolled out of the screen:

"Compiler stops after the first error:

Compiler should process the whole compilation unit (normally, a file) unless a total disaster strikes. E.g., if an expression has the wrong type, just assume the type is right and proceed to the next expression. You do not have to generate the executable, just report as many errors as possible!"

To be fair, most compilers do continue on in an attempt to fund further errors, and this is useful. The key is doing so in a way that keeps the errors pertinent. See the first few chapters of Programming Language Pragmatics for some discussion of this.

I second that reference!

Ouch, pretty harsh. Any OCaml fans around want to counter some of those complaints? Are these things that don't bother most programmers, or can be avoided by proper idiomatic code?

I've heard good things about OCaml elsewhere, but my experience with functional languages is limited to a bit of Scheme and Haskell. I've thought about trying out OCaml but this makes me possibly want to reconsider...

I used to be a huge user and advocate of ocaml, but the language is heavily constrained by the standard library, and the maintainers come from a pure research background so they aren't inclined to make it more practical.

For instance, there's no packages for http, json, or xml in the standard library.

Ergh! Sure, some of these things are true, but some just reek of a stubborn refusal to do things the way the language intends for them to be done.

Note how instead of saying, "Ocaml doesn't have with-open-file or unwind-protect", he says, "Here's how you have to do with-open-file and unwind-protect in Ocaml". No! You do not go around trying to turn other languages into Lisp if you want to code in Lisp. If you want to code in Lisp, you code in Lisp.

Similarly, he just dismisses the syntax as "pretty much unreadable". Bollocks. The language syntax is fine. Sure, it's different from what most people are used to, unless said people have used SML or Haskell. But it's a decent synatx - yes, with it's own quirks and problems - which is most certainly not "unreadable".

"No Polymorphism; Cannot add an int to a float - need an explicit cast" - what he means to say is that it's a very strong-typed language. If you use the "O" part of "Ocaml" (Objective Caml", polymorphism exists and works.

Now, a lot of his points are valid, like the one about the standard library. But in general, I feel that he really discredits himself by his persistence in writing Lisp code in Ocaml. When in Rome, do as the Romans do.

(Disclaimer: I've used Ocaml, but not to any grand extend. Maybe 10,000 lines of code written in it. Paradigm-wise, I'd have to say I might prefer Lisp, although I find that CL is slightly annoying often times.)

"Note how instead of saying, "Ocaml doesn't have with-open-file or unwind-protect", he says, "Here's how you have to do with-open-file and unwind-protect in Ocaml". No! You do not go around trying to turn other languages into Lisp if you want to code in Lisp. If you want to code in Lisp, you code in Lisp."

What would be the OCaml solution for the problem that unwind-protect solves? In Haskell, I would use bracket, and appropriately the API documentation of bracket gives the definition of withFile as an example:

  withFile name mode = bracket (openFile name mode) hClose

(see http://haskell.org/ghc/docs/latest/html/libraries/base/Contr...)

FWIW, F# has "using". Between "using" and IDispose, you've got all the resource-unlocking, unwinding, and rollbacks you'd ever want.

I think this article makes it very clear how having a huge existing set of libraries can really put a language into warp drive, whereas not having one means you are going to spend some time re-inventing the wheel. (But even in straight Ocaml, I fail to see the problem)

You can implement your own unwind-protect:

http://caml.inria.fr/pub/ml-archives/caml-list/2003/07/5ff66...

I'm a fan, but I mostly use C++ and Python these days. My counter to the complaints is that I could make a longer list of things that suck about any language out there.

This article makes me very happy that I'm currently learning F# instead of plain vanilla OCaml.

Having said that, some of the code to me just doesn't look right. Like the file open nonsense. Why not just write a generic function and use that whenever you need it? Do you really have to repeat all that nonsense every time? Because if you're basically copying and pasting, maybe you're doing something wrong?

I don't know, since I'm a newbie and I'm on F#, not straight OCaml. I know in F# I can get an open file (with error catching) in just a line or so of code.

You shouldn't believe everything you read on the internet.

1/ if you're a newbie at F#, it is not completely unlikely that all the F# you have ever written was valid OCaml. The languages are that close to each other.

2/ the author's criticism is that OCaml is not LISP, not that OCaml is not F#, so all the complaints he has against OCaml very likely apply just the same (note that I am not saying they are valid complaints) to F#.

I didn't read the article and really don't care to, but I want to know: which of the following languages would HN suggest - OCaml, F# or Scala?

I took a brief look at OCaml a few years ago and have been meaning to try and learn it properly for a long time now, but never got around to actually doing it. From my very very brief look at F#, it looked really nice. Finally, I don't know much about Scala, but since I'm mostly using Clojure for my own coding (and Java + C++ + JNI in work), maybe staying with a JVM language would ultimately more beneficial?

Thoughts?

I'm an ocaml fan, and I agree with some of the complaints, but mostly the last section. The article should've started with that.

Reply on news.ycombinator.com