Now hold on a second... i learned O'Caml in an intro course also, and yeah, it was pretty annoying at the time, but since then, i've looked into it independently, and it really does seem like quite a nice language. Incidentally, Doug Bagley's Shootout was one of the first pieces of evidence i found that O'Caml is actually a language you can get real work done in. Aside from that, i emailed one of my professors and got his opinions on the language. He said that unless he's writing driver code, or something similarly low-level, it's his language of choice, adding that it's a shame industry is so harsh to newer languages.
Ok, about O'caml [O'caml = Objective Caml = a variant of ML with objects]. I had to use it for a PL class last semester. It's kind of nice, but don't expect it to be in any way like any language you've ever used (unless you know some other ML variant, of course).
This is true -- it's unlike anything you've ever used before. But that's not a bad thing, necessarily! This is a different way of thinking about programming, and many people feel it's better than the traditional procedural models.
In many ways it's very nice. In other ways it will drive you absolutely insane. For example, O'caml has very strong typing rules (which are good). It has almost no diagnostics when it decides it doesn't like your code (which is very very bad). It also apperantly sometimes gets very confused. For example, sometimes you'll get something like this:
Almost no diagnostics? Did you use the debugger? ocamldebug has many features of gdb, supposedly. Although i'll admit i have little experience with it, from what i've seen, it provides a comprehensive debugging environment.
Granted, the interactive interpreter has few debugging features, but it's not really meant for debugging large chunks of code -- that's why they have a debugger:)
foo.ml, line 100, chars 16-30: this expression has type int, but is used here with type int
This can be a little maddening after a few hours.
This happens when you write screwy code -- the types may have the same name, but they aren't the same underneath. That's another thing you have to look out for -- things don't change, they just get new environments. This is what functional programming is all about, and why it's much better for certain tasks (like things where you have to step back, or undo -- think web browser, text editor...). Incidentally, i doubt it happens with built-in types like int...
Other annoyances: no function overloading. So to print a string, use print_string. To print an int, use print_int. And so on. This is just how it works (I think you can write a wrapper which will check the type and dispatch the right call, but that's fairly irritating in and of itself).
No function overloading equates to good type-checking. If you allow functions or operators to be overloaded, you compromise the type inference system, which is one of the nicest features of O'Caml. (Besides, you can do things like print_string "n = " ^ (string_of_int n). You just have to be a bit more cognizant of what you're passing around...)
Another thing that irritates me (probably just because I'm from a C/C++/Perl background), is that sometimes you use no ';' to end a statement, sometimes one, sometimes a pair.
You only use a single semi-colon when you want to throw away the return-value of an expression -- it's an imperative feature. That's what's so cool about O'Caml: it doesn't tie you down to any one paradigm, but rather it supports them all -- functional, imperative, object-oriented,...
And the double semi is for when the compiler can't tell you've started a new statement. It actually makes quite a bit of sense once you understand the reasoning behind it.
Also, I found the documentation to be very erratic (the modules docs are quite complete, but try finding simple examples of how to do OO, without reading the BNF grammar they put in the docs - that's no way to learn a language).
Unfortunately, i'm inclined to agree with you here. Their documentation is very erudite, and difficult to comprehend. And regrettably, there are almost no good books on the language. (My professor pointed me to The Functional Approach to Programming, by Couisneau and Mauny, but it's more of a textbook, and doesn't cover the object-oriented features of the language.) Presumably this is due to the fact that big businesses don't recognize O'Caml by name (case in point: how many good C books are there? what about LISP?).
Nice stuff: strong typing, cool type matching stuff, bytecode and native compilers, seems like a decent module system.
Regarding the module system, i don't have enough experience to say anything intelligent about it myself, but all my professors are in love with it. They say it's more advanced than anything available, even in Java (the other language they teach us).
But if you don't already know it, good luck. You'll need it.
You make it sound so painful!:) On the contrary, i think any geek who gives it a whirl will find it refreshing and mind-expanding. <strike>Like LSD!<strike>
some nice pointers to things i'd forgotten about. see, i only learned a subset O'Caml in an intro to CS course, and i've been trying to grok the rest of it lately. it really seems like a nice language, and it's a shame the moderators took my mention as flamebait!:)
majiCk, who ponders the futility of posting to a yesterday-story. . .
Re: my own disagreement, on the Kubrickean ending
on
Review: A.I.
·
· Score: 1
Without fail, Kubrick's protagonists are always caught in pursuit of an illusory state of desire that ironically prevents them from achieving true happiness. [...] And that's why practically every Kubrick fan on the IMDB who wrote a review said the movie should have ended there... [...] Then of course Spielberg spread his garbage at the end.
if you look at the ending given (which, it has been pointed out by many, was in fact Kubrick's original ending in the story boards), David does fit the traditional Kubrickean model for a tragic protagonist. His illusory state of desire compels him to ask the aliens to resurrect his mother -- not for her own benefit, but so that he himself might be loved, and feel fulfillment. He fails to achieve true happiness because (1) his mother will be gone when the day closes, and (2) he will have in effect ``used'' his mother to fulfill his own existence. Ironically, he has in doing so achieved one thing he wanted all along -- a human personality. Just like the humans who created him to fill a gap, he had his mother re-created to fill his own gap.
Now is that really so non-Kubrickean? I think of myself as a Kubrick fan, and i walked out of the theater delighted. Kubrick's mastery shown through the entire time, and Spielberg's touches only enhanced the experience.
Re:The grey beings were of the Path
on
Review: A.I.
·
· Score: 2
i think it's interesting how you say the ending is clearly Spielberg's doing, and non-Kubrickean, since it seems so stapled-on for the sole purpose of providing a happy close for Hollywood movie-goers, but then go on to say that if Spielberg really thought this ending was happy, he was a fool. You're contradicting yourself, but if you analyze what you say, it brings a great deal to light. You got more out of this ending than i managed to, and i thank you for enlightening the rest of us, but i think you would be more satisfied if you took into account the fact (pointed out by many already) that the ending was in fact, Kubrick's, from the very beginning.
Hear, hear. I'm sick of seeing freshly-minted Java programmers grunt out mounds of steaming O(n!) code, believing that "this is good cuz it's Java."
I don't understand the association of Java with inefficient code. Actually, it seems like the opposite would result -- Java programmers, knowing the excruciating slowness of every step, will try the hardest to minimize the number of steps in program flow.
Big-Oh analysis was a major topic in my second-semester intro to CS course, which used none other than Java as its teaching language of choice. Personally, it seemed like a good idea to me -- teaching high level concepts should not require knowledge of how to allocate memory and what's going on at the register level. Those are mere details to the computer science of it all.
You, sir, are a moron. (No personal offense, of course...)
The QWERTY keyboard could not have been designed to better distribute typing load over both halves of the keyboard, because there are so very many words that can be typed with only one hand using the QWERTY layout. Just off the top of my head, i can think of: (left hand) stargazer, traders, barges, grades, trees, created, eraser, better, etc. (heh heh), and (right hand) pumpkin, lollipop, monk, hoop, knoll, yoohoo. (As an interesting aside, i think there's something like one word over three letters than can be typed using only one hand on a Dvorak simplified layout.)
What's more, many more words reside almost entirely on one half of the keyboard. For example, in the above paragraph, "distribute" takes only two characters from the right half of the keyboard; "because" takes only one. "philosophy" takes just one measly character from the left half.
These sorts of things are all too common with the QWERTY layout, and they're often the cause of errors, simply because one hand isn't fast enough to type an entire word accurately. Try it yourself -- pay attention to your typing sometime, and see what you notice.
AC1: war speeded up technology
AC2: what does WW1/WW2 have to with things like lightbulb/sanitation/plumbing?
SM: war was possible because of them
AC2: hmmm sure, but that's irrelevant in discussing the article . my point remains: war did not speed up the discussed technologies.
Well, he didn't exactly say war was possible because of them -- he said Hitler was the first to make use of such technologies. And Hitler was a key player in (correct me if i'm wrong) World War II. And i never liked history too much, but i'm quite sure there was another rather large skirmish prior to World War II...
(I can't honestly comment on whether his statements are accurate or not, but your logic against them is certainly flawed.)
Slashdot Mirror
Now hold on a second... i learned O'Caml in an intro course also, and yeah, it was pretty annoying at the time, but since then, i've looked into it independently, and it really does seem like quite a nice language. Incidentally, Doug Bagley's Shootout was one of the first pieces of evidence i found that O'Caml is actually a language you can get real work done in. Aside from that, i emailed one of my professors and got his opinions on the language. He said that unless he's writing driver code, or something similarly low-level, it's his language of choice, adding that it's a shame industry is so harsh to newer languages.
:)
...
:) On the contrary, i think any geek who gives it a whirl will find it refreshing and mind-expanding. <strike>Like LSD!<strike>
Ok, about O'caml [O'caml = Objective Caml = a variant of ML with objects]. I had to use it for a PL class last semester. It's kind of nice, but don't expect it to be in any way like any language you've ever used (unless you know some other ML variant, of course).
This is true -- it's unlike anything you've ever used before. But that's not a bad thing, necessarily! This is a different way of thinking about programming, and many people feel it's better than the traditional procedural models.
In many ways it's very nice. In other ways it will drive you absolutely insane. For example, O'caml has very strong typing rules (which are good). It has almost no diagnostics when it decides it doesn't like your code (which is very very bad). It also apperantly sometimes gets very confused. For example, sometimes you'll get something like this:
Almost no diagnostics? Did you use the debugger? ocamldebug has many features of gdb, supposedly. Although i'll admit i have little experience with it, from what i've seen, it provides a comprehensive debugging environment.
Granted, the interactive interpreter has few debugging features, but it's not really meant for debugging large chunks of code -- that's why they have a debugger
foo.ml, line 100, chars 16-30: this expression has type int, but is used here with type int
This can be a little maddening after a few hours.
This happens when you write screwy code -- the types may have the same name, but they aren't the same underneath. That's another thing you have to look out for -- things don't change, they just get new environments. This is what functional programming is all about, and why it's much better for certain tasks (like things where you have to step back, or undo -- think web browser, text editor...). Incidentally, i doubt it happens with built-in types like int...
Other annoyances: no function overloading. So to print a string, use print_string. To print an int, use print_int. And so on. This is just how it works (I think you can write a wrapper which will check the type and dispatch the right call, but that's fairly irritating in and of itself).
No function overloading equates to good type-checking. If you allow functions or operators to be overloaded, you compromise the type inference system, which is one of the nicest features of O'Caml. (Besides, you can do things like print_string "n = " ^ (string_of_int n). You just have to be a bit more cognizant of what you're passing around...)
mjd (of perl fame) actually gave a nice talk on why strong typing is so cool -- ML's type system was able to prevent an infinite loop bug! The anecdote starts at slide 27, though for full effect, i'd recommend you read the entire talk
Another thing that irritates me (probably just because I'm from a C/C++/Perl background), is that sometimes you use no ';' to end a statement, sometimes one, sometimes a pair.
You only use a single semi-colon when you want to throw away the return-value of an expression -- it's an imperative feature. That's what's so cool about O'Caml: it doesn't tie you down to any one paradigm, but rather it supports them all -- functional, imperative, object-oriented,
And the double semi is for when the compiler can't tell you've started a new statement. It actually makes quite a bit of sense once you understand the reasoning behind it.
Also, I found the documentation to be very erratic (the modules docs are quite complete, but try finding simple examples of how to do OO, without reading the BNF grammar they put in the docs - that's no way to learn a language).
Unfortunately, i'm inclined to agree with you here. Their documentation is very erudite, and difficult to comprehend. And regrettably, there are almost no good books on the language. (My professor pointed me to The Functional Approach to Programming, by Couisneau and Mauny, but it's more of a textbook, and doesn't cover the object-oriented features of the language.) Presumably this is due to the fact that big businesses don't recognize O'Caml by name (case in point: how many good C books are there? what about LISP?).
Nice stuff: strong typing, cool type matching stuff, bytecode and native compilers, seems like a decent module system.
Regarding the module system, i don't have enough experience to say anything intelligent about it myself, but all my professors are in love with it. They say it's more advanced than anything available, even in Java (the other language they teach us).
But if you don't already know it, good luck. You'll need it.
You make it sound so painful!
majiCk
some nice pointers to things i'd forgotten about. see, i only learned a subset O'Caml in an intro to CS course, and i've been trying to grok the rest of it lately. it really seems like a nice language, and it's a shame the moderators took my mention as flamebait! :)
majiCk, who ponders the futility of posting to a yesterday-story. . .
Without fail, Kubrick's protagonists are always caught in pursuit of an illusory state of desire that ironically prevents them from achieving true happiness. [...] And that's why practically every Kubrick fan on the IMDB who wrote a review said the movie should have ended there... [...] Then of course Spielberg spread his garbage at the end.
if you look at the ending given (which, it has been pointed out by many, was in fact Kubrick's original ending in the story boards), David does fit the traditional Kubrickean model for a tragic protagonist. His illusory state of desire compels him to ask the aliens to resurrect his mother -- not for her own benefit, but so that he himself might be loved, and feel fulfillment. He fails to achieve true happiness because (1) his mother will be gone when the day closes, and (2) he will have in effect ``used'' his mother to fulfill his own existence. Ironically, he has in doing so achieved one thing he wanted all along -- a human personality. Just like the humans who created him to fill a gap, he had his mother re-created to fill his own gap.
Now is that really so non-Kubrickean? I think of myself as a Kubrick fan, and i walked out of the theater delighted. Kubrick's mastery shown through the entire time, and Spielberg's touches only enhanced the experience.
i think it's interesting how you say the ending is clearly Spielberg's doing, and non-Kubrickean, since it seems so stapled-on for the sole purpose of providing a happy close for Hollywood movie-goers, but then go on to say that if Spielberg really thought this ending was happy, he was a fool. You're contradicting yourself, but if you analyze what you say, it brings a great deal to light. You got more out of this ending than i managed to, and i thank you for enlightening the rest of us, but i think you would be more satisfied if you took into account the fact (pointed out by many already) that the ending was in fact, Kubrick's, from the very beginning.
don't you feel all warm and tingly now?
Hear, hear. I'm sick of seeing freshly-minted Java programmers grunt out mounds of steaming O(n!) code, believing that "this is good cuz it's Java."
I don't understand the association of Java with inefficient code. Actually, it seems like the opposite would result -- Java programmers, knowing the excruciating slowness of every step, will try the hardest to minimize the number of steps in program flow.
Big-Oh analysis was a major topic in my second-semester intro to CS course, which used none other than Java as its teaching language of choice. Personally, it seemed like a good idea to me -- teaching high level concepts should not require knowledge of how to allocate memory and what's going on at the register level. Those are mere details to the computer science of it all.
CS is about algorithms, not hardware.
You, sir, are a moron. (No personal offense, of course...)
The QWERTY keyboard could not have been designed to better distribute typing load over both halves of the keyboard, because there are so very many words that can be typed with only one hand using the QWERTY layout. Just off the top of my head, i can think of: (left hand) stargazer, traders, barges, grades, trees, created, eraser, better, etc. (heh heh), and (right hand) pumpkin, lollipop, monk, hoop, knoll, yoohoo. (As an interesting aside, i think there's something like one word over three letters than can be typed using only one hand on a Dvorak simplified layout.)
What's more, many more words reside almost entirely on one half of the keyboard. For example, in the above paragraph, "distribute" takes only two characters from the right half of the keyboard; "because" takes only one. "philosophy" takes just one measly character from the left half.
These sorts of things are all too common with the QWERTY layout, and they're often the cause of errors, simply because one hand isn't fast enough to type an entire word accurately. Try it yourself -- pay attention to your typing sometime, and see what you notice.
AC1: war speeded up technology
AC2: what does WW1/WW2 have to with things like lightbulb/sanitation/plumbing?
SM: war was possible because of them
AC2: hmmm sure, but that's irrelevant in discussing the article . my point remains: war did not speed up the discussed technologies.
Well, he didn't exactly say war was possible because of them -- he said Hitler was the first to make use of such technologies. And Hitler was a key player in (correct me if i'm wrong) World War II. And i never liked history too much, but i'm quite sure there was another rather large skirmish prior to World War II...
(I can't honestly comment on whether his statements are accurate or not, but your logic against them is certainly flawed.)