Comparing Standard ML and OCaml | Hacker News Reader

Comparing Standard ML and OCaml

adam.chlipala.net

86 pointsrohshall20 comments

Regarding build systems, ocamlbuild is included with the standard ocaml distribution and gives a high-level interface that is much simpler to use than ocamldep and friends. Especially when combined with findlib.

Yeah, this is really old. I remember seeing it six years ago when I started using OCaml.

Nothing said about multithreading and parallel processing? Seems like a big omission if you're comparing languages.

The reason is that neither OCaml nor SML support language-level parallelism or concurrency.

These features are /somewhat/ available as 3rd party libs (OCaml), but you won't see GHC or Erlang-style thread use.

there were some attempts to include multithreading into standard ml. john reppy's manticore project came quite far but wasn't fully implemented.

currently mythryl, a sml/nj derivative with c-flavored syntax, is about to get a full multithreading support. check out mythryl.org and the status updates on the mailing list.

The user group explicitly rejected multithreading at the OCaml Users conference a couple of years back. (There was a working implementation called oc4mc).

The reasons were that it will slow down single-threaded performance, and threads as a programming model is not robust (compared to, eg. forking, message passing, MPI etc). Also actual graphs of 4- and 8-way SMP performance showed pretty poor scaling for real problems, so the benefits aren't that great compared to going for full MPI, which you have to do for NUMA anyhow.

Also actual graphs of 4- and 8-way SMP performance showed pretty poor scaling for real problems

Do you mean for OCaml, or in general? Because lots of problems are amenable to 4 and 8 way threading on SMPs or multicores.

GHC has a compiler flag to enable multi threaded runtime. Why can't OCaml have that? It is a bit rigid to have to build two versions of a binary, but for folks who run their own code, no problem at all.

Sure, you can run OCaml and oc4mc. You'll also end up with two different binaries. oc4mc isn't as well tested, so I guess you'll hit more bugs. This still doesn't solve the horrible programming model [I've been cursing a multithreaded C program in the past few days. It's amazing how much stuff you have to remember and how much simply doesn't work in C when you've got threads]. Nor does it let your program scale past the limit of a single NUMA node. Whereas message passing a la Erlang lets you scale over NUMA and across machines and networks.

F# is practically OCaml, from my understanding. I don't know if it has all the same current .NET multithreading support under Mono. Worth looking into.

I have adopted it as my main scripting language when doing Windows projects. :)

What's a good F# tutorial/reference you've used?

See my article http://jackfoxy.com/a-course-of-fsharp-study/ I've got a bunch of references to F# tutorials, articles, and references. IMO the best tutorial is http://en.wikibooks.org/wiki/F_Sharp_Programming

I already knew Caml so it was easy to learn F# just by reading the MSDN articles and Channel 9 videos.

There is plenty of good stuff there.

http://msdn.microsoft.com/en-us/magazine/ee310108.aspx

http://channel9.msdn.com/Tags/fsharp

http://channel9.msdn.com/Tags/functional+programming

They really diverge when it comes to more advanced language features. I make heavy use of functors in my code and my (possibly mistaken) understanding is that F# simply doesn't support them. Ditto for first-class modules, polymorphic variants, GADTs, and OCaml's object system. Of course, in exchange for a wimpier core, F# gives you a lot of convenient polish and proper support for parallelism & concurrency.

My understanding is the same. I, like you, haven't followed F# since it diverged so much in development, but it's understandable that those features would be in-commensurable with how it interoperates with the .NET framework.

Mauricio Scheffer has written several articles about applicative functors in F# http://bugsquash.blogspot.com/search/label/applicative%20fun... To tell the truth I don't really get it, but maybe you do.

ML functors aren't the same thing as the functors or applicative functors I often blog about. Difference explained here: http://stackoverflow.com/questions/2030863/in-functional-pro... ML functors are like parameterized modules. F# doesn't have parameterized modules, but has parameterized classes, which work quite similarly. Classes/objects can also be used as first-class modules. What .NET lacks (therefore also F#) is type constructor abstraction, which means you can't generically express the concept of a (Haskell) functor, applicative functor, monad, etc.

this was Leroy's post in 2002 about multithreaded runtimes

http://web.archive.org/web/20110724004117/http://caml.inria....

Here are recent commentaries:

http://stackoverflow.com/questions/1302272/is-inria-going-to...

http://www.reddit.com/r/ocaml/comments/xxxn4/interesting_dev...

http://stackoverflow.com/questions/10705526/is-there-a-surve...

Urgh! I want to see Jocaml posts around here!

Reply on news.ycombinator.com