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 <i>did</i> 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.<p>So for example I think criticism like <i>The conspicuous absence of macros cannot be obscured by the presence of preprocessors</i> 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)
argument #1 : "OCaml sucks because it is not LISP".
argument #2 : "OCaml sucks because it is not LISP".
...<p>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:<p>"Compiler stops after the first error:<p>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!"
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?<p>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...
This article makes me very happy that I'm currently learning F# instead of plain vanilla OCaml.<p>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?<p>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.
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?<p>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?<p>Thoughts?