[sgeisenh]

Purity is almost used in a pejorative sense throughout the page.

If it wasn't for poor library support, I would prefer using SML to OCaml. SML is syntactically simpler and both SML/NJ and MLton have a lot to offer that I haven't yet found with OCaml.

I think one of the biggest mistakes in the life cycle of SML was premature specification. As a result of the language definition, SML has stagnated for almost 20 years. There is now some notion of "Successor ML" (see: http://sml-family.org/), but I honestly don't see it catching on outside of an academic space.

As an academic language, SML is great. It is a great tool for learning functional programming since the learning curve isn't especially steep. It is easy to reason about performance since evaluation order is explicit. And immutability is the default but with mutable types that are easy to use.

[larsberg]

I agree completely with your library statements.

> I think one of the biggest mistakes in the life cycle of SML was premature specification.

I disagree. There were some earlier Successor ML efforts ~10 years ago (see: http://successor-ml.org/index.php?title=Main_Page ), but as I understand it, there was agreement on many of the small issues but larger challenges reaching consensus on bigger changes. You can see some notes from Bob Harper at the ML Workshop in 2013 on how we're moving forward currently:

http://www.cs.cmu.edu/~rwh/talks/mlw13.pdf

[bjz_]

That's certainly a pretty exciting presentation! Looks like a huge effort though... how much progress has there been since?

[larsberg]

We did the first part and very recently put http://www.sml-family.org/ online and announced the opening of the definition (whew!).

I'm primarily concerned with the parallelism and concurrency-related features, which we're trying to first clean up a bit more in the context of Manticore before trying to do something like proposing standardization for those features.

Also (IMO) you should take those slides more as a research direction for years of research investigating alternatives that eventually get standardized, not a 2015 implementation plan :-) Each of those topics casually mentions non-trivial extensions to problems that already have each had researcher-decades of investigation.

[ajb]

Given the goal of implementing proof systems, whose semantics you obviously need to be really clear, I don't think that specification was premature. But you're right that it has inhibited the use of the language in a more general setting.

[jdh30]

> SML has stagnated for almost 20 years

I'm still waiting for OCaml to get decent multicore support, decent Windows support and an FFI that doesn't suck donkey brains through a straw (which is why so many OCaml libraries, like OpenGL bindings, suck beyond belief). Multicore became ubiquitous 10 years ago. Last I looked the vestigial OCaml community still hadn't noticed.

[adultSwim]

The netmulticore library [1,2] worked well for me. The style there is to spawn worker processes and pass messages between them. I'm not sure how popular that library got but that style of programming seems to be pretty popular among OCaml users who need it. Many projects use something lighter-weight or just roll their own (e.g. Parallel in Jane Street's ocaml-core looks pretty good [3]).

I certainly wouldn't mind if you could swap out the garbage collector (a la Java - where you can choose between a fast serial garbage collector and a parallel garbage collector). However, I don't think it's the right tool for many tasks.

[1] http://blog.camlcity.org/blog/multicore1.html

[2] http://projects.camlcity.org/projects/dl/ocamlnet-4.0.0test2...

[3] https://ocaml.janestreet.com/ocaml-core/109.24.00/doc/parall...

[edwintorok]

Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/

TBH I don't miss multithreading in OCaml, if you write applications which expose some sort of API over a socket that will scale to clusters, not just multicore. And you can program those kinds of applications quite nicely with Lwt or Async already.

Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C library at runtime using pure OCaml (and a wrapper around libffi), or to generate C stubs.

Regarding OpenGL there is a new binding called 'tgls' for OpenGL 3.x/4.x (besides LablGL) that is mostly generated from the XML description of the OpenGL APIs.

Regarding Windows support I can't say much because I don't use it at all, but there was a new 'Self-containted OCaml distribution for Windows' called ocpwin-distrib posted to the ML recently. If you care about Windows support you should probably give them feedback on what is missing.

[jdh30]

> Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/

I just watched it. Great to see somebody else trying but this is no more advanced than OC4MC and they are using Fibonacci as an example when I already used a complete parallel ray tracer with shared memory when benchmarking parallelised HLVM code:

http://flyingfrogblog.blogspot.co.uk/2010/01/naive-paralleli...

They've got a lot of catching up to do before they can overtake and I'm concerned that retrofitting a modern GC on a 20th century VM will never work because OCaml has such poor locality of reference due to massive unnecessary boxing.

> TBH I don't miss multithreading in OCaml,

I said multicore, not multithreading. I dot lots of concurrency and parallelism in F# without having to worry about multithreading.

> if you write applications which expose some sort of API over a socket that will scale to clusters not just multicore.

You're proposing deep copying all of your data structures when multicore programming is all about sharing data between cores using shared caches. If you copy then your identical copies of the data compete for space in a shared cache.

> And you can program those kinds of applications quite nicely with Lwt or Async already.

Lwt and Async are for concurrent programming. In particular, they are extremely slow.

> Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C library at runtime using pure OCaml (and a wrapper around libffi), or to generate C stubs.

Ctypes looks great. Didn't exist when I last used OCaml.

> Regarding OpenGL there is a new binding called 'tgls' for OpenGL 3.x/4.x (besides LablGL) that is mostly generated from the XML description of the OpenGL APIs.

Has anyone tried to write anything much using it?

[shadowfox]

Side note on Windows distributions: Besides ocpwin-distrib there is also Wodi [1] which started as a port of Godi and is fairly stable on windows.

[1] http://wodi.forge.ocamlcore.org/

[imanaccount247]

>if you write applications which expose some sort of API over a socket that will scale to clusters, not just multicore

And it will be way slower for all those use cases where I don't need to scale to clusters. Or where it won't actually scale to clusters because I need shared memory, the latency to ask another node is simply too high. I had to move to haskell specifically because of ocaml's "who cares about multicore" stance.

[marktangotango]

I really liked SML and wanted to use it in anger after reading "ML for the working programmer" and "Purely functional data structures" (excellent functional programming books by the way) but just couldn't due to the lack of libraries as you say. For me the object system on Ocaml was just too much. Tis a pity.

[Raphael_Amiard]

> For me the object system on Ocaml was just too much

What do you mean by that ? The current consensus about the object system in OCaml is "don't use it", even if there might be cases where it will describe your system better.

The standard library (both the real stdlib and Jane Street's Core library) don't use objects so you can pretty much ignore this part of the language if you want to.

[avsm]

There's nothing wrong with objects or classes in OCaml -- it's just that most problems can be expressed using a simplest abstraction technique such as modules. OCaml has steadily improved in every recent release to further reduce the set of problems that need objects (open types, GADTs, first class modules, destructive substitution in module types).

For problems where objects and classes are a good fit (e.g. something requiring open recursion), then OCaml objects are fine and sound. They are used quite nicely in CIL for implementing the visitor pattern, and I like them in the Lablgtk OCaml bindings as well. They also provide a nice bridge to foreign code in OCamlJava and js_of_ocaml when compiling to platforms that make more use of objects.

It's worth noting that class types and object types are distinct in OCaml, so you can often use objects without involving classes at all. This is explained in Real World OCaml: https://realworldocaml.org/v1/en/html/objects.html

Not using OCaml because it possesses an optional object and class extension is a little strange. It never really gets in the way...

[marktangotango]

Since that is the 'current consensus' as you say, it seems like the ocaml community converged on the opinion I formed 10 years ago. But it wasn't necessarily the consensus then.

[Raphael_Amiard]

Ok, makes perfect sense !

[pjmlp]

I remember reading that book on my crossings over the tagus river in Lisbon, after we got introduced to Caml Light.

Time flies!

[adultSwim]

I would note that several SML extensions were made by adding on to existing compilers (e.g. Concurrent ML). The Haskell community has used this model to great effect (testing/refining new features as add-ons to existing compilers and then moving some of them into the main language).

Any ML would be good. The basic features of the language are the best. "Vanilla" ML would suit most people's needs (preferable replacement to many popular languages).