Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Developing Applications With Objective Caml

timothy posted more than 9 years ago | from the watering-hole dept.

Programming 243

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.

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.

cancel ×

243 comments

Sorry! There are no comments related to the filter you selected.

I'd rather develop things with this babe... (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#10957356)

IMPORTANT UPDATE: Please show your support [calcgames.org] for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux [debian.org] users are a bunch of flaming homosexuals [lemonparty.org] when its fronted by obviously gay losers [nylug.org] like these?! BSD [dragonflybsd.org] has a mascot [freebsd.org] who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks [hope-2000.org] and gorgeous babes [hope-2000.org] then maybe it would be able to compete with BSD [openbsd.org] ! Hell this girl [electricrain.com] should be a model!

Linux [gentoo.org] is a joke as long as it continues to lack sexy girls like her [dis.org] ! I mean just look at this girl [dis.org] ! Doesn't she [dis.org] excite you? I know this little hottie [dis.org] puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox [spilth.org] . As you can see, no man can resist this sexy [spilth.org] little minx [dis.org] . Don't you wish the guy in this [wigen.net] pic was you? Are you telling me you wouldn't like to get your hands on this ass [dis.org] ?! Wouldn't this [electricrain.com] just make your Christmas?! Yes doctor, this uber babe [electricrain.com] definitely gets my pulse racing! Oh how I envy the lucky girl in this [electricrain.com] shot! Linux [suse.com] has nothing that can possibly compete. Come on, you must admit she [imagewhore.com] is better than an overweight penguin [tamu.edu] or a gay looking goat [gnu.org] ! Wouldn't this [electricrain.com] be more liklely to influence your choice of OS?

With sexy chicks [minions.com] like the lovely Ceren [dis.org] you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD [netbsd.org] if she [dis.org] told you to? Personally I know I would give my right arm to get this close [dis.org] to such a divine beauty [czarina.org] !

Don't be a fag [gay-sex-access.com] ! Join the campaign [slashdot.org] for more cute [wigen.net] open source babes [wigen.net] today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

Ceren is sort of like a flea infested alley cat (1)

Fecal Troll Matter (445929) | more than 9 years ago | (#10957497)

Have you any Lenka? [freeones.com]

MLDonkey (3, Informative)

Megaslow (694447) | more than 9 years ago | (#10957367)

Possibly the most widely used app written in Objective Caml -- MLDonkey [nongnu.org]

Re:MLDonkey (0, Troll)

mordors9 (665662) | more than 9 years ago | (#10957516)

Well then, shouldn't the RIAA file suit on OCaml also. After all it is being used to write an application that is being used illegally by some people. Certainly they should have foreseen this.

Re:MLDonkey (1)

Taladar (717494) | more than 9 years ago | (#10957825)

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 (2, Funny)

Anonymous Coward | more than 9 years ago | (#10958326)

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 (1)

mordors9 (665662) | more than 9 years ago | (#10958412)

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

Re:MLDonkey (0)

Anonymous Coward | more than 9 years ago | (#10958594)

Yeah, you can't be too subtle with some of the moderators. It goes right over their head.

Re:MLDonkey (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10957527)

That's funny I thought it was CAMLToe [ratemycameltoe.com]

Re:MLDonkey (0)

Anonymous Coward | more than 9 years ago | (#10957533)

Ocaml! The reason I gave up on compiling mldonkey and installed amule from rpm's. Yes I know it's inferior but I had 1 day to use up 1Gig and no time to play with compile errors.

Re:MLDonkey (2, Informative)

bcrowell (177657) | more than 9 years ago | (#10957692)

Also unison [upenn.edu] , which is a great app.

FFTW (2, Funny)

geneing (756949) | more than 9 years ago | (#10957718)

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

read on for the rest of Neumann's review. (-1, Offtopic)

gonerill (139660) | more than 9 years ago | (#10957370)

Or as I call him, Neumann!

Re:read on for the rest of Neumann's review. (0)

Anonymous Coward | more than 9 years ago | (#10957517)

What, me worry?

Muchly needed (5, Funny)

Tibor the Hun (143056) | more than 9 years ago | (#10957385)

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

Hell, I tell ya.

Re:Muchly needed (0)

Anonymous Coward | more than 9 years ago | (#10958579)

Were the Twins there? Good, Wicked and Evil?

OCaml is popular, but not everywhere (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10957393)

Why, in Korea, OCaml is only for old people.

KOREA/SOVIET/...is dying (-1)

Anonymous Coward | more than 9 years ago | (#10957413)

Okay, this is getting old...fast

Re:KOREA/SOVIET/...is dying (-1)

Anonymous Coward | more than 9 years ago | (#10957448)

funny, i read "SOVIET KOREA is dying"

Re:KOREA/SOVIET/...is dying (-1)

Anonymous Coward | more than 9 years ago | (#10957755)

you must need glasses... yeah that is funny!

http://example.com/ [example.com]

Moderation Abuse (0)

Anonymous Coward | more than 9 years ago | (#10957732)

The article was about Objective Caml. Parent post was directly talking about Objective Caml. No way is that offopic.

I think some moderators are letting their anti-Korean prejudices show when in fact we could learn a lot from the people of Korea. In Korea, these sorts of prejudices are only for old people.

Re:Moderation Abuse (0)

Anonymous Coward | more than 9 years ago | (#10957785)

Everybody is suspicious of Koreans...in Japan!

Re:Moderation Abuse (0)

Anonymous Coward | more than 9 years ago | (#10957820)

Perhaps, but in Soviet Russia Koreans are suspicious of YOU.

Book is five years old, whew... (-1, Offtopic)

tcopeland (32225) | more than 9 years ago | (#10957417)

...one of the nice things about Ruby [ruby-lang.org] is that Dave Thomas and Andy Hunt keep Programming Ruby [pragmaticprogrammer.com] up to date. The second edition just came out, and it's a good one.

If you're using Ruby or are interested in using it, it's an excellent written by someone who's very active [rubyforge.org] in the Ruby community.

Re:Book is five years old, whew... (0)

Anonymous Coward | more than 9 years ago | (#10957559)

I'm a Ruby zealot myself, but this comment was the most off-topic ever seen on /.! I know nothing about OCaml (I learn Scheme now) and I'd prefer REAL opinion from real OCaml guys...

Re:Book is five years old, whew... (1)

KoporShow (618049) | more than 9 years ago | (#10958160)

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.

Re:Book is five years old, whew... (0)

Anonymous Coward | more than 9 years ago | (#10957582)

Wow, and K&R's ANSI C is like over ten years old - C must be like so shit, no wonder no-one uses it!!! God bless a language that needs its goalposts moving every year. Yes, I want to spend more time learning how to use my tool than actually using it.

Intrigued? (5, Insightful)

hobuddy (253368) | more than 9 years ago | (#10957458)

Yes, I've been intrigued by OCaml for a long time.

OCaml's major problem is that, like every other functional language available today, the breadth of its standard library and third-party libraries is totally pathetic in comparison to the likes of Java and Python. The same limitation applies to Lisp, Scheme, Haskell, Erlang, etc.

These languages face a Catch-22: until they're more popular, they won't attract enough developers to ameliorate the library situation, yet until they offer better libraries, they won't attract developers. Historically, this barrier has been surmounted in one of two ways: either a deep-pocketed corporation subsidizes library development until the language gains momentum (see Java, C#) or the languages are sufficiently "charming"/"hip" that the library support appears as a result of a grass-roots effort (see Perl, Python).

Is there any realistic prospect that one of the functional languages I mentioned will strike it rich in either of those ways? It doesn't seem likely to me.

Re:Intrigued? (5, Interesting)

Anonymous Brave Guy (457657) | more than 9 years ago | (#10957525)

I totally agree with your comments about the need for a standard library. But, as you observe yourself, such things can be developed by the community: CPAN for Perl, CTAN for TeX, and Boost for C++ are all very high quality libraries that are pretty much entirely community-developed.

I think the most obvious missing thing is a figurehead for functional programming. A fair few of programming language geeks seem to be fans, but as someone posted here once before (sorry, can't remember who), functional programming has yet to find its Larry Wall. I'd like to think that the first time someone steps up and takes on that role, that will get the geeks going, and the snowball will start to form. All we need is someone qualified who wants to put in the effort, but of course there are going to be very few such people around in a relatively small corner of the programming world -- catch 22, indeed.

Re:Intrigued? (4, Interesting)

Coryoth (254751) | more than 9 years ago | (#10957742)

I totally agree with your comments about the need for a standard library. But, as you observe yourself, such things can be developed by the community: CPAN for Perl...

On that front, it will be interesting to see what will happen in Parrot [parrotcode.org] successfully manages its dream of uniting (amongst others) Perl, Python and Ruby - allowing a module from one language to be used in another. Surely that confluence of communities could build a very formidable library indeed...

Jedidiah.

Re:Intrigued? (5, Informative)

Anonymous Coward | more than 9 years ago | (#10957645)

Well, that may have been true five or ten years ago, but have you checked the Caml humps http://caml.inria.fr/humps/ recently ?

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

Push popularity using .net/mono (1)

jerometremblay (513886) | more than 9 years ago | (#10957685)

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 [microsoft.com] this [nemerle.org] and this [sourceforge.net] , 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 (1)

killjoe (766577) | more than 9 years ago | (#10957761)

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

Re:Push popularity using .net/mono (1)

jerometremblay (513886) | more than 9 years ago | (#10957884)

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 (0)

Anonymous Coward | more than 9 years ago | (#10958389)

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

You already can: try http://merjis.com/developers/perl4caml/ [merjis.com] .

Re:Push popularity using .net/mono (1)

Taladar (717494) | more than 9 years ago | (#10957885)

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 (2, Insightful)

DavidNWelton (142216) | more than 9 years ago | (#10957688)

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.

Re:Intrigued? (4, Informative)

srussell (39342) | more than 9 years ago | (#10957690)

OCaml's major problem is that, like every other functional language available today, the breadth of its standard library and third-party libraries is totally pathetic in comparison to the likes of Java and Python. The same limitation applies to Lisp, Scheme, Haskell, Erlang, etc.

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

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

--- SER

Re:Intrigued? (1)

fossa (212602) | more than 9 years ago | (#10958402)

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? (0)

Anonymous Coward | more than 9 years ago | (#10957753)

I think you really should look into Ocaml again if you're under the impression that it lacks a great deal of third party libraries or abilities.

I've programmed in Java since its introduction, and in C++ for far longer. Ocaml's standard library is 'far' from pathetic. It is definitely lacking a good imperitive library to match its functional one--- but its functional library is by many means far more complete than that of C++, and nearely as complete as Java's.

I think the assertion that Ocaml's library is 'totally pathetic' in comparison is simply incorrect.

There is also an Ocaml implementation in Java, and it's easily combined into a stand-alone executable along a C/C++ which allows it to be interfaced with a wide variety of libraries with ease.

The language is very comprehensive, easy to read and use. Its object oriented features leave some things to be desired, but then again so does Java and C++'s. It can be both natively compiled, and interpreted as byte-code. And, it's damn fast.

-Jason Thomas.

Re:Intrigued? (1)

Greyfox (87712) | more than 9 years ago | (#10958046)

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? (1)

renoX (11677) | more than 9 years ago | (#10958052)

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? (2, Interesting)

upsidedown_duck (788782) | more than 9 years ago | (#10958058)

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? (0)

Anonymous Coward | more than 9 years ago | (#10958330)

(Common) Lisp lacks only a non-proprietary and useful GUI toolkit. Otherwise it has just about everything.

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. There's also nothing even approaching a consensus on web development frameworks, as exists in Java servlets and EJBs. Plus, the most technically excellent open source implementations don't work on Windows.

"Just about everything", indeed, as long as you stick to cute quicksort implementations and never try to write a real cross-platform application that a community of human beings will actually--gasp--USE.

Same Problem (1)

Umbral Blot (737704) | more than 9 years ago | (#10958167)

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 (0)

Anonymous Coward | more than 9 years ago | (#10958408)

Oh, I dunno, maybe by posting a clever throwaway comment in a slashdot developer thread?

Always wanted to know what would happen if visual basic met forth in a supercollider. Now i know...

Re:Intrigued? (4, Informative)

The boojum (70419) | more than 9 years ago | (#10958271)

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

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

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

Re:Intrigued? (2, Insightful)

hobuddy (253368) | more than 9 years ago | (#10958575)

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? (1)

maw (25860) | more than 9 years ago | (#10958583)

Don't forget about nemerle [nemerle.org] . It's built on .net (and developed on mono). Its design clearly owes a lot to ml, but its syntax is much easier to wrap your head around than that of ml and derivatives, especially if you're coming from a C/C++/Java/C#/Perl/whatever background.

Re:Intrigued? (1)

stesch (12896) | more than 9 years ago | (#10958338)

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

Re:Intrigued? (0)

Anonymous Coward | more than 9 years ago | (#10958437)

Although the lack of libraries does have an effect on the Caml and other functional languages not being wide spread I think a bigger problem is that functional programming is too different from imperative programming and most C++/Java programmers just can't see the benefits of learning a functional language.

90% of programmers I know are happy with C++/Java and are not interested in checking any other language out.

The other 10% usually check out Python or Perl (and to a lesser extent Ruby) partially because they are more accessible then functional languages and partially because they have bigger communities/more libraries.

Parrot may change this (1)

DrYak (748999) | more than 9 years ago | (#10958686)

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

any other questions? (0)

Anonymous Coward | more than 9 years ago | (#10957461)

Intrigued?

No. Next?

Objectivist camels? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10957471)

In Korea, Ayn Rands riding camels are for old people.

Would an Islamic hacker be an (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#10957484)

Objective Camel Jockey?

I tried learning OCaml (3, Insightful)

Coryoth (254751) | more than 9 years ago | (#10957521)

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 (3, Informative)

drafalski (232178) | more than 9 years ago | (#10957653)

I had a "types and programming languages" (graduate level) course at UPenn that made heavy use of OCaml. Though I can't imagine voluntarily going through that material, the resources page [upenn.edu] gives a good general background including OCaml references. The homework page [upenn.edu] provides some OCaml programming examples. The solutions seem to have been pulled, but I imagine they are still easily found on archive.org (which is not responding for me right now to check) or via google.

Re:I tried learning OCaml (2, Informative)

Anonymous Coward | more than 9 years ago | (#10958164)

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.

My first Caml script... (4, Funny)

Anonymous Coward | more than 9 years ago | (#10957524)

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

Important Stuff

# Please try to keep posts on topic.
# Try to reply to other people's comments instead of starting new threads.
# Read other people's messages before posting your own to avoid simply duplicating what has already been said.
# Use a clear subject that describes what your message is about.
# Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)

Problems regarding accounts or comment posting should be sent to CowboyNeal.

BEWARE! (1, Funny)

Anonymous Coward | more than 9 years ago | (#10957665)

Contains subliminal likeness of goatse "giver".

Dear CowboyNeal (3, Funny)

zoloto (586738) | more than 9 years ago | (#10957736)

Does this count the same as anyone from GNAA?

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

First o'caml script (3, Funny)

sik0fewl (561285) | more than 9 years ago | (#10958270)

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

Chapter 8: Toes (4, Funny)

apachetoolbox (456499) | more than 9 years ago | (#10957568)


:D

Re:Chapter 8: Toes (1)

FerretFrottage (714136) | more than 9 years ago | (#10957662)

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.

Careful about speed comparisons (5, Interesting)

Junks Jerzey (54586) | more than 9 years ago | (#10957616)

OCaml code can rival C++ code in benchmarks...if you write OCaml that looks like C++. Yes, the OCaml code is still probably safer in the end, but the OCaml solutions to many of the benchmarks are just nasty. The prettier, straightforward solution is often 2-4x slower than the C++ version. So is OCaml fast? Yes. But please be careful here.

Re:Careful about speed comparisons (0)

Anonymous Coward | more than 9 years ago | (#10957784)

This is true (and true of other functional languages too). I think you can reasonably spin this as an advantage however.

You can say that ocaml allows you to write most of your code in a high level way that's easier to write, understand and maintain and for the small bits of your code that really need high perfomance you can start thinking more like a C programmer and get up to C performance levels.

Simply stated, the advantage is that you don't have to think like a C programmer all the time, just for the performance bottleknecks.

Re:Careful about speed comparisons (3, Insightful)

Svartalf (2997) | more than 9 years ago | (#10957912)

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 (3, Insightful)

KoporShow (618049) | more than 9 years ago | (#10958091)

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.

Full Support? (3, Informative)

engywook (802813) | more than 9 years ago | (#10957619)

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? (1)

Anonymous Brave Guy (457657) | more than 9 years ago | (#10957655)

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

Re:Full Support? (1)

Oxy the moron (770724) | more than 9 years ago | (#10957787)

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

Re:Full Support? (0)

Anonymous Coward | more than 9 years ago | (#10957809)

Ocaml came from a type system, in ML, without the concept of objects. An object is a type, but a type in Ocaml isn't neccessarily an Object. In a pure OOP language, this would be true. What this comment means is that Ocaml's Objects work with the underlying strongly typed system. You should look at Ocaml's type inference capabilities if you want to know what implications this has for Object Oriented programming.

Re:Full Support? (1)

Svartalf (2997) | more than 9 years ago | (#10957872)

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? (1, Interesting)

Anonymous Coward | more than 9 years ago | (#10957891)

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.

Frog language (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#10957680)

I think there's a review over at http://www.fuckfrance.com/ [fuckfrance.com]

On another note, did Michael Simms commit suicide like he promised us if Kerry didn't win?

Huh. (2, Interesting)

rackhamh (217889) | more than 9 years ago | (#10957724)

At first read I thought it said "Developing Applications With Objective Calm" -- which, come to think of it, would probably make for a pretty interesting article.

In related news, (2, Funny)

Anonymous Coward | more than 9 years ago | (#10957769)

In Korea, only old people use scripted languages.

Re:In related news, (0)

Anonymous Coward | more than 9 years ago | (#10958328)

Caml is not and has never been a scriptING language.

tac3O (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#10957794)

cycLe; tak3 a

Developing with a half-camel? (0)

Anonymous Coward | more than 9 years ago | (#10957802)

Buffy and especially Willow/Tara fans know what I mean.

I'd consider OCAML (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#10957844)

If it didn't have such atrociously ugly syntax. An OCAML with pure lisp sexp syntax might be bearable.

Re:I'd consider OCAML (2, Interesting)

KoporShow (618049) | more than 9 years ago | (#10958212)

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.

Who needs another boutique goof ball language (0)

Anonymous Coward | more than 9 years ago | (#10957909)

Someone's pet hobby horse. Perl is bad enough.

Frog language (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10957966)

I think there's a very good review over at http://www.fuckfrance.com/ [fuckfrance.com]

On another note, did Michael Simms commit suicide like he promised if Kerry didn't win?

No good tutorial about ocaml... (3, Insightful)

zymano (581466) | more than 9 years ago | (#10958083)

I looked everywhere. None are intuitive and easy like the java.sun.com tutorial.

I downloaded the compiler about a year ago but got turned off by the quality of tutorials.

You need easier reading material if you want people to adopt.

Re:No good tutorial about ocaml... (0)

Anonymous Coward | more than 9 years ago | (#10958372)

Out of curiosity have you tried reading the manual? I thought the manual served great as an introductory text/tutorial as well as a language reference.

manual (1)

zymano (581466) | more than 9 years ago | (#10958682)

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:No good tutorial about ocaml... (3, Informative)

nietpiet (836036) | more than 9 years ago | (#10958541)

but there are!
I learned the language online, (just as i learned Java from their very good tutorial)

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

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

I like OCaml because it Combines the power of functional programming, like (tail-)recursion, functions as an argument, with 'normal' programming language statements.
It doesn't force the "functional programming way" on you, like Lisp does, So, you 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.

I find that a Camel often helps me code. (0)

Anonymous Coward | more than 9 years ago | (#10958098)

Damn company only lets me smoke 'em outside though.

Pascal comment (2, Insightful)

Trillan (597339) | more than 9 years ago | (#10958293)

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 (0)

Anonymous Coward | more than 9 years ago | (#10958484)

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 wasn't alive in the 1970's, but in the 1990's when I was taught Pascal in school, "array[1..20] of char" and 'Foo' were different types on both compilers I used.

Maybe it's better now -- I haven't done Pascal in a while -- but it certainly wasn't universally better 30 years ago.

Man, I still don't 'get' functional programming (0)

Anonymous Coward | more than 9 years ago | (#10958461)

Are there any good websites for how to learn a functional programming language that are devoted strictly to people who are experienced in normal programming languages?

(Sorry for the use of the word 'normal'. I don't mean anything untoward by that)

Re:Man, I still don't 'get' functional programming (2, Informative)

stdcallsign (558206) | more than 9 years ago | (#10958676)

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

Eiffel is all this and more... (1)

darp (181922) | more than 9 years ago | (#10958503)

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.

Things I want to know about a new language: (2, Interesting)

Pacifix (465793) | more than 9 years ago | (#10958562)

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: (1)

pkhuong (686673) | more than 9 years ago | (#10958746)

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.

OCaml tutorial (4, Informative)

Richard W.M. Jones (591125) | more than 9 years ago | (#10958643)

Objective CAML (OCaml) is a very cool and powerful language. We use it at our company extensively, and we've released a lot of tools under open source licenses (see my signature). You can, for example, call Perl and Python libraries, and COM objects directly from OCaml, and interfacing with C is trivial.

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

Rich.

Mercury (2)

G. Waters (172392) | more than 9 years ago | (#10958672)

Here [mu.oz.au] is a beautiful derivative of prolog in desparate need of an o'reilly treatment.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?