>> 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.
>>
>> Of course, even Haskell currently has a parallel but not concurrent GC,
> 
> You're right.  The lack of concurrent GC is the single most important issue to
> be fixed today, even Jon Harrop would tell that.  That's why you're seeing today
> C and C++ beating OCaml real hard.  Because just a while ago -- when OpenCL,
> OpenMP and other easily-parallelizing toolkits for C/C++ compilers weren't
> generally available -- OCaml programs usually sported similar performance to
> C/C++ and were also much clearer and shorter.
> 
> Eventually, it should get up to date.

I haven't checked yet, but I'm fairly sure the Shootout still has 
benchmarks for older, single-core systems. If I check that it should be 
informative.

>> 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.
> 
> yeah, but it's probably a very difficult issue.

Well, as difficult as it is for any language, yes.

>> 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?
> 
> No, it's not trivial (oh such common word) at all.

In exactly which way is it not trivial to determine that an identifier 
appears in the LHS expression?

> Which is also why you don't
> have many compilers for Haskell, but you get quite a good lot of good performant
> compilers for both ML (Jersey ML, MLton, OCaml) and Scheme (Bigloo, Chez,
> Gambit, Stalin etc).

Right. And but because nobody knows Haskell exists yet?

(Besides, there are half a dozen compilers out there. It's just that 
there's only one that's production-ready. Apparently there used to be more.)

> I don't like all the semicolons either.  And the +. *. operators for
> floats/doubles, but hey, at least these help on performance.

So does [or should] statically-known types. If you statically know that 
you're adding floats, replace + with +. and you're golden. It's not 
rocket science. (Actually it's program optimisation...)

It seems several design choices in Ocaml are specifically about making 
one special case faster at the expense of complexity and ugliness. Which 
is fine, I suppose, if you're just trying to win benchmarks rather than 
write maintainable software...

>> 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.
> 
> Being used to Pascal as well as C, I don't see the issue here.  It's just a
> different way to state something:  "a set of integers" or "an integers set".

It's valid I guess, but I'm still curious to see what happens when you 
have multiple parameters...

>> 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".)
> 
> It was not a mistake before Unicode showed up, it was common-sense, specially in
> a performance-conscious programming environment.

I'll admit that not that many people use Unicode. Still, I imagine it 
means that if you try to adapt your program to work properly with 
Unicode, it breaks all over the place in unexpected ways.

> I don't know enough of OCaml to say this with 100% certainty, but I'd say it's a
> design choice geared at, again, performance.  Just like C++ got plain structs
> against the more heavyweight classes.

...except that C++ structs *are* classes. ;-)

Still, at least they didn't do that horrid C++ thing where you have to 
manually specify which methods you can override later.

>> 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.
> 
> Why would you write (*) 2 3 in OCaml when you can simple 2*3 or 2*.3?  (or even
> in Haskell, except to make it look like Lisp ;)

You wouldn't. But if you want to pass "*" to a high-order function...

> (* this comes from Pascal and BTW,
>  it spans several lines, which -- doesn't *)
> 
> Do you know what the Haskell multiline comment marker looks like?  I'll wait for
> the answer.

It's {- ... -}, which is vaguely more logical.

>> In Haskell, if I want to compile a multi-module program, I say
>>
>>    ghc --make MyThing
> 
> oh, you didn't get the fun times when GHC would compile down to C files and then
> you ran the whole C-stack build process on your own, did you?  You missed half
> the fun, my friend...

Current versions of GHC default to using the native code generator 
rather than GCC anyway. ;-)

>> 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.)
> 
> OCaml development is not as large or hip as Haskell's, so they have to make use
> of whatever is ready for them, which means things like make.

In which universe is Haskell "hip"? o_O

Well anyway, I thought Ocaml was far better known than Haskell, but I 
guess I could be wrong on that. It's just frastrating that they've 
designed the system in such a way that even if you were prepaired to 
write the code, it's not easy to automate.

> That's why a Makefile is so useful. ;)

Sure. But make doesn't determine dependancies; you have to do this 
manually. And if you get it wrong, your program presumably just doesn't 
link, or crashes when run. Kind of negates all the correctness benefits 
of functional programming...

>> 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.
> 
> Good for Haskell that its large developers have recreated make inside it, but
> not everyone can afford that.

I repeat, make does not determine dependencies, it just decides what to 
do based on them. (Which is admittedly non-trivial in itself.) As far as 
I'm aware, there is no tool that writes makefiles for you. So GHC does 
far, far more than make. (In fact, there's an option to have it write a 
makefile for you, if you wish for some reason...)

>> 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).
> 
> It can, because source files are compiled into native object code.

Doesn't necessarily mean you can link to it from the outside. (I'm not 
debating that you can, I'm just saying your explanation is incomplete.)

>> 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.)
> 
> yes, pragmatism was the main force behind OCaml.

Presumably native object code from Ocaml must also contain the Ocaml 
runtime system too. (Including the GC, at least...)

Being pragmatic is fine - isn't that what made C so popular in spite of 
being rubbish? But it seems to be that there are a lot of poor design 
choices here that don't enhance performance in any way, they just make 
programming harder. Which is somewhat dissapointing.

I'm not saying Ocaml is completely rubbish. It does seem to have a small 
few interesting ideas in it. (The tutorial I read doesn't really explore 
these very much...) I just hope I never have to actually use it. :-}

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message