Slashdot Mirror
Developing Applications With Objective Caml
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.
Why just last week I was developing applications with an Opinionated Camel, and it was hell.
Hell, I tell ya.
If you don't know what AltaVista is (was), get off my lawn.
Yes, I've been intrigued by OCaml for a long time.
OCaml's major problem is that, like every other functional language available today, the breadth of its standard library and third-party libraries is totally pathetic in comparison to the likes of Java and Python. The same limitation applies to Lisp, Scheme, Haskell, Erlang, etc.
These languages face a Catch-22: until they're more popular, they won't attract enough developers to ameliorate the library situation, yet until they offer better libraries, they won't attract developers. Historically, this barrier has been surmounted in one of two ways: either a deep-pocketed corporation subsidizes library development until the language gains momentum (see Java, C#) or the languages are sufficiently "charming"/"hip" that the library support appears as a result of a grass-roots effort (see Perl, Python).
Is there any realistic prospect that one of the functional languages I mentioned will strike it rich in either of those ways? It doesn't seem likely to me.
Erlang.org: wow
_
.--' | .--. /` '. /\| /'----`\ /
//_( //_(
/___^ |
) | / \
/ |
| '-' / \
\ | |\
\ / \
\
||| \\ |
((| ((|
||| |||
Important Stuff
# Please try to keep posts on topic.
# Try to reply to other people's comments instead of starting new threads.
# Read other people's messages before posting your own to avoid simply duplicating what has already been said.
# Use a clear subject that describes what your message is about.
# Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
Problems regarding accounts or comment posting should be sent to CowboyNeal.
:D
OCaml code can rival C++ code in benchmarks...if you write OCaml that looks like C++. Yes, the OCaml code is still probably safer in the end, but the OCaml solutions to many of the benchmarks are just nasty. The prettier, straightforward solution is often 2-4x slower than the C++ version. So is OCaml fast? Yes. But please be careful here.
I've also written an OCaml tutorial for people coming from 'conventional' languages like C, Perl and Java.
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
1) What do you consider "about as efficiently?" A ten-second search turns up an FFT benchmark written by Xavier Leroy; he reports that it runs about 2/3 as fast as C code.
That code doesn't use a complex datatype--it uses real arrays and writes out the complex number operations. The FFT example was not to get an FFT, it was to illustrate a point about what operations a language can and cannot support.
2) What the hell kind of "modern general-purpose application" needs to compute FFTs quickly? That's a highly specialized application.
FFT itself is needed by lots of applications: financial software, image processing software, speech recognition software, speech synthesis software, etc. But it isn't about FFT in particular or complex numbers in particular: you encounter analogous problems with datatypes appearing in graphics, reliable numerical computing, graph algorithms, language processing, statistics, and lots of other areas.
3) If certain algorithms cannot be computed quickly in OCaml, just write them in C. Bindings to C functions are trivial to write. You want to do FFTs? It's already been done.
You just don't get it, do you? Numerical, semi-numerical, statistical, scientific, graphics, and visualization code is moving into applications and the people who are writing want better tools for writing it than using C or even C++. We are f*cking tired of being told by ivory-tower compiler writers that we should just write our code in C just so that they don't have to get their hands dirty. I have "just linked in" C code for 20 years: it's a lot of work, it's difficult to package, and it erases all the runtime safety that writing in OCAML should give you. It's time that language designers with aspirations for designing general purpose languages get a clue.
Languages like OCAML and Java are defective as general purpose languages because they don't support efficient data abstraction for numerical types. The fact that their designers just don't get that fact is a testament to the ignorance of their designers. It's also what people really mean when they say that those kinds of languages are "just not efficient as C/C++": it means that in C/C++, you can get whatever code you write to run fast, while in OCAML or Java, there are always problems where you have to drop down to C.