Developing Applications With Objective Caml 243
| Developing Applications With Objective Caml | |
| author | Emmanuel Challoux, Pascal Manoury, and Bruno Pagano |
| pages | 742 |
| publisher | O'Reilly France |
| rating | 8/10 |
| reviewer | William D. Neumann |
| ISBN | 2841771210 |
| summary | A comprehensive book on Objective Caml, covering not only the core language, but also modules, objects and classes, threads and systems programming, and interoperability with C. |
The Book
The book itself is quite comprehensive, clocking in at over 700 pages and covering material ranging from an introduction to the language to concurrent and distributed programming. To organize all of this material, the book is broken into four main sections that build upon each other. Each section has a set of chapters that present some related concepts, followed by an "Applications" chapter that uses those concepts to create a few small applications such as a minesweeper game, a graphical interface library, a couple of different two-player games, a distributed robot simulation, and a basic HTTP servlet. These four sections are as follows:
I. Language Core
This section serves primarily as an introduction to the OCaml language, with chapters on the functional core and imperative aspects of the language, a chapter on the differences between the two styles that shows how the two can be melded, and a chapter on the OCaml Graphics module. The introduction to OCaml is complete enough that anyone with a background in programming should be able to achieve a good understanding of the basics of the language. Especially when combined with other freely available resources, like Jason Hickey's Introduction to Objective Caml , and Richard Jones' Learning OCaml for C, C++, Perl and Java programmers, one should be able to obtain a strong OCaml foundation to use while reading the rest of this book.
II. Development Tools
The second section covers, as the title states, the OCaml development tools. The chapters in this section provide information on the OCaml compilers, interpreter, and interactive toplevel environment; some of the libraries included with the standard distribution; OCaml's garbage collection mechanism; Ocaml's debugging and profiling tools; OCaml's versions of lex and yacc; and interfacing OCaml with C. This is perhaps the most valuable section of the book, as it provides good coverage of some important topics that are covered a bit too briefly in the OCaml manual.
III. Application Structure
This section covers the OCaml Module system, and its interface and functor (parameterized module) facilities. Also included in this section is a well written chapter on object oriented programming in OCaml, and a chapter comparing the two models of program organization, offering a brief look at how the two systems can be combined to reap the benefits of both.
IV. Concurrency and Distribution
The final section covers the topics that many folks might consider to be the "real world" programming topics: File I/O, process management and communication, concurrent programming using threads, and distributed programming. The coverage in this section is, again, well done, but perhaps a bit light, and it would have been nice to see more time spent on this subject matter. However, the book is already quite hefty, and the services provided by OCaml's Unix module should look familiar enough to most programmers that the material that is presented should be sufficient to get a competent programmer up and running.
The Upshot
For the most part, Developing Applications With Objective Caml does a very good job at presenting the OCaml language in more of a "practical" light than other books on languages in the ML family (and functional languages in general). And while the applications that are constructed throughout this book aren't anything particularly great or interesting in and of themselves (a simple BASIC interpreter, a rudimentary database, a client-server toolbox, etc.), they aren't the primary purpose of the book. What the applications are used for is to illustrate how the concepts presented earlier in the book are used in within the framework of an application, and not just as isolated examples. This is especially important, as most people who might read the book will be unfamiliar not just with Objective Caml, but with the entire functional programming paradigm. Repeated exposure to working OCaml code helps to familiarize the reader with functional programming and OCaml idioms while reinforcing the book's material.There are, of course, some problems with the book. For one thing, Developing Applications is nearly five years old, half a lifetime when dealing with most computer related topics. This issue is first brought to light in the introduction where it's mentioned that chapter one tells how to install version 2.04 (OCaml is currently at version 3.08), and then in chapter one, when the reader is warned that, "Objective Caml only works under recent versions of Windows : Windows 95, 98 and NT." Fortunately, the information presented about the language remains valid (and Appendix B presents some of the features added to the language by version 3.04, the release that was current at the time of the translation). There are also a few spots where the code in the book contains minor errors, but both of these issues can easily be overcome with the help of the resources listed earlier in this review, or with the help of the OCaml community. Other minor issues crop up as a result of the translation, with the occasional odd sounding phrase popping up in the text and examples. These problems are, however, few and far between and do little to detract from the material or the presentation. And so this book still remains one of the best resources for learning Objective Caml. I used it when I was learning the language, and I still turn to it from time to time as a useful resource.
Will the book turn you into an OCaml guru, or teach you all sorts of advanced type system trickery? No, of course not. But it can teach you enough about the language to start you writing real apps in it. And it will allow you to add a fast, flexible, and powerful language to your toolbox.
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:Intrigued? (Score:5, Interesting)
I totally agree with your comments about the need for a standard library. But, as you observe yourself, such things can be developed by the community: CPAN for Perl, CTAN for TeX, and Boost for C++ are all very high quality libraries that are pretty much entirely community-developed.
I think the most obvious missing thing is a figurehead for functional programming. A fair few of programming language geeks seem to be fans, but as someone posted here once before (sorry, can't remember who), functional programming has yet to find its Larry Wall. I'd like to think that the first time someone steps up and takes on that role, that will get the geeks going, and the snowball will start to form. All we need is someone qualified who wants to put in the effort, but of course there are going to be very few such people around in a relatively small corner of the programming world -- catch 22, indeed.
Careful about speed comparisons (Score:5, Interesting)
Huh. (Score:2, Interesting)
Re:Intrigued? (Score:5, Interesting)
On that front, it will be interesting to see what will happen in Parrot [parrotcode.org] successfully manages its dream of uniting (amongst others) Perl, Python and Ruby - allowing a module from one language to be used in another. Surely that confluence of communities could build a very formidable library indeed...
Jedidiah.
Re:Full Support? (Score:1, Interesting)
The funny thing is, the OO system of ocaml actually doesn't really fit into the type system that well. Methods can't be polymorphic (i.e. they have to take real types, not 'a). Meanwhile, functions can be polymorphic, but can't be overloaded. Try to get too abstract with polymorphism and covariance, and you get monomorphism restrictions coming around and biting you. Let's not even get into how painful it is to represent something as simple as an "unsigned 32 bit int" (kinda useful when doing network programming) in ocaml. And yes, the same could be said for Java, and I say it loudly and often.
That said, Ocaml's easier to learn than Haskell: objects are easier to deal with than existential types, there's no monads, and you get variables that act more or less like you'd expect. Unfortunately, the core language hasn't seen any significant updates, and even camlp4 hacks are sort of petering out. I'd hate to see Ocaml fizzle out, but I don't know that slashdot articles are going to save it from the apparent neglect by its core developers.
Re:Intrigued? (Score:3, Interesting)
(Common) Lisp lacks only a non-proprietary and useful GUI toolkit. Otherwise it has just about everything. The fact that POSIX interoperability doesn't appear standardized is annoying, but the most annoying thing is that the good Lisp environments cost $$$$. I envy Lisp developers from a distance have never had the balls to really become one myself. It does take balls, too, to say to a group of Java-nerds or C++-nerds that something can be done better, faster, and with fewer problems.
Re:I'd consider OCAML (Score:2, Interesting)
Things I want to know about a new language: (Score:2, Interesting)
Re:manual (Score:3, Interesting)
Functional languages are very intuitive to math majors, and people who study abstract computer science (which is essentially discrete math). Concepts like currying, recursion, and the like make a lot of sense if you're used to the way mathematicians think.
I don't know Ocaml, but I do program in Haskell. I remember looking at the language as a freshman and finding it very confusing. By the time I'd taken graduate level math classes though, and was comfortable with functors and morphisms, lambda calculus and Haskell were not only a piece of cake, but incredibly intuitive.
Note that this way of thinking is (at least in my opinion) no more "intuitive" than procedural programming paradigms. It just depends on your background. I had some classmates that never groked programming until they were introduced to ML or Prolog.
Re:Careful about speed comparisons (Score:4, Interesting)
Well, not quite. In C you pay as you go. You essentially have a direct mapping to common hardware. You can go faster, yes, but the improvement generally isn't worth it unless you're targeting specific weirdness like MMX or SSE2.
OCaml has some significant overhead that comes from the language definition. There's garbage collection, which while fast is certainly not free. Floating point values in mixed-type tuples are heap allocated (that is, the floating point values--doubles, actually--are separate heap objects). There's the classic issue with functional languages that the simple and easy way to build a list either involves stack space for each element or a full reversal of the list (not in place) at the end.
I fully agree with you that readability is worth a hit in performance. I use interpreted languages all the time, and compiled OCaml is certainly much faster than them. But OCaml advocates need to be careful about claiming their language is as fast as C/C++, because it generally isn't true. It's only true if you drop the nice features and write grungy C-style code, and then only in certain situations. This does not mean it is a bad language, however.
Re:Intrigued? (Score:2, Interesting)
Re:No good tutorial about ocaml... (Score:3, Interesting)
Re:great language, but not quite general purpose (Score:3, Interesting)
Don't get me wrong: I think OCAML is a great language for specific application domains (theorem provers, compiler writing, etc.), and Java has become a decent language for traditional server-side applications. But in order to become general purpose languages, languages that people can use instead of C/C++ without reservation, I think they must get better numerical support.
Better numerical support does not mean that those languages have to get implementations that can beat optimized Fortran. It also does not just mean that it is possible, in principle, to write fast numeric code (you can write fast numeric code in Java and OCAML if you really have to--it just is a lot of work). It means that people can write decently clean, maintainable numerical code without having to make much of an effort.
The thing that is frustrating is that language designers keep underestimating the importance of good support for that kind of programming, and one promising language after another dies because of of that misjudgement.
In the case of Java, people now have an alternative: C# is basically Java with those missing pieces added. There are lots of political issues surrounding the two languages, but if it just came down to technology, it would be a no brainer to figure out which one would win in the market. And I think functional programming languages won't make it big time until one of them adds analogous functionality.