Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews Technology

Developing Applications With Objective Caml 243

Posted by timothy from the watering-hole dept.
Fahrenheit 450 (William D. Neumann) writes "Developing Applications With Objective Caml was originally published in French by O'Reilly, and later translated into English by a group of volunteers (note that the reviewer was a volunteer proofreader during the translation effort), and graciously made available online as HTML or PDF at the Caml website. For those not familiar with Objective Caml (or OCaml, as it is commonly called), it is a strongly, statically typed (but don't be thinking about Pascal-style typing), eagerly evaluated language with a functional core that also offers many imperative programming features. OCaml also has full support for object-oriented programming that fits in completely with OCaml's strong type system. On top of that, OCaml code can be interpreted for simple scripting, compiled to bytecode for portability, or compiled to native code for speed and resource utilization that rival even that of Intel's C++ compiler. Intrigued?" If so, read on for the rest of Neumann's review.
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.
This discussion has been archived. No new comments can be posted.

Developing Applications With Objective Caml More

Developing Applications With Objective Caml

Comments Filter:

  • MLDonkey (Score:4, Informative)

    by Megaslow ( 694447 ) * on Tuesday November 30, 2004 @05:12PM (#10957367) Homepage
    Possibly the most widely used app written in Objective Caml -- MLDonkey [nongnu.org]

    • Re:MLDonkey (Score:3, Informative)

      by bcrowell ( 177657 )
      Also unison [upenn.edu], which is a great app.

    • FFTW (Score:3, Funny)

      by geneing ( 756949 )
      I think FFTW would be the most famous and useful if not the most popular.

      • Re:FFTW (Score:3, Funny)

        by sketerpot ( 454020 ) *
        For those who haven't heard of it, FFTW stands for Fastest Fourier Transform in the West [fftw.org], and it's a library for computing some discrete Fourier transforms really quickly.

        • Further clarification (Score:4, Informative)

          by j1m+5n0w ( 749199 ) on Tuesday November 30, 2004 @11:11PM (#10960220) Homepage Journal
          FFTW is written in C, so I was confused what it had to do with Ocaml. According to the faq [fftw.org]:
          FFTW is written in ANSI C. Most of the code, however, was automatically generated by a program called genfft, written in the Objective Caml dialect of ML. You do not need to know ML or to have an Objective Caml compiler in order to use FFTW. genfft is provided with the FFTW sources, which means that you can play with the code generator if you want. In this case, you need a working Objective Caml system. Objective Caml is available from the Caml web page.
          • Sounds to me as if they are using ocaml to compile 'something' to C.

            I don't think that counts as writing it in C any more than compiling a C program to binary means that I *wrote* the machine code.

  • Muchly needed (Score:5, Funny)

    by Tibor the Hun ( 143056 ) on Tuesday November 30, 2004 @05:14PM (#10957385)
    Why just last week I was developing applications with an Opinionated Camel, and it was hell.

    Hell, I tell ya.

  • Intrigued? (Score:5, Insightful)

    by hobuddy ( 253368 ) on Tuesday November 30, 2004 @05:22PM (#10957458)
    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.

    • Re:Intrigued? (Score:5, Interesting)

      by Anonymous Brave Guy ( 457657 ) on Tuesday November 30, 2004 @05:29PM (#10957525)

      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.

      • Re:Intrigued? (Score:5, Interesting)

        by Coryoth ( 254751 ) on Tuesday November 30, 2004 @05:50PM (#10957742) Homepage Journal
        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...

        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:Intrigued? (Score:2, Informative)

        by arjun ( 33278 )
        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.
        can you say Paul Graham [paulgraham.com]?

    • Re:Intrigued? (Score:5, Informative)

      by Anonymous Coward on Tuesday November 30, 2004 @05:39PM (#10957645)
      Well, that may have been true five or ten years ago, but have you checked the Caml humps http://caml.inria.fr/humps/ recently ?

      For GUI you have Tk, GTK, GTK2 ; some people have written interfaces to the Win32 API. Concerning data structures, the standard library has lots (lists, hashtables, queues, sets, maps), and if that's not enough, you name it, you have it (from splay trees to bitvectors), and not only esoteric data structures available only in functional languages. With Bigarray you can MMap huge arrays of whatever you want (bytes, floats). With the built-in lazy streams you can easily hack a LL parser, and if that's not enough you can run ocamlyacc. There are interfaces for Postgresql, mysql. Unix support is very complete (and portable). There is a good crypto library. For number-crunching you have the built-in number library, GMP bindings or numerix. Interfacing to C is excellent. I mean, come on, Perl and Java have, today, more in their libraries, but you really can't call Ocaml's library support "pathetic". Ocaml can and is really used for real apps (Coq, MLDonkey, etc.) with real GUIs. You can't say the same for Scheme. Plus, Ocaml compiles to machine code on i386, PowerPC and a few other architectures, and that runs damn fast even if you don't spend the afternoon optimizing your code.
      • Scheme is used for real applications with real GUIs -- the PLT web server, for example.

        Also, the crypto library is... a good start. Assuming you mean Cryptokit, it has issues.
      • The libraries you mention are C libraries, not OCaml libraries. When I use an advanced 4th generation programming language, I want its libraries to also be of 4th generation quality, i.e. no hacked wrapping of other languages libraries. In other words, I want the libraries to reflect the qualities of the programming language I am using. If I am to use C libraries through Ocaml, why bother? I would do it with C++ and gain access to lots of other C++ only libraries, as well as the very fine tools that are ava

    • Attack a niche (Score:3, Insightful)

      by DavidNWelton ( 142216 )
      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 dilem

    • Re:Intrigued? (Score:5, Informative)

      by srussell ( 39342 ) on Tuesday November 30, 2004 @05:44PM (#10957690) Homepage Journal
      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.

      I don't know; I've always been able to find libraries that I needed for Haskell; there are quite a few listed on the Haskell libraries [haskell.org] page. It seemed to me, when I was evaluating OCaml, that a lack of libraries bindings or bindings to other language's libraries was not a problem. They've got quite a decent database of extensions at The Camel Humps [inria.fr]

      I'm mainly a Java and Ruby developer, though, so I may not have stressed tested the availability of Haskell libraries. Java doesn't use libraries; if somebody writes a third-party library for it, Sun re-implements it, poorly, and bundles it with the VM, which effectively kills the original, and often superior, library. And Ruby... well, you just create whatever bindings you need, dynamically, with 'dl'.

      --- SER

    • I don't know about those other ones, but Guile has a very nice set of libraries to play with. I set out to learn a bit more about it and was very impressed with what I've seen so far.

      My biggest learning curve with lisp was with manipulating the data structures. Once I got that out of the way, I found the language to be quite impressive. It still tends to feel like scripting rather than "real" programming though, probably because I started out with E-Lisp.

    • Library is not the only problem of Ocaml IMHO: I tried once to learn it but I disliked its syntax which is "weird" (not bad like Perl, just weird) and the book I used to learn (French book) kept pushing the functionnal style even in situations where it makes the code more difficult to read than imperative style.

      Which is a shame IMHO, in some case functionnal style is easier to use, in other it is not: if a language supports both style, why not use the style which suits the problem?

      • Agreed. The syntax is seriously quirky, especially for a functional language. They are usually more attentive to that sort of things, but not ocaml. I worked through the first couple of chapters in that book once, and I remember thinking it was as idiosyncratic as C.

    • Re:Intrigued? (Score:3, Interesting)

      by upsidedown_duck ( 788782 )
      The same limitation applies to Lisp, Scheme, Haskell, Erlang, etc.

      (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

    • Re:Intrigued? (Score:5, Informative)

      by The boojum ( 70419 ) on Tuesday November 30, 2004 @06:37PM (#10958271)
      One solution that many of these languages are now taking is to target either the .NET framework or the JVM. For example, F# [microsoft.com] and SML.NET [microsoft.com] are two different projects from Microsoft Research aimed at producing ML-like compilers targeted at .NET. The Bigloo [inria.fr] Scheme compiler now has an experimental .NET backend in addition to native code and JVM backends. There are also some Haskell compilers targetting the .NET now. If you look around, quite a few functional languages are beginning to support some combination of .NET and the JVM.

      For many languages, this solves exactly the problem that you describe. The new language instantly gets the benefit of large, useful and well tested library. The language developers can focus on the design of their language and leave the hassle of building and maintaining the supporting run-time and library to someone else. Eventually they can add a more native-feeling system library layer over it, but targeting the .NET or JVM gets them off the ground right away.

      There's a few quirks involved in shoehorning functional languages this way. As I recall, the JVM is a bit more difficult to compile functional languages to since it is really intended to run Java. .NET is a bit easier, though there are still some quirks. Many of those are known at this point, however, and there are even some libraries even to help work around them (e.g. the ILX [microsoft.com] SDK developed for F#.) I also think I recall something about the next update to MSIL addressing many of those quirks to simplify the development of functional language compilers.

      • Re:Intrigued? (Score:3, Insightful)

        by hobuddy ( 253368 )
        The problem with .NET or Java as a solution to the library problem is that you end up using your functional language:

        1) On a proprietary runtime. In the case of .NET, it's also a platform-specific runtime. Don't even bother mentioning Mono; the Microsoft Corporation that exists in the universe I inhabit will never allow Mono to grow into anything more than a token antitrust smoke screen, a perpetually not-quite-ready, not-quite-compatible runner-up. If you expect Microsoft to behave differently, you mus
        • 1) I won't argue ideology here; I'm from the pragmatic use-what-works school. But I have Joel Spolsky's Fire and Motion column in mind here. Once the runtime technology reaches maturity, there's not really any need for Mono to try to keep up. Look at Java: how many of the extra libraries are really used? Most programmers won't have a need for too much beyond the core library and won't bother learning all the silly esoteric additions. Once Mono's caught up with the (fairly static) core and can run 99%
      • Don't forget about nemerle [nemerle.org]. It's built on .net (and developed on mono). Its design clearly owes a lot to ml, but its syntax is much easier to wrap your head around than that of ml and derivatives, especially if you're coming from a C/C++/Java/C#/Perl/whatever background.
    • I don't miss anything for Common Lisp. Have you checked the CL community lately?

    • 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.

      That's one of the hopes behind a common multiple-language (polyglot ?) virtual nachine like parrot.

      Parrot will support big language like Python and Perl6.
      Bindings and libraries will be written for python-vm but could be used from within any language that supports parrot as target.

      Then you could use or create whatever language you like. As long as it

    • Re:Intrigued? (Score:2, Interesting)

      by matthewknox ( 835024 )
      actually, this is not a significant issue in lisp anymore. Lisp developers can access any java libraries from jfli . This is a pretty amazing hack, and means that lisp probably has better library support than any other language at the moment, given that lisp calls to C with ease and has pretty significant native libraries, too. It almost begs the question: what excuse are the parenphobes going to use now?
    • OCaml's major problem is that, like every other functional language

      Stop there. that is the problem. The reason functional languages fail is because they are functional languages. They are powerful, but amazingly terse and difficult for even a jedi-level programmer to fully comprehend.

      Great to hack in, great to show your buddies how amazingly awesom0 you are, worth fuck-all when you have a real development environment when the junior engineers outnumber the senior engineers 5-1 or even 10-1.

      Oops bug

      • Re:Intrigued? (Score:2, Informative)

        by vague ( 107055 )
        Ehrm, that's a problem of education, needing better intro texts, not of the language. Here's the truth: functional programming is no harder to imperative programming. It only appears that way because most of the current educational material isn't written by people who understand the needs of non-programmers. The bracketing is only a problem for those who are used to different syntaxes really.

    • Re:Intrigued? (Score:2, Funny)

      by edp927 ( 240364 )
      The real problem with OCaml (and modern functional programming in general) is that its too frnech. perhaps if it were called Freedom Programming....

    • 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, [...]

      This may have been true 5 years ago, but today you can call Perl 5 libraries [merjis.com] and Python libraries [sourceforge.net] directly from OCaml.

      Rich.

  • I tried learning OCaml (Score:4, Insightful)

    by Coryoth ( 254751 ) on Tuesday November 30, 2004 @05:28PM (#10957521) Homepage Journal
    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.
    • I had a "types and programming languages" (graduate level) course at UPenn that made heavy use of OCaml. Though I can't imagine voluntarily going through that material, the resources page [upenn.edu] gives a good general background including OCaml references. The homework page [upenn.edu] provides some OCaml programming examples. The solutions seem to have been pulled, but I imagine they are still easily found on archive.org (which is not responding for me right now to check) or via google.

    • Re:I tried learning OCaml (Score:2, Informative)

      by Anonymous Coward
      I've learned Caml literally by reading the manual and would highly recommend checking the manual out to anyone interested in Caml. It has an introductory section which is enough to get you started, a detailed description of language features and the standard library.

      I would say Caml is a lot easier to get into then Scheme/Lisp or Haskell (having worked with all 3).

      Haskell and Scheme are both nicer to program in however in Haskell it is often difficult to get good performance out of the final program and

  • My first Caml script... (Score:4, Funny)

    by Anonymous Coward on Tuesday November 30, 2004 @05:28PM (#10957524)
    _
    .--' |
    /___^ | .--.
    ) | / \
    / | /` '.
    | '-' / \
    \ | |\
    \ / \ /\|
    \ /'----`\ /
    ||| \\ |
    ((| ((|
    ||| |||
    //_( //_(

    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.

    • Dear CowboyNeal (Score:4, Funny)

      by zoloto ( 586738 ) on Tuesday November 30, 2004 @05:49PM (#10957736)
      Does this count the same as anyone from GNAA?

      Or because it's CAML, will it be allowed? Please tell me what to flame!

    • First o'caml script (Score:4, Funny)

      by sik0fewl ( 561285 ) <<xxdigitalhellxx> <at> <hotmail.com>> on Tuesday November 30, 2004 @06:37PM (#10958270) Homepage
      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
    • Looks more like brainfuck [muppetlabs.com] source to me.

  • Chapter 8: Toes (Score:5, Funny)

    by apachetoolbox ( 456499 ) on Tuesday November 30, 2004 @05:32PM (#10957568) Homepage

    :D

  • Careful about speed comparisons (Score:5, Interesting)

    by Junks Jerzey ( 54586 ) on Tuesday November 30, 2004 @05:36PM (#10957616)
    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.

    • Re:Careful about speed comparisons (Score:4, Insightful)

      by Svartalf ( 2997 ) on Tuesday November 30, 2004 @06:05PM (#10957912) Homepage
      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.
      • Its not that simple. C++ doesn't provide functional programming constructs; OCaml does and encourages its use. Functional programming can cost much more resources than OO programming.

        To compile functional code that looks pretty, the result is often resource wasteful:

        - Memory is copied at every turn (in functional constructs, variables cannot be changed),

        - About all small functions use recursive calls (no, tail-recursion doesn't solve most of them; often the result of the recursion has to be modified befo
    • 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

  • Full Support? (Score:3, Informative)

    by engywook ( 802813 ) on Tuesday November 30, 2004 @05:36PM (#10957619) Homepage
    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."?

    • No. That sentence can be parsed two ways, and presumably was meant the other way to the way you interpreted it...

    • Not QUITE. The statement probably ought to have been phrased as follows:

      "OCaml also has full support for object-oriented programming that fits in completely with Caml/ML's strong type system..."

      Probably was more of a not-thinking typo than anything else, considering that OCaml is a superset of Caml, which is a superset of ML- both of which have strong variable typing.

  • Huh. (Score:2, Interesting)

    by rackhamh ( 217889 )
    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.

  • In related news, (Score:2, Funny)

    by Anonymous Coward
    In Korea, only old people use scripted languages.

  • No good tutorial about ocaml... (Score:4, Insightful)

    by zymano ( 581466 ) on Tuesday November 30, 2004 @06:19PM (#10958083)
    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.
    • but there are!
      I learned the language online, (just as i learned Java from their very good tutorial)

      they gave 2 good ones at the top.
      the Richard Jones'
      Ocaml Tutorial for people who know how to program 'normally' [merjis.com]

      There is also an update to Jason Hickey's book [metaprl.org]

      I like OCaml because it Combines the power of functional programming, like (tail-)recursion, functions as an argument, with 'normal' programming language statements.
      It doesn't force the "functional programming way" on you, like Lisp does, So, you ca
    • There's a bunch of good tutorials here [inria.fr]. I learned everything I know about ocaml from there, in particular from Jason Hickey's, Richard Jones' and the OCaml manual. I spent a week learning that stuff and playing with it, and another week writing from scratch a rather non-trivial program that would have easily taken two months in C. I found ocaml astounding: nearly as fast as C, as compact and elegant as python (arguably more so, in fact).

  • Pascal comment (Score:3, Insightful)

    by Trillan ( 597339 ) on Tuesday November 30, 2004 @06:38PM (#10958293) Homepage Journal

    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.

    • yep. the string problem has been solved for years. and it was practically the only real problem with the pascal strong typing
  • 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.
    • It's pretty safe (IIRC, I think the only type problem is with the unserialisation, which must be cast upward), but, since it has both static and inferred typing, it's fast while not making you write oodles of declaration just to get your program running. Fans of inferred typing argue that if you're not sure of your program's typing, then you're really sure how it's supposed to work either. Since it's inferred, the typing can be extremely fine-grained, allowing high performance, but you, the user, don't have
    • There are many reasons why OCaml comes out on top in language comparisons. Go to the The Computer Language Shootout Benchmarks [debian.org] and compare them yourself. To name a few:
      • Interactive interpreter and fast native compiler.
      • Parametric polymorphism
      • Pattern matching
      • Functors
      • Highly efficient garbage collection
      • Closures (which I find to be more powerful than Objects)
      • Functions as first class values
      • Derived types - Ocaml is efficient, static and strongly typed, but you can write without explicit typing.

    • If you use C++ for its power and flexibility then some of the features in OCaml will make you cry, and realise how low-level C++ remains in some respects.

      I write mathematical software all day in C++, which we use for exactly those reasons (and its good portability). Still, it hurts to think how many times 5+ lines of cluttered C++ would become a single, elegant line in a decent functional language. Obviously the work I do is particularly suited to a functional style, but I've always had a background envy

  • OCaml tutorial (Score:5, Informative)

    by Richard W.M. Jones ( 591125 ) <rich@@@annexia...org> on Tuesday November 30, 2004 @07:18PM (#10958643) Homepage
    Objective CAML (OCaml) is a very cool and powerful language. We use it at our company extensively, and we've released a lot of tools under open source licenses (see my signature). You can, for example, call Perl and Python libraries, and COM objects directly from OCaml, and interfacing with C is trivial.

    I've also written an OCaml tutorial for people coming from 'conventional' languages like C, Perl and Java [merjis.com].

    Rich.

  • Here [mu.oz.au] is a beautiful derivative of prolog in desparate need of an o'reilly treatment.

  • In this talk [plover.com] appears the quotation:

    It was only because he was unfamiliar with 1960's programming styles that he thought that one goto every fifty lines was a frequent use of goto.)

    Which made me physically shudder. What could these ancient horrors look like? Could anyone post a link to some of this ancient and offensive code? I mean I've written code for school if a group member has used *a* goto. This is something I need to see.

  • I was getting into OCaml a while back, to the point where I wanted to replace my extant software with OCaml rewrites, and then someone pointed something out to me: OCaml has an annoyingly onerous license. You aren't allowed to distribute, fork, change, or anything the main OCaml source. How annoying!

    • RTFL (Score:4, Informative)

      by pikine ( 771084 ) on Tuesday November 30, 2004 @10:35PM (#10960010) Journal
      I'm not sure how you could refute the official objective caml license [inria.fr], 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.
  • OCAML is a great language. Unfortunately, despite its excellent performance on many benchmarks, OCAML performance on common kinds of numerical or graphics code is still lacking.

    Basically, if you can't write a complex FFT with a user-defined complex number type and have it work about as efficiently (in both space and time) as equivalent Fortran 90 or C++ code, then the language is not suitable for modern general-purpose applications. Java fails this test, too. Among commonly used modern languages, C++, C
    • Basically, if you can't write a complex FFT with a user-defined complex number type and have it work about as efficiently (in both space and time) as equivalent Fortran 90 or C++ code, then the language is not suitable for modern general-purpose applications.

      I completely disagree.

      1) What do you consider "about as efficiently?" A ten-second search turns up an FFT benchmark [inria.fr] written by Xavier Leroy; he reports that it runs about 2/3 as fast as C code.

      2) What the hell kind of "modern general-purpose applic

      • Re:great language, but not quite general purpose (Score:5, Insightful)

        by geg81 ( 816215 ) on Wednesday December 01, 2004 @07:39AM (#10962064)
        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 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 dat

  • OK OK flamebait, troll, whatever... but I still don't see the point of having a very small niché language messing around open source projects... i've seen a sourceforge project that have a part written in Ocaml, and their dependance on a very small language which very few people know about, is stalling the project big time.

    Maybe Ocaml is the heck of a development language, but I think it's about 5 years late...

    my 2 cents.
  • I develop in a range of languages, but mostly Java for its cross-platform-ness and GUIs, and Python for its clear syntax.

    If i had a combination of the two - python's pureness and cleanliness and Java's x-platform libraries - i would be pretty happy. However, i would still be stuck with Swing for GUI work.

    I would like to see a language that is built for creating rich GUIs, and have it be as clean and simple as Python, and as well thought out as InterfaceBuilder (OS X).

    Java/Swing (and TCL/TK is surely wors
  • Why use Ocaml? the question has been raised before. Should I use it for being functional? but functional programming has practical issues.

    For example, sorting with functional languages is very very slow, since lists are copied over and over, and for each sorted element, a new list is created. For example, the quicksort algorithm takes each element of the input list, then splits the rest of the list to less than the element and greater than the element lists, sorts these lists and then combines the three pa

Slashdot Top Deals

Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke

Close