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.
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
But didn't have a project on hand to try coding in Ocaml with. To be honest I found it hard to kick my brain into the rather different gear that OCaml requires (though I have done a little Lisp programming, I haven't had too much experience in real functional languages). Without an example to work on yourself, and understand quite how to structure things I think it can be hard going. I just didn't have the time to commit properly, unfortunately. What I did see of the language was truly impressive, and this book certainly sounds like an excellent resource. Maybe it's time to go back and try again.
Jedidiah.
Craft Beer Programming T-shirts
One way is to find a niche and just nail it. Be the best thing out there for it. PHP did that, and if they play their cards right, they could grow out of that niche too, surpassing things like Python in popularity, even if PHP isn't that beautiful a language.
To really understand this problem, you are going to have to read *gasp* marketing and economics books. "Crossing the Chasm" and "Information Rules" (network effects, lock-in, and so on) are ones I find interesting. I've heard "the innovator's dilemma" is good too, but haven't read it yet.
http://www.welton.it/davidw/
Considering that the C++ code would have nasty solutions for peak speed- prettier, straightforward solutions for C++ tend to be 2-4x slower than the optimal solutions for C++. The same could be said for C code as well.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I looked everywhere. None are intuitive and easy like the java.sun.com tutorial.
I downloaded the compiler about a year ago but got turned off by the quality of tutorials.
You need easier reading material if you want people to adopt.
The performance difference between C and OCaml depends heavily on the application. I have written a relatively small application in OCaml (an interpreter for the programming language Joy) and the optimized OCaml version was faster than its C counterpart. (The C version, not programmed by myself, is about 6x larger and still slower) There are examples where OCaml is significantly slower, but I think, that you would rarely see a 2X slowdown when programming carefully. On the other hand the development time can be significantly reduced: programming in OCaml is normally about 2-5 times faster than in C++ if one takes the reduced time for debugging into account. And this is true for ma altough I have more than 8 years (and over 100 KLOC) C++ experience while less than one year OCaml experience. One can also add that the object system of OCaml is much more powerful than that of C++. It allows for much more genericness while having a thourough type-safety. You can not achieve the same genericness in C++, since you can add everywhere explicit type delaration (resulting in long and complicated template names) where OCaml can deduce the type information automatically. This makes code-refactorization much more easy. It is not true that OCaml needs a different type of thinking than a procedural or object-oriented language. OCaml has full support for "traditional" programming style and in fact most OCaml programs are written that way. Haskell and Clean are more elegant, but they really require that the programmer uses a purely functional programming style without mutable states.
We saw from the examples that the typing in C and Pascal failed for several reasons. It was too fine-grained, as in Pascal's useless distinction between an array of twelve characters and an array of thirteen characters. It led to many spurious error messages, which means warnings that are ignored and waste everyone's time. It was too easy to violate the type systems though union types and casts, and it had to be so, because of the preponderance of spurious errors.
Can't we give this one a rest? Has anyone run into s:array[1..20] of char being incompatible with s:='Foo'; since the 1970s?
I feel like I get slightly stupider out of empathy every time I read about that.
Other posters have already sent some great replies but just in case their explainations don't mean much to you considering that you don't seem to be familiar with Caml here's a simpler answer.
You're comparing apples and oranges. Eiffel is an object oriented imperative language. Ocaml is an impure (as in has some imperative features) functional language with some object oriented constructs which are largely unnecessary as anything that can be done with objects can be done with functors and Ocaml types more naturally in functional programming style.
Many things that are considered good OOP practises (such as hiding state for example) come naturally to functional languages (assignment is not allowed so there is no need to hide state as you can't change it - sounds limiting but that's only because you're used to imperative programming. Functional programming languages are in fact far more expressive).
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.
The point being not that one should write all code in ocaml, but in some cases its useful to know some of these techniques such as meta-programming, symbolic computation etc.
I know how to do metaprogramming and symbolic computation. But a language that forces me to use such techniques just to compensate for the lack of an efficient way of abstracting numerical data types is defective.
FFTW runtime is in C, but the C code is generated by a program written in Ocaml.
It's not about FFT. It's about the lack of an efficient way of abstracting complex numbers, small vectors, intervals, derivatives, and other common compound numericla datatypes in OCAML.
I learnt ocaml for one main reason, it helps to learn a new style/paradigm for programming.
OCAML is a great educational tool, as are Haskell, and lots of other languages. But as an efficient, general-purpose programming language, it's a failure. That's regrettable, because it is nice in so many ways. But a language can't be general purpose unless it also supports reasonably efficient, high-level numerical abstractions. The only commonly used languages that currently do are C++ and C#.
Why do you need to do FFT with the compiled code?
Complex FFT is just an example. It's an algorithm everybody knows and understands. It involves complex numbers and arrays. There are lots of other examples, from graphics, statistics, UIs, etc.
If you are doing applications that require a lot of FFT, then would you not get a co-prcessor to do this of the kind that Texas Instruments produces?
Even if it was specifically about FFT, you wouldn't: general purpose processors are fast enough. And coprocessors are completely unsuitable for other kinds of numerical and semi-numerical code. They are also a pain to program.
Even if you use a language like C++ that does not mean that the algorithms that are used or the way that data is jockied about in memory has effciency and gives you fast output.
C++ does this a lot better than OCAML.
There are many things to consider besides just a choice of languages.
There are lots of things that need to fall into place in order to get good performance. One thing is that the language needs to have the right primitives. Since OCAML lacks the right primitives, you are guaranteed that pure OCAML code won't be doing well on this type of code.