OCaml for the Masses (2011)

http://queue.acm.org/detail.cfm?id=2038036

by luu • 12 years ago

100 88 12 years ago

queue.acm.org

cordite2• 12 years ago

As a haskeller, I've heard some disconcerting things about OCaml.

Namely, the standard lib is more or less made just to be able to compile itself, and that the standard lib is not pure, which makes developers go to alternate implementations to do the job in a way that is expected.

Please do correct me if what I've heard is wrong.

My only indirect experience with OCaml is the Opa language compiler--so all I've seen is that it is a language favored for implementing languages.

yminsky9• 12 years ago

(Author of the article here)

The stdlib that ships with the compiler is indeed minimal, though it is used for things other than the compiler. It can be used for other projects, but you probably want something more full-featured. Core, and the more minimal and portable Core_kernel (https://github.com/janestreet/core_kernel) is a full-featured alternative that is growing in popularity, and is what the book I worked on (Real World OCaml, http://realworldocaml.org) is based on.

OCaml (and most of both the stdlib and Core) default to immutable data structures, but OCaml has good support for programming imperatively, to its credit, in my view.

jzelinskie• 12 years ago

I've heard that Jane Street uses their own extensions to the language. Also, how does one deal with the development of OCaml being largely done in French?

plinkplonk• 12 years ago

FWIW: Core doesn't work with Windows (the Real World OCaml book does state this upfront) so you need either an OSX or Linux machine to work with Core, and so you can't work through the book with a Windows machine. Something to be aware of.

tomp• 12 years ago

Hi, Yaron! I was recently looking into using Core for one of my projects, but have so far failed to find any good, clear, complete documentation or how-to guide. Is there anything like that available online? I guess I could read the Real World OCaml book to learn parts of it, but I already know OCaml...

a-nikolaev• 12 years ago

I think, you are misinformed. While the standard library is not huge, it is quite ok. Then, OCaml is steadily gaining strength with Opam and Jane Street's libraries, which become de-facto standard. Personally, I see OCaml as C++ done right (minus pointers), if you need pointers, use Rust.

eru• 12 years ago

Or D.

judk3• 12 years ago

The Haskell Prelude is famously awful, so OCaml stdlib isn't much of a needle-mover.

codygman3• 12 years ago

I wouldn't say it's awful, however there are definitely improvements that need to be made.

GreaterFool2• 12 years ago

Another Haskeller here. I strongly recommend you take a second look at OCaml. I think it has some fantastic features that Haskell doesn't:

Modules. They are great for solving major code organisation problems and I really hope Haskell will get a module system soon ("Backpack" paper). Type classes are great for things like Monad and Num since you are likely to use many different Monads or Nums in the same chunk of code. But consider what happens if you want to support both ByteString and Text in your library (let's say a parser library). You may end up with a type class constraint like ListLike and your code will be littered with 'ListLike .. =>'. But when you're parsing some data later on it will be either ByteString or Text. So I'd fix my choice of ListLike at module instantiation time and make the constraint go away. If I need both (e.g. I'm reading some data from a socket and some of it is Text and some of it is ByteString) then I'm just going to instantiate two modules, one for each. To me this is a much cleaner solution.

Named/optional function parameters. They solve a bunch of minor but incredibly annoying problems. A simple example: for (aka flip map); It is not in Prelude and whenever it comes up there are plenty of people who are opposed for one reason or another. In OCaml (Core library) it doesn't matter because map takes the function by named parameter so List.map ~f:(fun x -> x + 1) [1;2;3] works fine and so does List.map [1;2;3] (fun x -> moderately long, perhaps few lines long function). Both cases are important for readability. Another example: in Haskell I've been working with APIs where functions have 20+ positional parameters (yeah, it's terrible design but that's out of my hands). If they were named and some of them optional (most of them really are optional) then the code would be a fraction of what it is.

OCaml is quick to compile. I've been looking at Eliom web framework recently and rebuilding a website takes seconds; compare that to yesod which takes forever and spins all the cores on my laptop which eats my battery in no time.

OCaml code tends to be quite straightforward: from my experience it is longer than Haskell equivalent, uses less abstractions but at the same time it is conceptually simple.

Typed printf. (yeah, there are 'solutions' in Haskell but it's a typed printf out of the box!)

Polymorphic variants. Can be used to bring information to the level of types. Compare

parse :: Parser a -> String -> ParseResult a

with

parse :: Parser a -> String -> [`Error String | `Result a]

Also see OCaml's tyxml package which provides typed html5. Yeah, the types look rather crazy in some places but that's a small price to pay for rooting out invalid HTML.

shadytrees• 12 years ago

Haskell has typed printf out of the box! It recently (v4.7) got a makeover so now it's extensible too. https://hackage.haskell.org/package/base-4.7.0.0/docs/Text-P...

cordite2• 12 years ago

This does make me want to take a look OCaml seriously.

I'd mostly use it in a web server context. Though I have no clue where to really get started in that.

Yesod actually was one of the reasons that pushed me to learning Haskell (though I arguably never got much done in Yesod since it felt like its pragmatisms didn't match up with mine.)

skybrian• 12 years ago

This is from 2011. I wonder how OCaml implementations have changed since then?

yminsky9• 12 years ago

The biggest change is OPAM, http://opam.ocaml.org/, a top-notch package management system that makes installing OCaml packages much easier.

Shameless plug: there's also a newish O'Reilly book, Real World OCaml http://realworldocaml.org, which I think is a big help in learning the language.

Oh, and there's OCaml Labs, a new lab at Cambridge University that's dedicated to improving the language.

And of course the compiler is constantly making progress. The upcoming 4.02 release is a pretty fun one, which I documented here: https://blogs.janestreet.com/ocaml-4-02-everything-else/ And before that, changes like GADTs and first-class modules landed, which have been quite useful extensions.

Really, it's a very active and fun community these days. The language is getting better quite quickly, but mostly in conservative and tasteful ways. The people in charge of the core language have been doing a great job, and the community infrastructure (things like OPAM) have been making big strides as well.

judk3• 12 years ago

Great to here. I tried wodi years ago and it was a disaster. Made hobby-learning ocaml a nonstarter. Opam sounds promising.

girvo2• 12 years ago

OPAM is awesome, made it super easy to install "Batsh"[0], a neat compile-to-bash-or-BAT language. Makes programming in shell not painful :D

[0] https://github.com/BYVoid/Batsh

mercurial2• 12 years ago

It looks like the ecosystem is fairly small. Another thing that is off-putting (unless I'm missing something) is that OPAM packages have no online docs per default, something that is standard with Haskell packages, for instance, and is definitely a big help.

jlarocco2• 12 years ago

I think it's progressing pretty well, but not yet as polished as something like Python or Ruby.

I've tried it a few times through the years. Most recently I grabbed a kindle version of "real world ocaml" a couple months ago, and started to work through it. The fact there's a recent book in English made it easier to get into than the previous times I've looked at it, and a good sign of progress, IMO.

Unfortunately, after a couple weeks a new version of ocaml came out, and some packaged from opam were updated, and something about it broke everything for me and stopped me in my tracks. I'm pretty sure it's a problem waiting for changes to trickle through to osx, but I don't really know. I spun up a linux vm, and everything worked great, so it seems osx specific.

girvo2• 12 years ago

I found that using homebrew's OCaml and OPAM really painful, and made things not work very well. Moving to OPAM directly and letting it manage OCaml for me has made things work brilliantly on OS X, to the point where I really wish I could use OCaml at work; it's a seriously nice language.

jordwalke• 12 years ago

I've seen a ton of great improvements in tooling/ecosystem.

- OPAM was already mentioned.

- The OCaml to JS compiler has matured and gained a lot of use. Interestingly, I suspect that it can also be used to achieve different types of parallelism than the types that the stock OCaml compilers provide. https://github.com/ocsigen/js_of_ocaml

- Merlin is also a fantastic autocompletion plugin for Vim/Emacs. https://github.com/the-lambda-church/merlin

VimBox (shameless plug) uses Merlin and is configured to provide "intellisense" style completion (as you type) like Visual Studio. https://github.com/jordwalke/VimBox

- utop is perhaps the best top level REPL that I've ever seen. https://github.com/diml/utop (edit: Regarding utop: Normally I dread using a REPL for a statically typed language, but utop actually makes the top level fun and interactive. I actually look forward to using it!)

tieTYT2• 12 years ago

What made me give up on Haskell was all the libraries had native linux bindings. It was hell reusing code if you're developing on windows (and I've heard this is true on macs, too). Does OCaml have this issue?

tedks• 12 years ago

Ocaml has a bytecode compiler and a native code compiler; any library written in OCaml can be compiled to run-anywhere bytecode, though I'm not sure how many libraries are really just wrappers around native GNU/Linux libraries.

yminsky9• 12 years ago

Unix support is definitely better than Windows. That said, the core language and base libraries are pretty portable. Here's one nice retrospective on a move from Python to OCaml for a program that needed portability to Windows as a fundamental concern.

http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

Probably the biggest problem on Windows is that OPAM, the package manager, doesn't work there. That will come eventually, though.

shadowfox• 12 years ago

Probably the biggest problem on Windows is that OPAM, the package manager, doesn't work there. That will come eventually, though

Wodi [1] is a reasonable choice until OPAM starts supporting Windows. It includes many of the interesting/useful libraries (including, importantly, batteries [2] and core [3])

[1] http://wodi.forge.ocamlcore.org/ [2] http://batteries.forge.ocamlcore.org/ [3] https://github.com/janestreet/core_kernel

pjmlp5• 12 years ago

Probably the biggest problem on Windows is that OPAM, the package manager, doesn't work there. That will come eventually, though.

Any ETA on it? If I knew about it before buying the book, I would not have done it.

The book is great, but as it is I have better luck with F# at work.

jeremyjh• 12 years ago

I think it really depends on the application domain. A lot of Haskell (for example most of the web frameworks) doesn't have the problem you mentioned - but GUIs and numerics systems probably do. I would guess the same may be true for OCaml. If I were developing on Windows though I would probably lean towards F# over OCaml though...Visual Studio is an amazing IDE.

tieTYT2• 12 years ago

I want the "write once, run anywhere" that Java gives me. I guess I'm just spoiled, but it's what I've come to expect.

gnuvince• 12 years ago

I recently picked up a project in OCaml that I had begun last summer and never finished. I have to say, compared to my day-to-day tools (mostly Java these days, Python before), OCaml is a breath of fresh air. For instance, today I did a refactoring where I replaced a type that was simply an alias to string with a proper abstract data type. Fixing the code was simply a matter of compiling, going to the file/line number in the error message, fix and repeat. Algebraic data types (sometimes called discriminated unions) are great for properly separating the logic of a data structure instead of sticking everything into one big class.

I highly recommend you give it a try. By the way, although we hear about OCaml less often than other languages, it is still used in many well known places such as Facebook (for pfff and Hack), Microsoft (SLAM, a verification tool for drivers), and Airbus (they use the ASTRÉE static verification tool which is written in OCaml).

brianberns• 12 years ago

Although we hear about OCaml less often than other languages, it is still used in many well known places such as ... Microsoft

Microsoft's F# language is essentially a .NET version of OCaml.

_pmf_2• 12 years ago

Microsoft's F# language is essentially a .NET version of OCaml.

Oh, how I wish there was a JVM variant of F# (no, Scala does not count).

simplify• 12 years ago

I considered picking up OCaml at one point, but got scared off by the global interpreter lock. Can an experienced OCaml dev tell me when this would really become an issue, and certain cases where it wouldn't make a difference?

yminsky9• 12 years ago

My experience has been building parallel and distributed programs using multiple runtime instances that communicate via message passing. There are libraries that help automate this, link our own Async_parallel (https://blogs.janestreet.com/async-parallel/). One advantage of this approach is that it scales beyond a single box.

There is work going on at OCaml Labs on a parallel runtime. I suspect it will be useful, but in the end, message passing is I think a better idiom than shared memory threads for parallel programming. When the true parallel runtime lands, I'm not sure that we'll actually use it much for running truly parallel threads.

lobster_johnson• 12 years ago

Does OCaml have anything resembling Erlang's OTP? Lightweight concurrent processes, easy to use remote processes, supervisor trees etc.?

mercurial2• 12 years ago

I suspect it will be useful, but in the end, message passing is I think a better idiom than shared memory threads for parallel programming.

It really depends on the problem you are working with. You wouldn't want to make a high-performance HTTP server this way. Especially if you get to copy 2MB of POST data every time.

yclept• 12 years ago

Python has the same thing right?

robert_nsu• 12 years ago

I've played with OCaml in the past, but I decided to get comfortable with F# then give OCaml another go.

jmgrosen• 12 years ago

I've often seen OCaml compared to F#; as someone who knows Haskell and Rust (among others), which is better to learn? I'm not really a Windows guy, which makes me think OCaml, but I've seen that Xamarin now works with F#, which is appealing to my inner app developer.

chadzawistowski• 12 years ago

F# is essentially OCaml.NET, so knowledge of either will be very transferable to the other. F# can interface with C# types, but it feels cumbersome at times. Idiomatic F# is very similar to idiomatic OCaml.

bsamuels• 12 years ago

I prefer F#, but only so because it has decent visual studio tooling and .net interop. F# power tools' refactoring is great, and its syntax coloring is very good as well. http://puu.sh/a1vM5/c735f3d319.png (i swear this looks a lot nicer on the washed out screen i program with)

The interop with .net libs is helpful too - but i've found that if there's anything that's really hurting F#, it's all the OOP tacked onto it to make the .net interop work. Decent tradeoff if you ask me, but it's cringeworthy to see people using F# like an oop language when the oop only appears to be there for the interop magic to work.

stonemetal• 12 years ago

Comparing OCaml and F# is about like comparing Java and C#. The MS languages started out very similar to the others, but made much larger strides. F# has changed their syntax to be lighter, with something similar to Haskell's offside rule. They added workflows which are monads but not quite as nice as Haskell's.

adultSwim• 12 years ago

My personal preference is OCaml.

One big point I would give to F# is tooling. Having a real IDE for OCaml would be nice. When I was writing OCaml I used Emacs with ocamlspotter.

The other big F# feature is library support. OCaml has pretty good libraries but F# can leverage the whole .NET framework. This would be noticeable in areas like GUIs.

I imagine that not using Microsoft F# would negate the benefits of F# over OCaml.

To be honest, go with either. For most people the benefits come from the simple/common/old features. Once you get used to dealing with the compiler, you'll likely fall in love with ML.

hackerboos• 12 years ago

We were given this by Dr Grant Malcolm when studying semantics in the University of Liverpool.

Although I didn't run off and learn OCaml at the time it did spark my interest in functional programming - eventually picking up Scala and Erlang.

rrss1122• 12 years ago

I tried OCaml once. It was to figure out the algorithm Yaron Minsky (author of linked article) used for his orbital simulator, Planets. I only learned enough to port the code over to JS, and quickly forgot it. Coming from a procedural programming background, the learning curve was too steep for OCaml.

Here is Minsky's Planet's project, by the way: http://planets.homedns.org/

ALee• 12 years ago

We're also using OCaml at Esper. Here's our implementation for folks who are interested in using functional programming lagnuages: http://stackoverflow.com/questions/19350590/designing-large-...

OCaml for the Masses (2011)

Related Stories