

OCamlPro and the future of OCaml - budu
http://ocaml.janestreet.com/?q=node/89

======
noelwelsh
A decade ago it looked like O'Caml was going to be the language that brought
FP to the masses. It had good runtime performance, good tools, and a decent
library. Then the development team basically did no work on the language for
some eight or so years, and other languages, notably Scala, F#, and Haskell,
have gained ground.

It is hard to cross from academia to commerce. The changes that were (and are)
needed to O'Caml are not things that will result in publications, and thus
don't fit the academic funding model. At the same time they are a precursor to
attracting wider interest in the language. It seems that a benefactor like
Jane Street is needed for this to occur. Certainly it seems that Jane Street
is eager to spend money to fix this problem.

The story of O'Caml is a good reminder that in language adoption, as in
business, execution, along with a bit of luck, what matters. The world is full
of could-have-beens. And on that note, I've got code to write...

~~~
rwmj
I'm writing OCaml just one hour ago. Out of all the languages I know (and I'm
very or reasonably proficient in many), it's still the easiest one.

------
ajshankar
The number one problem with commercial OCaml is the lack of comprehensive
library support. Until that's addressed, it's not going to take off. Brilliant
language, not very practical. F# is a step in the right direction here.

~~~
raphscallion
What about Jane Street's Core (<http://ocaml.janestreet.com/?q=node/13>), or
Batteries Included (<http://batteries.forge.ocamlcore.org/>) ?

~~~
Yoric
Go Batteries Included! (yes, I'm one of the developers, did that show? :))

------
rsaarelm
I wonder if there's any hope of ever getting type classes in OCaml. Then you'd
be able to have stuff like a single "print" function you can give any type of
value that can be turned into a string representation.

~~~
Yoric
Afaik (and according to Xavier Leroy), it's not planned in mainstream.

Now, implementation of typeclasses is pretty-well documented, so if anyone's
willing to finance OCamlPro on this, I don't think there's any technological
or scientific barrier.

------
mobileman
It would be interesting to know what they plan to do. It's easy to speculate
l. It would be much more interesting to see ocaml on the jvm

~~~
fhars
The JVM is quite a bad choice for languages like ocaml as it doesn't support
full tail call elimination, which is a fundamental aspect for the predominant
style of writing ocaml. So you would either have to simulate the ocaml stack
on the java heap (slow and will probably make ocaml/java interop ugly,
defeating the whole purpose of porting to the JVVM) or rewrite most of the
existing ocaml code in a ocaml-for-the-jvm style that is quite different from
normal ocaml style, taking into account which tail calls can be optimized and
which cannot. And if you decide to go down that road, you will not gain much
you cannot get by using scala right now, the only missing thing is camlp4.

~~~
melling
JVM tail recursion is done. It's available now and officially ships July 28th.

~~~
Yoric
IIRC, the next JVM will indeed offer a new operation that allows tail calls
(not exactly tailrec). However, this operation is incompatible with the Java
security model (what you're allowed to do depends on what's above you in the
stack -- this is used in many places in Java, in particular for anything
related to accessing the screen or the file system, or more generally anything
involving JNI) and with the Java exception model (exceptions contain the whole
stack). Therefore, the operation will not be used by Java itself, and there
are chances that using this operation in JVM languages without breaking
compatibility with the Java stdlib will take some work, at least for the
features that relate to security.

