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.
Possibly the most widely used app written in Objective Caml -- MLDonkey
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
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
_
.--' | .--. /` '. /\| /'----`\ /
//_( //_(
/___^ |
) | / \
/ |
| '-' / \
\ | |\
\ / \
\
||| \\ |
((| ((|
||| |||
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.
Isn't saying, "OCaml also has full support for object-oriented programming that fits in completely with OCaml's strong type system." equivalent to saying, "Ford Thunderbird also has full support for all fuels that meet its fuel requirements."?
"This signature quote intentionally left blank"
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/
I think FFTW would be the most famous and useful if not the most popular.
At first read I thought it said "Developing Applications With Objective Calm" -- which, come to think of it, would probably make for a pretty interesting article.
Does this count the same as anyone from GNAA?
Or because it's CAML, will it be allowed? Please tell me what to flame!
In Korea, only old people use scripted languages.
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.
This was my opinion at first. My first OCaml program (a simple fractal computation algorithm) was about 20 lines long and it took me a whole afternoon and it was no fun at all. After I got used to that syntax I learned to like it, and now I really prefer to almost any other languagues (expect for Ruby). I always prefered it over LISP, since the lot of parenthesis makes it too uniform and therfore hard to read.
My first o'caml script:
o
oooo o
ooooo o oooo
o o o o
o o oo oo
o ooo o o
o o oo
o o o ooo
o oooooooo o
ooo oo o
ooo ooo
ooo ooo
oooo oooo
Lameness filter encountered.
Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted.
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.
God is slashdots compression filter is retarded..
sik0fewl Preferences Subscribe Journal Logout Sections ain ApacheApple AskSlashdot 1 more Books BSD 2 more evelopers 1 more Games 11 more Interviews IT 4 ore Linux 1 more Politics Science 3 more YRO 2 ore Help FAQ Bugs Stories Old Stories Old Polls opics Hall of Fame Submit Story About Supporters ode Awards Services Broadband PriceGrabber ProductGuide Special Offers Tech Jobs IT Research
I remember when legal used to mean lawful, now it means some kind of loophole. - Leo Kessler
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.
If I am fluent in C++ (powerful), Java (run anywhere) and Ruby (scripting), what advantage does this new language have over those? What problems will this new language solve? If it's one of those above, how is this one better than the language I'm already using? I'm all for learning a new language for fun, but for work I'd better have a good reason for putting out the effort.
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
Here is a beautiful derivative of prolog in desparate need of an o'reilly treatment.
http://merjis.com/developers/ocaml_tutorial/
If you add to the list of features the ability to compile to C source and the support for multiple inheritance then you get Eiffel. The lack of strongly typed extensive base library seems to a problem with Eiffel too.
O'Caml is a more advanced language than Eiffel in most respects. It has multiple inheritance too, BTW. Features O'Caml has that Eiffel doesn't:
* Type inference
* Higher order functions
* More powerful type definition (e.g. tagged unions).
* Syntax/semantics generally much more suited to functional programming, which is pretty much impossible in Eiffel.
* More concise.
OK, Eiffel has design-by-contract, but that only adds additional safety, not power.
Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
Lots of CS majors don't cope well with functional programming paradigms. In the old days (and at many tier 1 CS universities) Lisp or Scheme are still taught as introductory languages, which helps some.
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.
I'm not sure how you could refute the official objective caml license, which clearly states that runtime system and standard libraries are licensed under LGPL (to allow linking with commercial programs), and the compiler and tools are licensed under QPL, which allow you to distribute unmodified code as is, or your modification "in a form that is separate from the Software."
The example given in QPL is using patches, but I don't see why you can't fork the source, since it would still be "separate" (just don't call it Objective CAML, but something else). QPL does not say your modification has to be in the form of patches.
I once had a signature.
I initally used thebook as a resource for learning Ocaml. My review would be more like:
Language Core
This covers the basics of the language, although the presentation of material is somewhat disjointed, which makes the book challenging to use as a reference in the first programming steps.
The book is clearly a translation, and in some areas the translation is not especially literate, although the meaning of the text is always pretty clear.
The worst problem with the book is that it is severely out of date with respect to the latest distribution of Ocaml. The aspect that had me tearing my hair out was the lack of coverage of open types - something which is essential to using a GUI toolkit, and which is somewhat complex as there are rules which may come as slightly odd to those used to the implementation of polymorphism in other languages.
Development tools
This section gives a good overview of many of the tools available, and is probably the best part of the book. The major ommission is Ocamlp4, which, again, post-dates the book's authorship. Users on Windows (bow your heads in shame... this is Slashdot) will find that their platform is not really covered, which is a shame, as there are a few differences from Windows.
The rest
Coverage of libraries is way out of date. For a modern user, the only serious GUI choice is LablGtk2, and it is not covered at all. There are other problems in a similar vein.
The book contains a number of extended examples. While these smack of being 'undergraduate projects', they do indicate some of the techniques and paradigms of programming in Ocaml.
ConclusionI wouldn't recommend this book. It's too far out of date (imagine buying a book on Perl 4 or Python 1.5). Since the Ocaml manuals are quite comprehensive, and there's an excellent tutorial at merjis.com, which is fast paced and does cover modern language features, there's really no need for this without a significant update. Sorry.
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.
I'm not sure I agree with the conclusion that OCaml (like Java) is defective due to deficiencies in handling of numeric types
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.