Live data from Hacker News

OCamlPro and the future of OCaml

ocaml.janestreet.com

11–20 of 24 posts

Re: OCamlPro and the future of OCaml

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

Re: OCamlPro and the future of OCaml

#12

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.

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

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

Re: OCamlPro and the future of OCaml

#13
post #9

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.

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.

Re: OCamlPro and the future of OCaml

#14
post #5

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.

While F# is a great language, its main problem is that it is basically MS only. At the current stage of development mono lags behind official MS .net implementation too much in terms of performance/stability/features.

Also, last time I checked only some parts of what mono implements are covered by the Microsoft Community Promise (i.e. promise not to sue you over it.) If there's anything new on this front, please share.

Re: OCamlPro and the future of OCaml

#16

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.

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

The last time I tried installing Batteries (on OS X) it was a big PITA and it looked like it was dead in the water (this was about 18 months ago).

During the same time using GODI to install a xml processing library completely hosed my system after me foolishly granting it root rights, which killed my OCaml enthusiasm for good.

OCaml is in itself a really nice language (apart from some warts like lack of native multithreading support) but it's tooling, infrastructure and "first developer experience" and lack of progress in these areas in the last years is beyond atrocious (compared to F#, Scala, Clojure, Haskell, Ruby, Python, JavaScript).

Re: OCamlPro and the future of OCaml

#17
post #9

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.

Type classes or module implicits, that would be great.

Re: OCamlPro and the future of OCaml

#18
post #8

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

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…

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

Re: OCamlPro and the future of OCaml

#19

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'Ca…

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.

Re: OCamlPro and the future of OCaml

#20

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'Ca…

OCaml is not Irish.
Post reply on HN