evan_tech -- utility of ocaml

10:43 am, 3 Jul 05

utility of ocaml

Now that I feel truly competent in O'Caml -- read a bunch of docs, written a bunch of programs, even contributed some code back the community -- I find that I'm not using it, and I've been puzzling over why.

It fills a weird niche.
It's much faster than a "scripting" language, much more fun to write than C++, but the cases where I've needed this sort of speed I've also needed the lower-level memory control of C++. (I refer you back to my entries about processing Wikipedia data, where I was streaming through large amounts of text and found my code spending most of its time in the GC. [I ought to fix this into a link.])

This isn't to say that it isn't a niche that's useful -- see, for example, this fellow who appears to be implementing Katamari Damacy -- but just one that I haven't needed. (There seems to be a trend with OpenGL, probably because language speed attracts game developers.)
The important derived question from the above is: is it more fun to write than a scripting language?

And there, the answer is yes and no. In terms of concrete syntax and the way you express things, I think O'Caml's got the edge. Being able to write code without type annotations but retaining static typing is really a killer feature (coincidentally, the whole language is designed around it) for writing stable programs and iterating quickly.

But there's an important caveat: the standard (and supporting) libraries are crap. There still isn't an obvious way for me to be able to make an HTTP request somewhere from within O'Caml. And I've read over and over about why standard libraries are one of the defining aspects of a language -- it's described as one of the distinguishing features of Python, which has a killer standard library -- but it hadn't sunk in as much because all of the languages I typically use have good standard libraries already. I read a comment somewhere to the effect of, "I don't program in Perl; I program in CPAN and use whatever language that requires."

Even the C++ I write at work has a large standard library (see Joe Beda's post about Google's code organization), and it's been so long since I used C++ regularly I had forgotten it's not normally there. I've been writing something lately in C++ and I keep running into this: "OK, now I need to parse HTML. I'll just use... aw crap, I don't have that." But at least with C++ I can download libxml and use its HTMLparser. With O'Caml, I have to write the bindings myself.

This sort of complaint (that O'Caml's developers don't take the broader language issues seriously, and instead focus on the lower-level bits) is regularly seen on the O'Caml lists. The developers respond by saying that the language is academic so that's basically the breaks. It's a startling contrast to the Haskell community, which is similarly academic, but where most major user-contributed projects are hosted by haskell.org and the developers are actively integrated into designing and implementing their own CPAN-like system, while simultaneously being aware of the needs of e.g. Debian-packaging requirements.

That last comment about Haskell is too bad, really: I think of Haskell as O'Caml with all the practicality removed, so if either of the languages needed a good standard library it'd be O'Caml.

xaosenkosmos

Richard Jones bounces from random thing to random thing, like most OCaml people. I don't know if the Katamari Damacy thing will pan out or just remain a rather standard demo program. At least the most recent release fixes the "You can get yourself stuck" bug.

As for the "them's the breaks" attitude: how is the Haskell core team distributed? It seems like all the OCaml maintainers are at INRIA, or at least .fr, and they definitely seem to form an insular little community. They probably don't really see any need for outside input, since it fills all their needs.

reply to this

jarodrussell	There still isn't an obvious way for me to be able to make an HTTP request somewhere from within O'Caml. That's the problem with LISP -- Common Lisp, SBCL, Scheme, etc. -- too. Looking at poking at LISP over the last year, there's no standard library to build upon.
reply to this

Anonymous	The available ocaml libraries are quite ok. Check http://www.ocaml-programming.de/programming/netclient.html Ocaml lib database: http://www.npc.de/ocaml/linkdb/ Cheers, Dirk
reply to this

gaal

I don't get the last remark? When you compare the two what are you missing from Haskell except for objects?

In terms of practicality, (ObPerl6Plug...) p6 is going to be insanely fun. For starters, you can use Perl5 from it today. Its OO caps are going to be clean AND hackable. It has closures all over. A keyword for currying. Optional laziness. Built in Unicode (except when you don't want it). Everything is an object (unless you want unboxed stuff). You should see its switch syntax. MMD. Inshaallah, useful threads and STM (inherited from Haskell). Introspection like a drunk Romantic poet. Did I mention libraries? Hooky stuff like function wrapping in the language. A well-defined compilation process with possibly several backends to choose from. "And so on".

The disappointments: it's probably not going to as fast as O'Caml. But it'll have a totally kick-ass NCI, no doubt about it. And sorry, no type inference either. "awk's gotta be better for something" :-)

reply to this

theorb	Who said we don't have type inference? The compiler is allowed to do type inference, but it isn't required that it do so; it's considered an optional optimization. OTOH, like many other optimizations, type inferencing is /hard/ in the absense of explicit hints.
reply to this

gaal	I think Evan's seeing type inference as a first-class language feature: you don't specify types explicitly, but the compiler figures out what they must be. This is very very different from ol' Perlish coding which just coerces things until they do... something.
reply to this

evan	To add to Gaal's comment, the real utility of type inference is not the optimization benefit but the compile-time checking benefit. The optimization is just a side effect of static typing in general.
reply to this

Anonymous

reply to this
- gaal You don't (naturally) have mutable fields, so the analogy with OOP only goes so far.
  
  reply to this
- evan it's just a poor (slash meaningful in a deep way) name choice. they have nothing to do with OO classes, and instead used for bounded polymorphism.
  
  reply to this

xaosenkosmos	I don't get the last remark? When you compare the two what are you missing from Haskell except for objects? The fact that strings are implemented as char lists leaps to mind...
reply to this

gaal	That buys you laziness, which is useful sometimes. (`getContents fromHandle >>= hPutStr toHandle` copies a file efficiently, for example.) But sure, this isn't Perl. How do strings work in OCaml?
reply to this

evan

They're sorta C++-like. They're their own type -- they're not even an O'Caml-level char array, despite O'Caml arrays having all the right semantics (like bounds checking, etc.). I think this is for type inference reasons (the subscript operation on strings is different syntax than arrays, so you always know when you're subscripting a string), and also because they do some more speed hacks underneath: at the implementation level, O'Caml strings have the length information in the bytes *before* the pointer, and are always guaranteed to have a NUL after the end, so language bindings can pass an O'Caml string directly to an underlying C function expecting a char* without needing to do any wrapping or offsetting whatsoever (as long as you don't care about embedded NULs, in which case the C API will be different, too).

reply to this

evan Yeah, but the syntax is soooo ugly. :P

reply to this

gaal	You don't (naturally) have mutable fields, so the analogy with OOP only goes so far.
reply to this

evan	it's just a poor (slash meaningful in a deep way) name choice. they have nothing to do with OO classes, and instead used for bounded polymorphism.
reply to this