OCaml's 20th Anniversary | Hacker News Reader

OCaml's 20th Anniversary

sympa.inria.fr

166 pointsamirmc34 comments

Congratulations to my friends Xavier Leroy and Damien Doligez, as well as to all the other contributors to OCaml.

For those interested in learning OCaml from a MOOC, there is one starting soon (next month). You can already register here: https://www.france-universite-numerique-mooc.fr/courses/pari...

Note: the MOOC is delivered on a French MOOC platform but will be in english.

Just in case, there's also a MOOC held by C.Queinnec (Author of Lisp in small pieces):

http://programmation-recursive.net/

Warning: seems like this one is in french though, so only if you're curious enough about it.

I got really excited reading the 1995 email as an announcement that INRIA was releasing a new SML-based language. The association I can't get out of my head is: SML is to C as OCaml is to C++. This is backed (to some degree) even in this email:

  > ... in 20 years, the language picked up many language
  features that were open research problems in 1995, such as objects and
  classes with type inference, polymorphic variants, first-class polymorphism,
  and first-class modules.

SML is a much simpler language and I think a solid SML kernel with a good (read: modern, web-friendly) standard library targeting LLVM or the JVM could be a real winner for commercial use.

> SML is to C as OCaml is to C++

In what way though? The amount of concepts and gotchas you have to understand to be proficient at OCaml is nothing compared to C++ in my opinion. I've used SML as well and didn't find it hugely different from OCaml unlike when I went from C to C++.

I agree. OCaml is really cool in many respects, and I like it a lot—but the only thing SML really needs is a modern Basis library that is applicable to today's standard use-cases.

I use SML for the JonPRL proof assistant, and I couldn't be happier. Some things would be a bit easier in OCaml, but to be honest, I love the fact that my code will continue to work without modification for decades, due to the simple fact that SML is a language frozen in time.

> due to the simple fact that SML is a language frozen in time

Unfreeze it, all the extant MLs fall short in one way or another. A modern SML with none of the syntactic cruft of OCaml; the lazy evaluation of Haskell and its non-existent module system; the nutured nature of F# ... that would be ML joy, maybe Rosenberg's 1ML will make that a reality.

We're in the middle ages of computer science language-wise.

Heck, even use HaMLet to bootstrap it.

Hamlet is a portable SML implementation written in SML.

http://www.mpi-sws.org/~rossberg/hamlet/

(Not unlike SICL, which is a portable Common Lisp for R&D https://github.com/robert-strandh/SICL)

I agree that each ML falls short in some ways--I think SML and OCaml are probably the best programming languages ever made, but there's definitely room for improvement. I dream of the "Next Great ML"; 1ML definitely looks interesting in this regard, though I am a bit skeptical of Rossberg's rhetoric on a number of issues.

I use SML over OCaml mostly for cultural & political reasons; SML has a few areas ripe for improvement (some of which are addressed in OCaml, others not):

1. structure sharing in the Definition is so bad that pretty much all the implementations of "S"ML diverge from it in some way. Each implementation of structure sharing is frustrating in its own way.

2. would be nice to be able to do higher-kinded polymorphism, as in 1ML

3. would be nice to unify polymorphism as a mere mode-of-use of functors, as in 1ML (well, this was not invented in 1ML, as I first saw it in Dreyer/Harper/Chakravarty's "Modular Type Classes": http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf; it may go back as far as the Harper-Stone type theoretic semantics). Combined with higher-order functors (which I believe are proposed to be added to "Successor ML"), this would give a proper treatment to polymorphism at higher kinds.

4. we need to standardize on a package calculus; the ML Basis system as used in Mlton is pretty nice, as is the simpler system used in SML/NJ's "Compilation Manager".

5. modular type classes (analogous to coq's "canonical structures") should be added in order to alleviate the pain of explicitly instantiating functors, etc. We do NOT want "type class coherence" as in Haskell, which amounts to a piece of global state that essentially outlaws local reasoning. I call it the "Antimodularity Restriction", but the name hasn't caught on, as much as Haskell folks like to berate us over our "value restriction" (which is a non-problem, and very useful--though it would be better to reconstruct it in a less ad-hoc way, via the theory of polarization that comes from Girard, and was further developed in light of effects, refinements and polymorphism by Zeilberger in his dissertation).

6. I'd like to (at least) follow OCaml and add the ability to convert between module signatures & existential types; I'm not sure if I am sold on the 1ML approach, which goes quite a bit further than this, but I need to investigate it more.

7. Refinement types would be nice (but PLEASE---do not fix in advance some awful solver or something for this; contra the popular literature at the moment refinement types have NOTHING at all to do with solvers!).

What is a good SML implementation that creates compact binaries that are easy to deploy? (One of OCaml's strength is the compiler that produces native code binaries that don't depend on tons of runtime libraries or other files.)

Mlton? Or is that just an optimizing compiler?

Or you could do the same thing with Ocaml while just using a subset of its features.

Are you trying to prove the C++ analogy? http://stackoverflow.com/questions/3073642/official-c-langua...

A while back, I had to decide which of SML or Ocaml I'd recommend to people interested. I looked up comparisons hopefully from talented developers. Found this one by Chlipala:

http://adam.chlipala.net/mlcomp/

A C and C++ analogy doesn't make sense unless you really cherry-picking. A better analogy would be Wirth's original Pascal for classrooms vs Borland's Turbo Pascal (or Free Pascal): one is designed to get stuff done with syntax and semantic features that make a lot more sense. You can use Ocaml in a style that gets you much benefits of ML. Even Coq extracts to a minimal Ocaml. Or, you can go Jane St with it developing real-world applications with excellent properties that neither SML nor C++ would have in current state.

Talking like Ocaml is ML's C++ is an insult to them. C++ is garbage built on worse garbage to make the landfill smell less. You'll find plenty of C++ developers admitting they only use it because they have to for whatever reason. You don't see that with Ocaml: good design, tools, and community are driving much growth and happy developers. So, it's more "Ocaml: ML Go's Pro" rather than "C++: Bend Over, Here it Comes Again." ;)

I'd characterize OCaml's tools as a mixture of best-of-breed (Merlin, OPAM) and oh-my-god (build tools, debugger). The language itself, if you avert your eyes from the standard library, is pretty damn good though.

That matches the view others have shared with me. A few of them mentioned that Jane St re-wrote the standard library to try to fix that problem. They also gave it back to the community. Have you tried theirs? If not, take a look at it so you can tell us if you think they've gotten past that weakness.

https://janestreet.github.io/

There are least three competing standard libraries: Jane Street's Core (high-quality but fairly big, also generates large binaries due to OCaml's lack of good dead code elimination support), Batteries (older, developed by the community), and Containers (Simon Cruanes' project, mostly - smaller but very well-designed).

They all have their advantages, the issue is that there is no one true alternative standard library, which makes the life of library writers difficult (especially when you want to use a type in your interface that is only present in one of these libraries).

I see the problem. Wouldn't this happen if SML was industrialized to any degree by different players?

Back to Ocaml, what would your proposal be to deal with this aside from adding dead code elimination for Core? That would be my first strategy because Ocaml needs it anyway.

I think it's difficult to tell people to jettison their stdlib dependencies by now (I think OPAM reverse dependencies are about 50/50 between Core and Batteries).

What I'd like to see is at least common data structures for useful things (like time) in the standard stdlib, and hooks for nice things like gen/seq (other high-qualities-but-very-lightweight libraries from the author of Containers).

It might be difficult but it needs a strong, standard lib. I can't remember that many languages that really made it with several competing libraries for the basics. Could go Common LISP approach and do an integration but that would probably be similarly ugly.

A LCD approach with stuff like you suggested might work. Maybe source-to-source translation from one to the other. (shrugs) Still think fragmentation might hold them back.

I think Rossberg's (author of 1ML) comparison[0] might be more appropriate because it doesn't make assumptions about what is better or worse in a language - whereas Chlipala's comparison makes a lot of assumptions. I personally don't think a lot of the assumptions he makes are valid especially when languages that are still "popular" and in-use today (C, Go) have features that he would seem to call "academic" rather than professional.

My point being, it's not that simple. Though I will grant that the libraries and existence(!) of an OCaml community is good reason to select OCaml over SML.

[0] https://www.mpi-sws.org/~rossberg/sml-vs-ocaml.html

That is a more thorough comparison. Makes deciding the victor a bit more difficult at language level except to say that there's more similarities than differences. As you said, libraries and community are main deciding point for me if I have to recommend a ML.

However, I do like that ML has a certifying compiler (FLINT). Love to see one for Ocaml for use in critical tools. The Esterel SCADE code generator, done in Ocaml, was manually verified to object code. That and FLINT make me hope it can be done with reasonable effort with Ocaml.

As someone who writes fairly SML-ish OCaml, there definitely are benefits to using OCaml (even if only for the library and tool support... opam really is pretty awesome) over SML. I rarely end up even using the object system and other features that SML lacks, but I find the syntax a bit nicer to read and write. And unlike C++, the standard library doesn't force all the bloat you don't want to deal with on to you, so it's no big deal to write code in SML style.

There is a small difference though: Using those various OCaml features is not going to instantly kill you.

With the deprecated features of C++, I'm not so sure.

Well, of course. The whole of ocaml is still a smaller language than anybody's recommended 20% subset of C++.

Way more power/features with the detailed description of those + library + tools + more = 588 pages. C++ programming language 3rd edition is 1,000+ pages. So, not quite that ratio but clearly one has better signal-to-noise ratio and design than the other. ;)

i upvoted on the theory that that was deliberate :) the internet needs more understated hunour

Sorry to disappoint. Agree the Internet needs more of that. Makes it funnier when people don't get it, start a tangent, and get called on it in an epic way haha.

One of the biggest problems now is the lack of the Windows support for Opam[1].

I hope that will be solved in the near future. Because currently Microsoft trying to take the niche with their F#.

[1] https://github.com/ocaml/opam/issues/246

I know Clojure, looking to learn a statically typed functional language. Narrowed it down to Haskell and OCaml (are there others I should know about?).

I still am unsure what OCaml is good for. Ex., Ruby is good for webdev with Rails, Python is good as a general purpose language, Clojure is good for async and quick iteration/integrating with Java code, C is good for OS work, C++ is good for native applications.

Is OCaml general purpose? Can I use it for NLP? Statistics? Numpy-like n-d array math? Writing a compiler?

OCaml is super general purpose. You can write low-ish level code (there have been 2 kernels partially written in it) as well as higher level stuff (web servers/scripts on the pages using tools like js_of_ocaml, Coq, etc.). Where it really stands out it compilers and static analyzers (+ other similar things). Facebook uses it for a few of their compilers and static analyzers, the Rust compiler was originally written in OCaml before being ported to Rust, the Haxe compiler and VM are in OCaml as well. The OCaml compiler comes with lexer and parser generators and a lot of other libraries exist for it too (such as an official LLVM binding). I'm not sure how great it is for NLP, but I'd assume it's not bad for it. Here is a list of companies that use it: https://ocaml.org/learn/companies.html.

Not currently an OCaml user, but it's definitely general-purpose.

I don't think OCaml fits into a specific broad niche, although one of the areas where it sees more use is in computer language development/research. A whole bunch of compilers are implemented in OCaml (Hack and Flow by Facebook, for example), and then there are tools like Coq, and some static analysis tools (Flow is one, I guess) are also in OCaml.

What I think you'll find is that the standard library is quite lacking, as is the availability of third-party libraries. The ecosystem is nowhere close to what it is for languages like Node.js, Ruby — or even Haskell.

I can't think of a better language to complement Clojure than OCaml. It hits all of Clojure's weak points dead-on, and its own weak points are covered really well by Clojure.

In terms of "general purpose", I think of Clojure as being a better choice for long-running server processes and OCaml as being a better fit for code you run on your own machine or programs that don't stay running forever, due to the varying memory/performance/concurrency characteristics of their respective runtimes.

I wrote in more detail about my experiences coming from Clojure to OCaml here: http://technomancy.us/170 I found it very easy to pick up with some FP background. Not having to think about nil in particular was a huge breath of air after Clojure. I also had good luck accepting contributions from others with a Clojure background who wanted to make some changes to my code and learned OCaml just for that.

OCaml is super-practical for writing simple command line tools. It interfaces easily with C and compiles to binaries with no dependencies. See: all the tools written in OCaml here: https://github.com/libguestfs/libguestfs

I got into OCaml because I wanted something that was like Python but with strong typing. Type inference is amazingly productive once you get into it - very nearly to the level of, if you program even compiles, it will probably work first time.

Reply on news.ycombinator.com