Developing Applications With Objective Caml

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.

Comments

MLDonkey

[Megaslow]

Possibly the most widely used app written in Objective Caml -- MLDonkey

Re:MLDonkey

[bcrowell]

Also unison, which is a great app.

Re:MLDonkey

[Taladar]

Then they should start suing at the source: C is used to write all P2P apps directly or indirectly (the compiler/interpreter/VM for the language used to write the P2P app is written in C).

Re:MLDonkey

[Anonymous Coward]

You're obviously kidding, the true fault clearly lies in the x86 instruction set and assemblers. If they had only stopped to think about how end users would take those innocent MOV's and POP's and pervert them into Peer2Peer thought-stealing technology. How many billions in "lost" content revenue would have been saved? What about the children?

Re:MLDonkey

[mordors9]

Modded down as a troll. You have to be kidding. It is obvious that I was spoofing the RIAA. It is spelled sarcasm.

Muchly needed

[Tibor the Hun]

Why just last week I was developing applications with an Opinionated Camel, and it was hell.

Hell, I tell ya.

Intrigued?

[hobuddy]

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?

[Anonymous Brave Guy]

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?

[Anonymous Coward]

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.

Re:Intrigued?

[srussell]

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

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

Re:Intrigued?

[Coryoth]

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 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?

[Greyfox]

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.

Re:Intrigued?

[renoX]

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?

Re:Intrigued?

[upsidedown_duck]

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 be done better, faster, and with fewer problems.

Re:Intrigued?

[The boojum]

One solution that many of these languages are now taking is to target either the .NET framework or the JVM. For example, F# and SML.NET are two different projects from Microsoft Research aimed at producing ML-like compilers targeted at .NET. The Bigloo 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 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?

[stesch]

I don't miss anything for Common Lisp. Have you checked the CL community lately?

Re:Intrigued?

[fossa]

Hi, I've been using Ruby for some time and never seen Ruby/DL. It looks very promising. Is this the preferred way to write extensions when a shared lib is available? I've been having good luck with the fairly simple "traditional" method of writing and compiling extensions in C, and I've never (well, now I'm not sure...) run across an extension that used Ruby/DL. Do you know of any good comparisons online? Perhaps I should just try to write my next extension with Ruby/DL. I suppose not needing a C compiler is quite an advantage.

Re:Intrigued?

[hobuddy]

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 must not be referring to the corporation that's been systematically raping its competitors by whatever means necessary for the last two decades. The safest elements of .NET--those that have been submitted to ECMA--exclude almost all useful libraries.

2) With libraries that were designed for consumption by object-oriented client languages, which robs the would-be functional programmer of much of the value of the functional way. The programming experience degenerates into a sad parody of functional programming that really amounts to object-oriented programming through a functional condom. To paraphrase the famous quote about condoms, "Functional programming with object-oriented libraries is armor against productivity, gossamer against library scarcity."

3) On a runtime that performs 3-10 times worse than a runtime designed for the langauge in question.

Re:Intrigued?

[maw]

Don't forget about nemerle. 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.

Re:Intrigued?

[sketerpot]

Sockets are almost universally available, but they're implementation specific. Threads are much the same. There are several relational database APIs, GUI APIs, HTTP/FTP/XML-RPC libraries, XML libraries, cryptographic libraries, imaging libraries, and more. The biggest problem is that the fancier commercial implementations (which have all the stuff you mentioned built in) cost so much money.

Re:Intrigued?

[Theatetus]

The Common Lisp standard library offers "just about everything" except sockets, threads, a relational database API, a GUI API, standard HTTP/FTP/XML-RPC libraries, XML libraries, cryptographic libraries, imaging libraries, and the list goes on.

Eh... as long as you're sticking with a given implementation you have all that, and most of it is pretty good.

For that matter, nowadays if you're using lisp in a production environment you're pretty much using one of: Allegro, CMU-CL, or SBCL. They each have their own implementation of the libraries you mentioned. And anyways there's a good Allegro/CMU compatability layer and SBCL is compatible with CMU natively. ASDF solved a lot of these library problems.

htmlgen, odbc, postgres, gtk, sdl, opengl, blowfish, twofish, aes, des, md5, elgamal, irc, tcpip, sockets, and of course ffi: I have all of those installed on my lisp boxes, and they do what they say they do. Now, when I'm working with Forth, that's a different story...

Re:Intrigued?

[srussell]

No, I think the preferred way is to use real bindings, although I haven't done a speed test to see if there's any real advantage to a true binding. I like Ruby/DL because I've been able to write a cross-platform binding for Matlab with it -- something I was unsuccessful at doing with the standard method. As you suspect, not requiring a C compiler is a huge advantage, especially on Windows.

--- SER

Re:Intrigued?

[Dunedain]

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.

Re:Intrigued?

[Theatetus]

Maybe. Then again I haven't worked at a site that used Windows since 2001. Different perspectives I guess.

Re:Intrigued?

[matthewknox]

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?

Re:Intrigued?

[arjun]

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 ?

Re:Intrigued?

[psbrogna]

"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"

So why did PHP gain momentum? Yes it has commercial backing, but I don't think that effected the take up rate. Is PHP really cool/hip?!

Re:Intrigued?

[The boojum]

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% of the programs out there, it'll probably be good enough for most people.

2) Functional programming is all about creating abstractions. Yes, depending on the language's FFI the abstraction layer might look ugly. But I'll bet it's still faster to create a small functional-style shim layer on top of a set of FFI calls than it is to reimplement the routines from scratch. You can always migrate to more elegant pure code later if you really want to spend the time on it.

3) Programmer time is expensive, hardware time is cheap. By your argument we'd all be writing assembly code and no one would ever use a scripting language. Most people using a high level functional language aren't doing it for performance reasons; they're doing it for the higher levels of abstraction they can achieve. I think many would gladly trade the performance penalty you mention for a chance to save themselves the chore of all that extra coding and debugging.

Re:Intrigued?

[gnovos]

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 in the production server that could cost us millions, what do we do? Nope, 90% of our workforce has no chance of even comprehending where it printed out the error to the screen, so I guess we have to call in that fuck-tard who wrote the damn thing. Fire him and rewrite it in visual basic.

Don't believe me? Here's a random section from near the TOP of chapter ONE in one of the tutorials mentioned above:

Note - no brackets, and no comma between the arguments.

Now confusingly repeated ("hello", 3) is meaningful in OCaml. It means "call the function repeated with ONE argument, that argument being a 'pair' structure of two elements". Of course that would be a mistake, because the repeated function is expecting two arguments, not one, and in any case the first argument is a string, not a pair. But let's not worry about pairs ("tuples") just yet. Instead, just remember that it's a mistake to put the brackets and commas in around function call arguments.

What the fuck does that mean?

call the function repeated with ONE argument, that argument being a 'pair' structure of two elements for crying out loud!

Re:Intrigued?

[edp927]

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

Re:Intrigued?

[bluFox]

He cant be for two reasons,
1) His language is arc, a variant of lisp, not exactly a functional language, nor does it look like one from the available material that he has released. Lisp is a multi-paradigm language that is only incidently functional.
2) He does not seem too keen to be building up a community :)

Re:Intrigued?

[vague]

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?

[Vintermann]

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?

[Richard W.M. Jones]

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 and Python libraries directly from OCaml.

Rich.

Re:Intrigued?

[meadowsp]

Ummm. Java does use libraries (in the form of jars), log4j and junit are a couple of examples.

And the VM run's the language spec, has nothing to do with the libraries.

Re:Intrigued?

[master_p]

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 available. C libraries use C principles, not Ocaml principles.

Another important point is that with languages like Java, most of the libraries are packed together with the programming language. Only one download is needed for developing applications. This is important not only for marketing reasons, but for knowing that there are absolutely no integration problems, and that the documentation is coherent.

Re:Intrigued?

[renoX]

"as idiosyncratic as C"

No, more like Pascal or Ada..
I remember thinking 'why the hell did they get inspired from Pascal? Nobody use Pascal..'

If they had tried to imitate C, I think it would have been better (except for the variable definition in C which is a mess, but this is not a problem in Ocaml): many more people know C/C++, the transition would have been less awkward.

Anyway I don't think, I'll try again to learn OCaml: each time there is a problem, it feels like doing math, Ruby is much more simpler to learn IMHO (but it runs also much more slower unfortunately).

Re:Intrigued?

[Vintermann]

It annoys me that I can't remember exactly what it was about OCaml syntax that annoyed me, but I do remember constantly mixing up OCaml and SML syntax.
I think there were some odd symbols in OCaml that made me think of C. I like Ada, it doesn't abuse symbols in syntax unnecessarily, and is comfortably verbose for my tastes (my limit goes at SQL :-). It may take a little more time to type, but thinking is the bottleneck when I'm programming!

Oh yeah, one of those weird things was the different syntax for accessing an element in a string and accessing an element in an array. And coming straight from looking at Ada I felt weird when using three or four different forms of brackets...

Re:Intrigued?

[hamfed]

People interested in OCaml may want to check out Nemerle (http://nemerle.org). Like OCaml, it offers type inference and both functional & object-oriented features. However, since it is built for the .NET platform you can take advantage of the .NET BCL (as well as third-party .NET assemblies). Note that it supports both Microsoft and FOSS .NET implementations.

Re:Intrigued?

[srussell]

I was being facetious. Sun has an established history of taking popular libraries, duplicating them, and embedding them in the standard library. This is a large part of why the Java API is so bloated these days.

--- SER

I tried learning OCaml

[Coryoth]

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.

Re:I tried learning OCaml

[drafalski]

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 gives a good general background including OCaml references. The homework page 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

[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 at the same time maintain code that is readable (simply because you have to "help" the compiler a lot). If you don't need speed then Haskell is great although I found it fairly difficult to get into (in particular getting used to monads - not so much using existing monads as much as figuring out what they do and how they do it).

Scheme is in some ways nicer then Haskell (extremely simple syntax, great macros, dynamically typed, great for metaprogramming) but in other ways not even nearly as nice (Haskell is a pure functional language unlike Scheme and Caml, elegant handling of side effects, type inference, pattern matching, ability to compose functions and program without variables (to some extent), lazy evaluation). My main problem with Scheme is that there aren't that many implementations that are compliant with the current standard (R5RS) and there are no decent free compilers for Scheme (especially ones that are R5RS compliant).

Caml is easier to get into because the structure of Caml programs closer resembles structure of programs written in imperative languages. Unlike Haskell and Scheme it also comes with a great native code compiler. It's a great starting point for anyone interested in learning functional programming and once you get into it you'll never want to go back to imperative languages.

Currently Ocaml is the only functional language implementation that can favorably compete with most imperative languages in terms of performance which makes it great for general purpose programming. MLton, a StandardML implementation, comes pretty close but it doesn't seem as mature as Caml.

Finally both Caml and Haskell have a great foreign language interface and it's quite easy interfacing them with C.

Re:I tried learning OCaml

[The boojum]

I've been using Bigloo (from the same folks as OCaml) for Scheme. You might find it gives you a lot of what you want.

My first Caml script...

[Anonymous Coward]

_
.--' |
/___^ | .--.
) | / \
/ | /` '.
| '-' / \
\ | |\
\ / \ /\|
\ /'----`\ /
||| \\ |
((| ((|
||| |||
//_( //_(

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.

Re:My first Caml script...

[Davorama]

Looks more like brainfuck source to me.

Chapter 8: Toes

[apachetoolbox]

:D

Re:Chapter 8: Toes

[FerretFrottage]

Already used all my mod points as that did make me laugh, but then again what type of geek would even consider camel toes that only run with Windows....well now that I think about it, he'd probably consider any.

Re:Chapter 8: Toes

[kundor]

You puzzle me. Who said anything about only running with Windows?

Re:Chapter 8: Toes

[Tablizer]

Wow! Mod parent up

Careful about speed comparisons

[Junks Jerzey]

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

[Svartalf]

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.

Re:Careful about speed comparisons

[KoporShow]

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.

Re:Careful about speed comparisons

[RdsArts]

But isn't this in general true of all languages? I mean, to write C code to the highest potential, you have to occasionally drop down and inline some cryptic ASM to punch up those few routines that are slow and commonly called.

Or I suppose what I'm asking is, isn't a increase in readablity worth a reasonable hit in performance, expectally if one can then use the less pleasant code when speed is a considerating?

Re:Careful about speed comparisons

[Junks Jerzey]

But isn't this in general true of all languages? I mean, to write C code to the highest potential, you have to occasionally drop down and inline some cryptic ASM to punch up those few routines that are slow and commonly called.

Well, not quite. In C you pay as you go. You essentially have a direct mapping to common hardware. You can go faster, yes, but the improvement generally isn't worth it unless you're targeting specific weirdness like MMX or SSE2.

OCaml has some significant overhead that comes from the language definition. There's garbage collection, which while fast is certainly not free. Floating point values in mixed-type tuples are heap allocated (that is, the floating point values--doubles, actually--are separate heap objects). There's the classic issue with functional languages that the simple and easy way to build a list either involves stack space for each element or a full reversal of the list (not in place) at the end.

I fully agree with you that readability is worth a hit in performance. I use interpreted languages all the time, and compiled OCaml is certainly much faster than them. But OCaml advocates need to be careful about claiming their language is as fast as C/C++, because it generally isn't true. It's only true if you drop the nice features and write grungy C-style code, and then only in certain situations. This does not mean it is a bad language, however.

Re:Careful about speed comparisons

[__aaahtg7394]

There's garbage collection, which while fast is certainly not free.

Actually, running benchmarks, it's found that the GC OCaml uses is faster than the repeated brk()s you get with C's malloc()/free(). If you profile it out, brk() is really expensive when you're dealing with a segmented heap/arena.

I don't know how the tuple issue falls out, though I'm sure Xavier Leroy and friends have done the best they can, as usual.

Re:Careful about speed comparisons

[TheRaven64]

Disclaimer: I have never used OCaml. I have, however, used Haskell (a functional language that, apparently, inherits quite a lot from OCaml - the OCaml code in one of the links in TFA looked remarkably similar to Haskell).

One of the advantages of functional languages that is not often mentioned is that it is relatively easy (at least in comparison with imperative languages) to implicitly parallelise the code. As an exercise, I sat down with a piece of Haskell code and some lambda calculus (*shudder*) to see how much of it a compiler could determine could be executed in parallel. While this may not be a huge advantage now (since most PCs have a single CPU), the advent of multi-core chips, mainstream SMP, and the increasingly slow rate of increase in raw CPU speeds this may make functional languages increasingly more attractive.

Personally, I'd rather use a declarative language that's actually fun to use, like Prolog.

Re:Careful about speed comparisons

[sangdrax]

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 before returned),

- Generic functions cannot be optimised well (C++ compiles a specific version at instantiation with a template).

To name a few. If you want raw execution speed in OCaml, use the procedural constructs. The computer is built to run code like that.

Re:Careful about speed comparisons

[Junks Jerzey]

One of the advantages of functional languages that is not often mentioned is that it is relatively easy (at least in comparison with imperative languages) to implicitly parallelise the code.

This has been a cited advantage of functional languages since the 1970s, but it hasn't come to fruition. In theory, yes, it's a big win, but in practice it's very difficult to do.

Re:Careful about speed comparisons

[Junks Jerzey]

Actually, running benchmarks, it's found that the GC OCaml uses is faster than the repeated brk()s you get with C's malloc()/free(). If you profile it out, brk() is really expensive when you're dealing with a segmented heap/arena.

Yes, GC can be faster than C's malloc/free, but that's not what I'm talking about. I'm talking about statically allocating your memory, as is the norm in embedded systems. Then you have no malloc/free overhead and no GC overhead, period.

Re:Careful about speed comparisons

[TomorrowPlusX]

It's true. I've been bitten by the surprisingly bad performance of std::vector in tight inner loops ( opengl code, doing hairy stuff at runtime ).

While I try to stick with the STL, there are times when you need to just eat it and use traditional arrays. And all sorts of other nasty things like making local copies of simple objects to avoid repetitive dereferencing and so on and so forth.

The important part is to explain in your documentation and source comments *why* you've done these things, so that other programmers -- or you in the future -- won't think "what the hell is this crap" and then undo some hairy code in the name of "elegance" and lose a 500% speedup.

Full Support?

[engywook]

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."?

Re:Full Support?

[Anonymous Brave Guy]

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

Re:Full Support?

[Oxy the moron]

No, but you can get OCaml in any color as long as it's black. =]

Re:Full Support?

[Svartalf]

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.

Re:Full Support?

[Anonymous Coward]

Missing a comma is all. Slashdot editors don't or can't, take your pick.

The funny thing is, the OO system of ocaml actually doesn't really fit into the type system that well. Methods can't be polymorphic (i.e. they have to take real types, not 'a). Meanwhile, functions can be polymorphic, but can't be overloaded. Try to get too abstract with polymorphism and covariance, and you get monomorphism restrictions coming around and biting you. Let's not even get into how painful it is to represent something as simple as an "unsigned 32 bit int" (kinda useful when doing network programming) in ocaml. And yes, the same could be said for Java, and I say it loudly and often.

That said, Ocaml's easier to learn than Haskell: objects are easier to deal with than existential types, there's no monads, and you get variables that act more or less like you'd expect. Unfortunately, the core language hasn't seen any significant updates, and even camlp4 hacks are sort of petering out. I'd hate to see Ocaml fizzle out, but I don't know that slashdot articles are going to save it from the apparent neglect by its core developers.

Re:Full Support?

[jodonoghue]

I'd have to agree with both of your points.

To be honest, and this is after using Ocaml extensively for a while, Ocaml's object system doesn't really work very well. I loved the language before I started to use the OO features, but working on LablGTK2 drove me crazy. The syntax (both for open types, and for keyword arguments) is ugly and poorly documented.

For command line software (mainly short scripts and 'parser' type applications), I still love the speed (both of development, and execution) of Ocaml, but I don't touch it for GUI programming any more.

I'm also inclined to agree that the core developers at Inria have moved on to other things. Whether this is because some of the language 'features' are seen as dead-ends (I'd suggest the implementation of OO polymorphism is one which doesn't meet real-world needs), or whether their research interests have somply moved on is not clear.

While many (including myself) complain at the lack of an elegent GUI interface, I've also looked into what would be needed to do such a thing myself (my poison of choice was wxWidgets, as I use Mac, Linux and Windows regularly, and *much* prefer having native look and feel. Gtk is really only fine for Linux), and the work involved looked very painful, unless you would accept an ugly interface to the C bindings for wx (I looked at using the wxEiffel C bindings as a starting point).

I know there's a fledgling wxCaml in the works, and I wish them luck. I agree that it would be a shame to see the language wither on the vine, although I fear that this is what is happening.

Having said that (and I speak as a real-time embedded developer), I am utterly convinced that many of the ideas embodied in Ocaml (type inference, functional/imperative programming mix etc) are the future of high-performance programming, and will eventually largely replace C for all but the lowest level tasks.

I doubt that Ocaml will be the language to do that, however. It will probably be a successor which learns from its shortcomings and builds on its (many) strengths. Probably a language yet to be written, in fact.

Re:Full Support?

[warrax_666]

Methods can't be polymorphic (i.e. they have to take real types, not 'a)

Yes they can. You just have to declare them slightly differently:

method blah : 'c. f:('c -> 'c) -> 'c = ...

will give you a polymorphic method (in the type 'c).

Unsigned 32bit int: While not representable directly, you can just use int32. Since all platforms which ocaml actually runs on are two's completement all operations except comparisons work as expected. If you need comparisons you can just use an int64 and make sure to (mod 2^32) it when needed.

Unfortunately, the core language hasn't seen any significant updates, and even camlp4 hacks are sort of petering out

Nonsense. Examples: the pa_macro camlp4 module was added in 3.07, and the object system had a few significant changes somewhere in the 3.05-3.08 timeframe (can't remember precisely, check the changelog if you care).

Besides, who says that stabilization is a bad thing?

Re:Full Support?

[wirelessbuzzers]

The funny thing is, the OO system of ocaml actually doesn't really fit into the type system that well. Methods can't be polymorphic (i.e. they have to take real types, not 'a).

# object
method trivialPolyMethod x = x
end
;;
- : < trivialPolyMethod : 'a -> 'a > = <obj>

Still, you're right, in that you occasionally have to use hacks, like casting self to its own class, to deal with bugs (or design failures) in the type checker.

BEWARE!

[Anonymous Coward]

Contains subliminal likeness of goatse "giver".

Push popularity using .net/mono

[jerometremblay]

This is where .net and mono could do a difference. They allow any language to be used with each other. So get your favorite functional language compiled for .net and you instantly have the whole library.

But despite this and this, as far as I can see there have not been any massive worldwide shifts toward functional programming recently.

I guess it's hard to change.

Re:Push popularity using .net/mono

[killjoe]

If parrot can host ocaml then you will be able to call perl libraries from ocaml.

Re:Push popularity using .net/mono

[jerometremblay]

Well, it's kinda my point.

If libraries are not the issue, then why aren't functionnals language more popular?

Re:Push popularity using .net/mono

[Taladar]

And you are locked into Windows just like MS planned .net

Unless Mono gets some sort of legal backup I wouldn't develop anything in .net
...at least nothing that isn't portable to another non-.net compiler/interpreter if necessary.

Attack a niche

[DavidNWelton]

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.

FFTW

[geneing]

I think FFTW would be the most famous and useful if not the most popular.

Re:FFTW

[sketerpot]

For those who haven't heard of it, FFTW stands for Fastest Fourier Transform in the West, and it's a library for computing some discrete Fourier transforms really quickly.

Huh.

[rackhamh]

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.

Dear CowboyNeal

[zoloto]

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 related news,

[Anonymous Coward]

In Korea, only old people use scripted languages.

Re:In related news,

[TheLink]

In the Spyware Infested Internet, scripting languages use you!

No good tutorial about ocaml...

[zymano]

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.

Re:No good tutorial about ocaml...

[nietpiet]

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'

There is also an update to Jason Hickey's book

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 can still use the If then, and While statements if you find them more usefull then a recursion.

And, it is quite fast!
both in development and in execution.
however, i have yet to find a way to well commenting my code.

Re:No good tutorial about ocaml...

[voodoo1man]

It [Ocaml] doesn't force the "functional programming way" on you, like Lisp does

I don't know how you can claim that, considering that Ocaml doesn't even have goto.

Re:No good tutorial about ocaml...

[zymano]

Thanks.

Re:No good tutorial about ocaml...

[rsidd]

There's a bunch of good tutorials here. 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).

Re:Book is five years old, whew...

[KoporShow]

I am a big fan of Ruby either.

I use Ruby for scripting exclusively, but my experience is that dynamically typed programming languages are not suited for larger projects, since they tend to have a lot of runtime errors, and very sensible to changes in compiler version.

The file synchronisation tool unison shows that OCaml is exteremely well suited for complex file-manipulation algorithms.

Same Problem

[Umbral Blot]

I can relate to that. Centum has the same problem ... how can I attract talented developers to write libraries when talented developers usually only work with languages that provide them with the libraries they need?

Re:Same Problem

[sketerpot]

You could take a leaf out of O'Caml's book and make an interface to Perl.

Re:I'd consider OCAML

[KoporShow]

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.

First o'caml script

[sik0fewl]

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

Pascal comment

[Trillan]

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.

Re:Pascal comment

[Trillan]

I suppose you're right. The real problem is very likely the standardized class content wasn't updated in 20 years. I was given that line in high school, too, late 80s or early 90s -- teachers just evaded the string type for some reason. I'd been using it for years at that point, on that very compiler...

Re:Pascal comment

[marcovje]

Turbo Pascal, that came out mid eighties had a string type. Delphi improved strongly on that.

Of course, one can try to argue that Borland dialects are not std pascal (the 70ies kind that the anti pascal rants are about), but the Borland dialects do account for 99.9% of the Pascal programmers.

Re:Pascal comment

[dunkelfalke]

yep. the string problem has been solved for years. and it was practically the only real problem with the pascal strong typing

Re:Pascal comment

[Trillan]

I know Apple Pascal had a string type as well. I'm not sure if that predates Borland's, but it certainly predates the Macintosh by at least a year (call it 1983).

Re:Pascal comment

[marcovje]

The point remains the same. Pascal is constantly bashed for things that nearly all production language had before 1985.

However the other languages are forgiven for it, but not Pascal for some mysterious reason.

Eiffel is all this and more...

[darp]

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.

Re:Eiffel is all this and more...

[brpr]

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.

Re:Eiffel is all this and more...

[ElHorrendo]

While you may know Eiffel you clearly do not know Ocaml. Ocaml has multiple inheritance, in fact it has powers well beyond this as compatibility of types is derived! Deriving types is a power that is hard to comprehend until you've experienced the relief this grants programmers. Conventional languages force programmers to do lots of type administration, and the vast majority of these tasks disappear in Ocaml. They disappear in much the same way memory administration disappears when you have efficient garbage collection.

Re:Eiffel is all this and more...

[Anonymous Coward]

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

Things I want to know about a new language:

[Pacifix]

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.

Re:Things I want to know about a new language:

[pkhuong]

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 to do all the grunt work. It's also, dare I say it, a clean language.

Re:Things I want to know about a new language:

[ElHorrendo]

There are many reasons why OCaml comes out on top in language comparisons. Go to the The Computer Language Shootout Benchmarks 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.
• Time travel debugger (step forward or backward)
• Very fast and efficient code.
• Minimal memory consumption.

See the Wikipedia for a brief overview.

Re:Things I want to know about a new language:

[meowsqueak]

I'm just curious (not trolling or being obnoxious) to know what you mean by a 'clean language'? Few exceptions to the syntax? Looks tidy?

Re:Things I want to know about a new language:

[Anonymous Brave Guy]

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 of people who get to use grown-up toys like this in their programming jobs.

OCaml tutorial

[Richard W.M. Jones]

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.

Rich.

Re:OCaml tutorial

[Richard W.M. Jones]

(and also!) If you're a business using Objective CAML, find other businesses and people using it here.

Re:OCaml tutorial

[DannyO152]

Ocaml has been at the periphery of things I wanted to learn for a while now. Thanks to the reviewer and team for the heads up about and translation of le livre O'Reilly. And thank you Rich for the tutorial which I plan to work through.

Re:OCaml tutorial

[nrrd]

Wow, I've only read the first couple of sections, but it looks like a great tutorial. I've been meaning to do some OCaml programming and I'll be using your tutorial to get up to speed.

Mercury

[G. Waters]

Here is a beautiful derivative of prolog in desparate need of an o'reilly treatment.

Re:Man, I still don't 'get' functional programming

[stdcallsign]

http://merjis.com/developers/ocaml_tutorial/

manual

[zymano]

the manual pdf at the link was way over my head.

I guess I am no computer science major because it was difficult reading.

Re:manual

[808140]

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.

Re:manual

[zymano]

I will try learning it again.

Parrot may change this

[DrYak]

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 targets parrot, all parrot bindings and libraries will be available to your scripts, even if the libraries aren't written in you language but with some other language supported by parrot.

Maybe once parrot reaches more stable and mature stages in a couple of years, we may see the advent of a lot of small special purpose scripting languages. Developpers won't be affraid to invent some highly specific language for their application, because users will be able to re-use libraries done for other languages.

Imagine a Parrot-enabled console in Quake V or Doom VI, and you could try using some AI modules in parrot bytecode format from some MOD for Unreal 2009 (or Duke Nukem 4 if there's the slightest chance it ever comes out by then... )

How is this news

[patonw]

I've been using this as a reference since college. This has been out for years.

Re:How is this news

[Anomalous Communard]

It's not -- it's a review.

Re:I'd consider OCAML

[pkhuong]

If you can't see the structure for the parens, you need an editor.

goto

[CaptainPinko]

In this talk 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.

Re:goto

[808140]

Don't write much assembly, do you?

Big problem with OCaml

[sudog]

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!

great language, but not quite general purpose

[geg81]

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#, and Fortran 90 pass that test.

Re:great language, but not quite general purpose

[Fourier]

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 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 application" needs to compute FFTs quickly? That's a highly specialized application.

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.

Re:great language, but not quite general purpose

[geg81]

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.

Re:great language, but not quite general purpose

[Anonymous Coward]

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

Re:great language, but not quite general purpose

[Anonymous Coward]

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.

Re:great language, but not quite general purpose

[Fourier]

Thanks for elaborating--you have made your point more clearly. I'm not sure I agree with the conclusion that OCaml (like Java) is defective due to deficiencies in handling of numeric types, but I see where you're going.

Re:great language, but not quite general purpose

[geg81]

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.

Re:great language, but not quite general purpose

[geg81]

Along that line, are there any technical limitations--e.g., about the compiler design, etc.--that prevent the sort of numerical libraries you mention from being developed? Is it just a matter of a critical mass of effor being focused on numerical computing in OCaml?

I think it's the usual combination of things:

• It requires some small language changes that people who don't need the feature consider unnecessary language complexity, so these kinds of proposals usually cause lengthy discussions.
  
• It requires a large chunk of work on an implementation that was designed without those features in mind.
  
• The people who need the feature are generally not the ones that are in a position to modify the compiler and runtime; and the people who can modify the compiler and runtime think (incorrectly IMO) that other needs are more pressing and find other topics (call/cc, whatever) more interesting to work on.
  

It seems to take a few decades until efficient numerical abstraction facilities get added to languages/language families. With Fortran, it took until the 1990's. With C, it took until C++ came out. With Pascal, it also took until the 1990's. Java has steadfastly refused to do anything about this (despite lots of recommendations and push from users), but C# is picking up the torch there. The core of what is needed is efficient value classes, efficient arrays of value classes, built-in mono-typed multidimensional arrays, a small amount of overloading, and a few smaller sundry things. Nice, but not stricly speaking necessary, are built-in data-parallel array operations and linear algebra functionality in the standard library.

There have been some timid attempts at efficient functional programming languages for numerical computations. One of the best known is probably SISAL. But while SISAL was a valiant attempt specifically for numerical applications, it fails at being a good general purpose language: that is, numerical code is all you ever want to write in it.

Re:great language, but not quite general purpose

[jaoswald]

The issue with performance of things like the FFT is not really with the language, per se, but with the compilers.

In fact, a naive implementation of the FFT is going to suck in C also. Because FFT performance is not determined by the expression of the algorithm so much as it is determined by the actual bits-meets-metal details, such as instruction pipelining and memory architectures.

The way you get efficient FFT algorithms is not just by writing them in C, but having a combination of a library writer and compiler writer who both know how to get the absolute peak performance out of a particular processor (and cache hardware.)

It just happens that C compilers have included enough hooks to low-level processor primitives, and C serves as a universal "high-level" assembler, so that you can create efficient FFTs that link well to C, and might even be written in C. (Although you better make sure to use the right C compiler or your performance will suffer.)

The reality is that we are just slightly advanced from the need to write performance bottlenecks in assembler. Somebody sufficiently skilled has to write the routines in carefully tweaked C, and use the best available C compiler to generated architecture-specific libraries.

If Intel (or even the gcc architects) built OCaml compilers that knew as much about IA-86 as their C compilers do, then you wouldn't be complaining.

Re:great language, but not quite general purpose

[Fourier]

Basically, if you can't write a complex FFT with a user-defined complex number type and have it work about as efficiently...

Of course, I couldn't help myself and had to go experiment a bit. My conclusion is that you're halfway correct. A naive FFT implementation using the standard Complex module delivers very poor performance. A few minutes with the profiler demonstrates that the biggest problem is the immutability of the standard Complex datatype. You end up doing lots of needless allocations and garbage collections--mark_slice alone accounts for 40% of the computation.

But if you're willing to compromise a bit, you can use a mutable data structure and get rid of most allocations. The tradeoff is that the code has lots of assignments--not very functional in nature.

C++ and OCaml code is here. On my (slow) machine, I get the following representative times:

$ time ./fft_cpp

real 0m3.143s
user 0m2.881s
sys 0m0.128s

$ time ./fft_ml

real 0m3.785s
user 0m3.465s
sys 0m0.123s

I consider that pretty good. Note that the C++ STL isn't terribly fast here; you can save about 25% on the C++ code by dumping that in favor of something simpler. But still, OCaml is in the ballpark as long as you're willing to write imperative-looking code.

Re:Book is five years old, whew...

[JamesOfTheDesert]

I use Ruby for scripting exclusively, but my experience is that dynamically typed programming languages are not suited for larger projects, since they tend to have a lot of runtime errors

This is getting off-topic, but maybe this is more a reflection on your coding technique than on dynamically-typed languages?

Annecdotal evidence abounds for all sorts of claims concerning static vs. dynamic typing. My experience is just the opposite of yours.

More specifically, if you are writing anything larger than one-off admin scripts then your code should have unit tests. And proper unit tests will catch the odd runtime error you might otherwise see in the wild. They'll also catch the cast exceptions and null pointer exceptions that still plague statically-typed languages. Merely passing a compilation stage, regardless of the typing system, is no assurance of robust code.

RTFL

[pikine]

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.

Re:RTFL

[sudog]

Not accurate. You are not allowed to combine your patches and make a new distribution out of it. They put portions of it under the QPL specifically to prevent people from what they call "taking credit" for their work.

Total bunk of course, but similar license restrictions are placed on qmail, and the patchsets are a complete mess as a result.

The LGPL is an attempt to hop on the OS bandwagon, but unless the whole thing is free, what freedom is there in that?

That sucks.

Further clarification

[j1m 5n0w]

FFTW is written in C, so I was confused what it had to do with Ocaml. According to the faq:

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.

Re:Further clarification

[myowntrueself]

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.

Re:Further clarification

[smallfries]

From the description it sounds as if genfft creates the C code directly, eg it is a meta-program. Hence the program would contain chunks of ML and chunks of C and an explicit knowledge of how the target program is constructed in C. This is different to writing an FFT in ocaml and having it generate C code.

An alternate view of the book

[jodonoghue]

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.

Conclusion

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

OCaml? How do you eat that?

[Spy der Mann]

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.

Top problem: GUI

[nikster]

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 worse) still requires one to write lots of boring code that should be handled by the framework. In addition, Swing has a huge problem with allowing needlessly many options in implementing common things (and, again, doesn't implement them to begin with) so if you read somebody else's code, chances are they did everything completely differently. There are no design guidelines, and even Sun's code is not consistent in any way.

O'Caml may be better at some things and in some way than Java or Python, but unless a fantastic GUI framework is included, it's not that interesting.

Re:Top problem: GUI

[moebius_4d]

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.

This isn't my problem, but it sounds like Jython would be a perfect fit for you.

I prefer Common Lisp, and for those pesky apps that have to run on a Java runtime I've had good luck with Armed Bear Common Lisp

Practical issues with functional languages

[master_p]

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 parts (the less than part, the element and the greater than part) into the result. It may be only a few lines of code, it may be much clearer than the imperative way, but it is much too slower for practical use.

So, what advantages Ocaml has over traditional imperative languages like C++ or Java when its functional characteristics are not to be used?

Re:Practical issues with functional languages

[master_p]

The reasons you mention are not sufficient enough to make me switch to Ocaml:

1) efficient code output I already have with C/C++/Java.

2) type inference is not very important. I would say that it is a disadvantage, as many logical errors will go undetected until the program runs.

3) I was never tempted to violate safety rules in C++/Java, so it is not something important to me.

4) Hmm, memory management is an issue with C++. I guess Java wins here.

Re:Practical issues with functional languages

[brpr]

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 parts (the less than part, the element and the greater than part) into the result. It may be only a few lines of code, it may be much clearer than the imperative way, but it is much too slower for practical use.

Yawn, you just use an algorithm which works efficiently in a functional language, e.g. insertion sort.

Re:Practical issues with functional languages

[master_p]

"But do you have efficiency and great expressive power (closures, pattern matching, functors,...)? "

C++ has pattern matching and functors. It does not have closures, but there are ways around it that are equally powerful.

"Please know what you are talking about before uttering such sentences! OCaml type inference will catch errors much better than C++/Java because it is (proved) coherent and powerful (unsafe features are not needed to get the job done). "

Maybe you should do that. I said "logical errors", not "type errors". Logical errors are when I mistakingly use another type (for example map, instead of linked list), and the error propagates down to the project. With type inference, the compiler will not say anything, because the map and linked list have the same iteration interface. Without type inference, those places that a linked list is expected instead of map will be immediately recognized by the compiler.

"So you never use casts? ;-)"

I hardly ever need casts in C++, due to templates.

Re:Practical issues with functional languages

[master_p]

"C++ has pattern matching ? Whereabout ?"

It is not only partial template specialization. C++ selects the method to call based on the types supplied to the method. That's exactly the same pattern matching functional languages have.

"The sole fact that nobody (well, sort of) knows how to use it"

You are overreacting. Many coders use it.

"Face it, doing anything even moderately complex in C++ is a real PITA"

I've done many complex things in C++, and guess what? C++ is the best language for it. It has the best speed, and one of the best ways to do it.

"Entire books are devoted to this"

That there are entire books it means that C++ offers a feature that is quite unique and useful.

"where Ocaml handles complex codes in a much more safe & elegant fashion"

There is nothing safe with type inference, as I previously demonstrated. And the functional syntax is no way more elegant that simple Algol-like syntax (at least for me).

"because as soon as you see you used the wrong type"

I've talked about an error, not a choice: someone mistakenly types 'list' instead of 'map': the error will propagate deep in the code.

"it's a matter of seconds to change the type"

I can do the exact same thing with C++. I always typedef my types.

"While in languages like C++, once 200 functions/classes have been defined with the wrong type, you will have to change the interface of the 200 functions/types and all the calling code. I wish you a nice day doing this."

Typedef is your friend! (as I explained above). I actually have done type changes across more than 700 classes with a simple typedef change.

"if you can't make the difference between a map and a linked list, then I would advise you to stop programming."

Well, both are collections...they have the same iteration interface. With many things having the same interface (for example, widget classes in a GUI toolkit), it is possible for many things to go undetected when type inference is used.

As I told you earlier, I always typedef my types, so I never have a problem of changing a type. I only change the typedef.

Re:Practical issues with functional languages

[vague]

I'm late, but you really have no clue and basis for these statements:-/

"C++ selects the method to call based on the types supplied to the method. That's exactly the same pattern matching functional languages have."

Ok, the way you confuse polymorphism, overloading, and pattern matching in this statement is just dear. Runtime or compile time? Same difference!

"There is nothing safe with type inference, as I previously demonstrated. "

No, you certainly did not demonstrate this, you demonstrated that you don't know what OCaml's type inference does for you.

"I've talked about an error, not a choice: someone mistakenly types 'list' instead of 'map': the error will propagate deep in the code."

If you've programmed in such a way that this is true, you only have _one_ place to fix it, just like with your typedeffed code. This is a matter of abstraction, in OCaml as well as in C++.

And type inference and common interfaces are actually contrary, as the overloading, since type inference has to resolve types at compile time it can't properly resolve overloaded functions like an explicitly typed language can. And that's a problem, with OCaml, which we resort to functorial interfaces for solving (i e we dont have overloading but allow parametrisation on name spaces, achieving the same affect in a more controlled manner), since OCaml doesn't have type classes like Haskell does. Look at the great lenghts C++ and Java goes to make sure to define common interfaces for collections and iteration. And for good reason, common interfaces are a _good thing_. Exactly because you can change a 'map' to a 'list' in one place and get great effects.

You should actually bother to learn stuff properly before showing of, well, your ignorance.

O'Caml , isn't the the irish relation?

[Viol8]

Along with his cousin O'Bject?

#read_expression "x-1";;

Exception: You don't want to be reading from that stream you don't lad, no, that ya don't...

On Learning a new programming language

[systems]

It's a popular advice (wisdom) that to be a good
programmer one needs to learn a new programming
language every now and then.

Also another good and popular advice that a programmer
should introduce himself to many programming paradigms
like OOP, AOP, Procedural, Static, Dynamic, Generic, Strongly typed, Weakly typed, Un-typed, etc ...

I think choosing to learn O'caml achieves both advices.
So in other words, you might want to learn O'caml, not just because it's a good language, but because by learning O'caml you might become a better programmer!

Re:Man, I still don't 'get' functional programming

[kent.dickey]

I tried that tutorial website and was reading about ocaml. Writing tutorials is very hard, but when he gave an example for a "range a b" function to give a list with integers from a to b, I just had to try to fix it so that it used tail-recursion in a nice way.

And when I did, I ran right into a problem: "Stack overflow during evaluation (looping recursion?)."

Here is my first ocaml code:

let rec range2 a b accum =
if a > b then accum
else range2 a (b-1) (b :: accum) ;;

let longlist = (range2 1 50000 []) ;;

print_endline (string_of_int (List.length longlist)) ;;
let list_str = List.map string_of_int longlist ;; (* This fails *)
print_endline (string_of_int (List.length list_str)) ;;

So it can't call a basic function map on a list of 50000 items? Can anyone point out what I'm doing wrong? The code works for lower values like 20000.

Parent is Not Safe For Work

[Captain Tripps]

But then, what were you expecting?

Re:Man, I still don't 'get' functional programming

[kent.dickey]

Thanks for the help. I was just seeing if the language was ready for general use. 50000 is a very low limit on recursion, and it also fails when using ocamlc. And the error messages are not very helpful. It's clearly not a jump-right-in language, which is too bad.

OCAML vs Fortran

[G3ckoG33k]

Could Ocaml be a serious alternative to Fortran for scientific/technical computing?

Re:Man, I still don't 'get' functional programming

[vague]

The decision to use a non-tail-recursive List.map implementation was a choice for supperior efficiency in the (far more) common case, e g with smaller lists, where it's significantly faster than List.rev_map. People who needs to deal with 50000 element long lists can cope with using List.rev_map or switching to a different data structure like, say, an array or a dynamic vector. These kind of engineering tradeoffs, efficiency vs generality and similar, _needs_ to be made, and the fact that OCaml chose to optimize for the common case and chose efficieny over theoretical beauty (while giving easy access to a more general solutin) should actually tell you that OCaml is a serious product and not an academic curiousity (as much as I adore those) or a beginners toy. You can think they traded the wrong way, certainly, but their decision absolutely isn't one of ignorance or immaturity.

As for a recursion depth of 50000 being too low, how deep does your recursion usually take you before you start considering the tail-recursive option? If you need greater recursion depth, increase your stack. Simple as that. As for the default, trying it out with Python I got a maximum recursion depth of between 900 and 1000, and that's a practical product used by many. C with msys/mingw/gcc on winXP got a limit of around 72000. That's really not all that much better than the 65000 I got from the OCaml interpreter for the same simplistic program on the same machine.