3 ms·
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.
by pascal_cuoq 17y ago
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!"
- jasonwatkinspdx 17y agoTo 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.
- amackera 17y agoI second that reference!