Objective Caml
As I mentioned previously, I’ve been spending a great deal of time with Objective Caml (OCaml) recently.
Why do I like it?
- Interactive use (like Lisp, Perl, & Python) via the bytecode interpreter (ocaml).
- Compilable to assembly language for a variety of processors (including recent support for Amd64) via the optimizing compiler (ocamlopt).
- Type Inferencing provides the type safety of a language that requires a type definition for each variable (like C#, C++, Pascal, etc.) without (usually) having to declare them manually. So you get the conciseness of languages like Python or PHP without the worries of possible type errors at runtime.
- Pattern Matching is like a case statement with nitrous and supercharger bolted on. See the tutorial below for examples of the neat things you can do with it.
What don’t I like?
- OCaml is so strict about type safety & so focused on performance that there are separate operators for integers and floating point numbers. While I understand the motivation, in practice it really does get in the way when working with numbers (although usually not for other types).
- Getting the command line tools to work correctly for complicated builds (at least under Windows) can be painful.
- There are many fewer libraries available for OCaml than for Python, Perl, or .NET. (However, there is good support for OpenGL under OCaml. Check out LablGL).
Learning OCaml, for C, C , Perl and Java programmers is a great tutorial to get started with. The most pleasant way I’ve found to use OCaml interactively is under emacs with the Tuareg mode. It does very nice syntax coloring and allows the sending of expressions from the editor to the OCaml toplevel one phrase at a time, which is great for interactive development.
September 30th, 2004 at 9:10 am
I liked OCaml until I got more into the ‘O’ part, seeing how they handled FP vs. OO, where you start having things like parameterized classes and other things to handle OO-style polymorphism while still keeping the type system happy. I switched to Common Lisp where I just use multimethods, plus the macro system is much simpler than camlp4.
October 4th, 2004 at 9:30 pm
I’ve spent a lot of time with Scheme, so as it turns out I tried pretty hard to get a Lisp (Corman Lisp) working for me for interactive OpenGL development. Unfortunately I wasn’t able to get OpenGL/Glut to work with threads in Corman without crashing and in the end I was able to get it working with the bytecode interpreter in OCaml with LablGl.
I do miss the freewheeling nature of runtime type checking with Lisp, especially for prototyping (but my code also seems to have fewer bugs with OCaml, so I suppose it’s a tradeoff). I’ll probably get a Scheme up & running in OCaml at some point to get some of those advantages back, but the problem then will be getting enough primitives up and running to make it worthwhile to prototype anything (that is one thing I miss about .NET—while reflection is slow, it does eliminate the need for a Foreign Function Interface).
I’ve only done really basic things with the OCaml object system so far, but other than the need to manually downcast objects and the poor error reporting for syntax problems for class definitions, I’ve been fairly happy with it.
I’ve never used multimethods, but Mike Vanier had a similar falling out with OCaml over the object system & lack of multimethods support .
The Oreilly OCaml book has an interesting comment about the object system as well:
“There is no class hierarchy in the language distribution. In fact the collection of libraries are supplied in the form of simple or parameterized modules. This demonstrates that the object extension of the language is still stabilizing, and makes little case for its extensive use.”
I haven’t tackled camlp4 yet. I go back and forth on macros. On one hand they are indisputably powerful. On the other hand, having a malleable syntax can be quite confusing. In any case, macros are great for implementing Domain Specific Languages—Shriram Krishnamurthi’s automata example in his The Swine Before Perl presentation is pretty compelling.
January 22nd, 2005 at 12:58 pm
OCAML’s use of distinct operators for floating and integer arithmentic doesn’t have to be a requirement of the strict type system. SML manages just fine with overloading + for both.
January 5th, 2006 at 11:22 am
I’d like to know what you think of the freely available first chapter of my book Objective Caml for Scientists.
Regarding Reilly Hayes’s last comment, using ad-hoc polymorphism to overload the “+” operator, as SML does, is clearly a trade-off, with SML requiring a slight extension to the type system, giving slightly more obfuscated error messages and even introducing discrepancies between the types inferred by different compilers.
You could implement a numeric tower for OCaml using camlp4 but this would give worse performance, complicate interfacing (including with the stdlib) and would only work on a per-source-file basis.