|
![](/i/fill.gif) |
So today I started learning (or at least familiarising myself with)
Ocaml (Objective CAML). But this isn't going to well; I find myself
continually screaming at the computer screen "YOU'RE DOING IT WRONG!"
If you don't care about why Ocaml is wrong and why Haskell is better,
you can stop reading now.
As best as I can determine, Ocaml is some sort of hybrid of Java and
Haskell. It's "mostly functional" and has syntax resembling Haskell, but
it also has object-oriented features.
Personally I prefer the 100% pure approach of Haskell. But hey, maybe
sometimes it's better to be pragmentic and go with a hybrid approach. It
could be interesting to at least see how that works out, right?
I get the impression Ocaml is from academia too (just like Haskell), but
it's designed especially with a focus on performance. This alone
probably explains why it's strict (like C, Java, VB, C#, Pascal...)
rather than lazy (like Haskell). Making Ocaml strict rules out all sorts
of possibilities, and gives lower performance in some cases, but it
makes performance *predictable*. And that's probably the Big Reason for
this design choice. [It also makes several implementation details much
simpler.]
Problems become apparent almost immediately. I had a look at the Great
Language Shootout, where I found Ocaml getting royally OWNED by both C
and C++, mainly because both of these used all four CPU cores, while
Ocaml apparently can't. Ocaml supports multiple light-weight threads,
but because the garbage collector isn't thread-safe, all Ocaml threads
run in a single OS thread - i.e., on a single CPU core.
Haskell, of course, runs your threads on several cores, like you'd
expect. (Unless you specifically ask it not to because you're trying to
interface to external C libraries that use thread-local storage.)
Of course, even Haskell currently has a parallel but not concurrent GC,
and in particular to perform a GC cycle you have to wait for all Haskell
threads to stop. (They can only be stopped at certain points.) This can
cause large program slowdowns, where one thread is in a tight loop and
won't stop, and all the other threads are paused waiting to start a GC
cycle.
But hey, all of this isn't really to do with *Haskell*, but rather with
*implementation*. Specifically, I'm talking about GHC. Other
implementations do exist. [Most of them don't support SMP *at all*
though.] You could write another implementation, or fix GHC, and the
above drawbacks would go away. I have no idea how many Ocaml
implementations there are, but it seems plausible you could also make it
to real multithreading too.
Then I started to look at the syntax. It's *mostly* identical to
Haskell, but with a few differences. Most of the differences are just
/different/. Haskell uses one symbol, Ocaml uses a different one. No big
deal. But a few of them are quite nausiating.
In Haskell, I can write
foo = 5
In Ocaml, you must write
let foo = 5
Small bit of superfluous chatter there. Still, I guess it makes the
syntax more consistent. Slightly. But then we get to the next
abomination: In Haskell, I can say
foo = bar foo
but in Ocaml, you must say
let rec foo = bar foo
Yes, that's correct, you have to manually tell the compiler that you're
making a recursive definition. WTF? What, it isn't trivial enough for
the compiler to detect this all by itself? (You might try to argue that
it prevents you writing recursive definitions when you didn't mean to,
but this is *functional programming*! Recursion is ubiquitous!)
Another puzzling thing is that Ocaml appears to use a layout rule
similar to Haskell [not that the tutorial I'm following bothered to
point this out], and yet it still requires explicit semicolons anyway.
(??) And there's a set of fairly complex rules for when you must and
must not write them. (?!?)
Now in Haskell - or in fact any vaguely modern programming language - if
I want to add two numbers together, I say
x + y
BASIC had this, Pascal had this, C had this, Java had this, Smalltalk
had this, and Haskell certainly has this. But not Ocaml, apparently.
Here you must use "+" for adding integers, "+." for adding reals, and
"+/" for adding arbitrary-precision integers. (And presumably some other
symbol for rational numbers, complex numbers, vectors...)
This seems pretty much inexcusible to me. I'm sure there's a technical
reason for why they did it this way, but it seems like a very basic
thing to get wrong. Some languages have overloading, some languages have
classes, and some languages just have interfaces, but all of them seem
to manage to avoid this. As far as I can tell, the above makes it pretty
much impossible to write code that works on more than one number type.
In a similar vein, in Haskell "7" is a number. Any type of number. It
can be anything. But in Ocaml, "7" is an integer, "7." is a real, and I
forget what the syntax for an arbitrary-precision integer is.
In Haskell, you can say "Set Integer" or "Set String" or "Tree Integer"
or whatever. Apparently in Ocaml you have to say this backwards:
"integer tree" and so forth. I haven't yet seen any higher-kinded type
constructors, but it'll be interesting to see how that works!
Haskell uses the convention that type NAMES must begin with a capital
letter, while type VARIABLE must begin with a lowercase letter. Ocaml
uses the arguably superior convention that type variables start with an
apostrophy. (I would have used a different symbol, but it's a reasonably
design choice. Somebody recently pointed out that some Unicode alphabets
have no concept of "uppercase" and "lowercase".)
Which reminds me - in Haskell, "Char" is a 32-bit Unicode character.
Ocaml makes the mistake of using an 8-bit ASCII code. (But apparently
there are libraries to "work around the problem".)
Haskell has a thing called "tuples". A tuple is a fixed-length,
fixed-type collection. For example, you might write a parser function
that takes a string and returns (say) an integer and the remainder of
the string. To do that, you return a 2-tuple containing an integer and a
string.
The literal value of such a tuple can be written as
(5, "rest of string")
and its type is written as
(Integer, String)
Ocaml has the same syntax for writing tuples, but the type signature becomes
integer * string
which seems a rather perverse choice. I can see what they're getting it
(a tuple type is a product type, whereas an enum is a sum type), but
that's still rather far-out.
(Haskell also uses "[Integer]" for a list of integers, and "[3,5,7]" for
a value of this type. In general, the type signatures mirror the value
syntax - possibly to the point of being confusing. Personally, I've
never been that fond of the list and tuple syntax. Sure, lists and
tuples are common, but would it really kill you to write "Tuple2 True 5"
instead of "(True, 5)"? It would be clearer...)
Also, Haskell's "()" type becomes "unit". Which is the name Haskell
programmers use to refer to it, but hey. It's not entirely clear to me
whether Ocaml lets values of type "unit" actually exist - and if so,
what their syntax is.
Haskell has algebraic data types. Every Haskell type is nominally an
ADT. (Although in the case of "Int32", it's an enumeration type with
constructors named "0", "1", "2"...) All types follow the same uniform
structure.
Ocaml, on the other hand, has "records" which are like "{field1=5,
field2=true, field3="hi"}", and "variants" which are like Haskell ADTs.
And they're apparently not the same thing. You can see this when you
define one:
type recordX = {field1 : int, field2 : string, field3 : stuff}
type variantY = Thing of int * string * stuff | OtherThing of char * char
So "records" use named fields, but have only a single (unamed)
constructor, while "variants" allow multiple constructors, but use a
wierd syntax for defining the fields - a syntax resembling tuple types,
actually. WTF?
(This quite apart from the parameter of a parameterised variant being
written *before* the variant name, not after it. I wonder if you can
have multiple parameters on a variant? I haven't seen any examples
showing this. I also haven't seem any parameterised records, so I'm not
sure if that's supported. I'm also not sure how it knows from looking at
a record which type you mean...)
Haskell makes the rather illogical choice of using "--" as the start
marker for a comment. (Great. So I can't use that as a name then!) But
Ocaml uses the even stranger choice of "(* ... *)". Which means that you
can't write "(*)" to mean the multiplication function, you must write "(
* )" [with spaces] to prevent it parsing as a comment.
[Then again, Haskell has a glitch with the unary minus function...]
Also, Haskell uses "++" for string (and list) concatenation. But Ocaml
inexplicably uses "^" instead. (Haskell uses both "^" and "**" to mean
exponent - but one is with an integer exponent and the other is with an
arbitrary exponent. No, I can never remember which is which.)
Things don't get any better when you start looking at the build process.
In Haskell, if I want to compile a multi-module program, I say
ghc --make MyThing
GHC will then automatically build the entire dependency tree, detect
what libraries you need, check what (if anything) needs to be
(re)compiled, compile it, and link everything to give you MyThing.exe.
Hell, if a module has changed, it'll recompile it, but then it takes a
hash of the interface file. If the module's implementation has changed
but its implementation has not, the module will be recompiled, but
anything depending on it will not.
It can even spit out a makefile if you wish, automatically generated
directly from the source code. But usually, you just DON'T NEED make at
all. GHC does it all for you.
In Ocaml, things are not so easy. Apparently YOU have to manually
determine the correct order in which to compile things, and issue all
the commands in the right order. (Or just use make.) You even have to
compile and seperately link things - and tell the compiler whether it's
supposed to be compiling or linking, and manually tell it what libraries
to include. *sigh*
It gets even better though. If you write a source file and compile it,
*everything* inside is public. If you don't want that, you have to
*manually* copy and paste the names of the public stuff into an
"interface file", and you apparently have to manually write in the
correct type signatures. (So much for "Ocaml does automatic type
inference".) You then have to insure that this file is compiled at the
right moment - i.e., after the corresponding source file is compiled,
but before anything depending on it is compiled.
Again, in Haskell you just write a list at the top of the source file
saying what things should be public. The compiler does the rest. Even if
you're manually running the compiler stages for some reason, the right
thing happens. The object file and interface description are generated
automatically in a single pass, and dependencies won't compile until
these exist.
It is *claimed* that you can compile Ocaml into a library that can then
be linked into programs written in arbitrary other languages (C or
whatever). If so, that would certainly seem like an advantage. OTOH,
Haskell can supposedly do this too - it's just that it'll be a bloody
huge library! (Because it will contain a copy of the entire Haskell RTS.)
Actually, the latest version of GHC supports [on Linux only] dynamic
linking now, so a Haskell library can be dynamically loadable, and the
RTS can be dynamically loadable, and any other libraries you're using
can be dynamically loadable. So if your C program uses 5 Haskell
libraries, you still only have to link one (dynamic) copy of the RTS
[which is fairly big].
It seems everywhere I look, Ocaml does the same things that other
languages have done, but does them wrong. The bits that are right are
identical to existing languages. The bits that are new are almost all wrong.
Post a reply to this message
|
![](/i/fill.gif) |