
Comparing OCaml and Standard ML - carloscm
http://adam.chlipala.net/mlcomp/
======
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/](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.

~~~
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.

~~~
edwintorok
Have a look at the 'Multicore OCaml' presentation here:
[https://ocaml.org/meetings/ocaml/2014/](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/](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...](http://flyingfrogblog.blogspot.co.uk/2010/01/naive-parallelism-
with-hlvm.html)

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?

------
a0
ML's syntax is indeed less confusing than OCaml's. And that's the reason I'm
working on a compiler front-end replacement for OCaml inspired by Clojure,
Haskell, Ruby and Julia. It will be for OCaml what Elixir is for Erlang. I'm
finishing the parser right now and will next implement the language primitives
as a library in the language itself.

~~~
mercurial
I'm curious about what you find particularly confusing about OCaml. I'm a
(relative) newcomer to the language, but I find it extremely readable, even if
it's a bit clunky at times.

~~~
tomp
What does this code do?

    
    
      if a > 0 then
        print_endline "a > 0" ;
        match a with
          | 0 -> print_endline "impossible"
          | 2 ->
            match b with
              | 0 -> print_endline "2, 0"
              | _ -> print_endline "2, not 0"
          | 3 -> print_endline "3, something"
          | _ -> print_endline "something, something"
      ;
      print_endline "done"

~~~
tel
As someone without too much OCaml experience, how do you disambiguate this?

~~~
tomp
1) Ignore indentation (I intentionally wrote it to deceive, but similar
examples could easily appear in real code). 2) `match` cases always bind to
the innermost `match` statement. 3) Statement separators (`;`) are tricky.

The correct indentation of the above code is:

    
    
      if a > 0 then
        print_endline "a > 0" ;
      match a with
        | 0 -> print_endline "impossible"
        | 2 ->
          match b with
            | 0 -> print_endline "2, 0"
            | _ -> print_endline "2, not 0"
            | 3 -> print_endline "3, something"
            | _ -> print_endline "something, something"
                ;
                print_endline "done"
    

To have the same meaning as the indentation implies, you would need to add
`(...)` or `begin ... end` at the appropriate places.

~~~
mercurial
What would be the corresponding SML? I see how the way SML binds ';' would
help here, but would it change anything about the last two badly indented
matching? And it seems to provide you with the equivalent footgun if you
attempt to do multiple side-effect operations in a match branch, which in my
experience you want to do more often than you need to separate matches with
';'.

------
p4bl0
Small update: recent versions of OCaml have immutable strings too.

It also miss mention of package manager (OCaml has Opam, which is awesome, I
don't know about SML).

And ocamlbuild is missing from the build tools section.

~~~
yodsanklai
Out of curiosity, why do you think Opam is awesome? I recently had to install
a few OCaml projects and I had a hard time dealing with opam and ocamlfind
(both on mac os and a linux VM). I suppose it's fine once everything is
properly set up.

I have the impression that the OCaml world has seen a lot of changes recently
with a lot of complexity added.

~~~
amirmc
> _I have the impression that the OCaml world has seen a lot of changes
> recently with a lot of complexity added._

The first part of that is very true but the second part feels completely and
utterly false to me. Where is this added complexity?

OCaml and OPAM were ridiculously trivial to set up on my system (via homebrew
on a Mac) and OPAM 1.2, with many improvements, is due for release in the next
few days [1]. Decent instructions are in the RWO wiki page [2]. The OPAM devs
are responsive to bug reports and do a lot to maintain the health of the
package ecosystem too.

If you're installing everything from sources then you're choosing to take on
that burden and I wish you well but don't claim that more complexity is being
added.

[1] beta announcement:
[https://opam.ocaml.org/blog/opam-1-2-0-beta4/](https://opam.ocaml.org/blog/opam-1-2-0-beta4/)

[2] [https://github.com/realworldocaml/book/wiki/Installation-
Ins...](https://github.com/realworldocaml/book/wiki/Installation-Instructions)

~~~
yodsanklai
> The first part of that is very true but the second part feels completely and
> utterly false to me. Where is this added complexity?

Recently, I tried to install a few ocaml projects. I had to learn what are
Opam, OCamlfind, Batteries, Core... And unfortunately, it didn't work on my
particular mac with homebrew. I had to use alternative ways of installing
everything.

If you look at the installation procedure:
[https://ocaml.org/docs/install.html](https://ocaml.org/docs/install.html) It
may be rather complex depending on the platform, and if it doesn't work from
the start, you have to dig deeply in this whole new ecosystem.

An other example. I was trying to install a project that compiles only using
ocamlfind. Unfortunately, one of the libraries used wasn't available with Opam
and I had to find it elsewhere and write myself the ocamlfind meta
information.

So yes, to me, a lot of complexity was added. There are many new tools that
you have to learn, a few standard libraries (I still don't know which one to
use as a casual developer).

It's probably much powerful and it works well most of the time, but it's more
complex than 10 years ago.

~~~
amirmc
Nope, none of what you describe equates to 'complexity', there just happens to
be more 'stuff' (unless you consider other, more popular languages with even
more tools/libraries to be even _more_ complex, in which case we have
different viewpoints on what that word means in this context).

Sure, not everything is in opam and that can be quite frustrating but the
improvements over the last few years have done a lot to _reduce_ the pain that
people experience (not increase it). Seriously, would you rather have the
_old_ ecosystem back? I know a large number of devs who would be quite hostile
to that idea.

The standard library question isn't new and has been going on for some time
but the options now are substantially better then they ever have been. Ask
around and get feedback from others on what might suit your needs best. Until
the community naturally converges on something, this is just how it is.

> _" And unfortunately, it didn't work on my particular mac with homebrew."_

So what went wrong? The instructions for homebrew are _two_ lines and my
experience here was flawless. The slew of instructions you point at are
largely for Linux distros and most of those are also only a few lines. Were
you trying any of these? It's clear that the install page you point to needs
work (who still uses fink?) but in most cases it's just a time-consuming
process, rather than a difficult one (i.e you just sit there while things
compile). If something goes wrong, then reporting it on the list [1] or issue
tracker [2] will help others to fix it.

[1] [https://sympa.inria.fr/sympa/arc/caml-
list](https://sympa.inria.fr/sympa/arc/caml-list)

[2]
[https://github.com/ocaml/ocaml.org/issues](https://github.com/ocaml/ocaml.org/issues)

------
CmonDev
Wow, ML syntax is actually better than OCaml. It's a shame the former was used
as a base for F#.

~~~
profquail
One thing I think F# got right is that it removed some of the "flexibility" in
OCaml's syntax. For example, it uses significant whitespace to define scoping,
which removed (in _nearly_ all cases) the need for the 'in' keyword and lots
of parentheses and semicolons. That may not sound like a huge deal, but it
does greatly improve the readability of F# code (all other things being
equal).

~~~
jdh30
> One thing I think F# got right is that it removed some of the "flexibility"
> in OCaml's syntax. For example, it uses significant whitespace to define
> scoping, which removed (in nearly all cases) the need for the 'in' keyword
> and lots of parentheses and semicolons. That may not sound like a huge deal,
> but it does greatly improve the readability of F# code (all other things
> being equal).

I must disagree. I once translated a significant (15kLOC) commercial OCaml
code base into F# and took the opportunity to quantify the syntactic benefits
as <3% by volume of code. The flipside is that F# misinterprets code pasted
from the web, rendering most code on the web useless. That is a crippling
deficiency of F# in my eyes and a major reason to go back to the superior
OCaml solution.

------
gnud
I really enjoy working with SML (I've used sml/nj and parrotml) - and would
love to use it for "real" projects, but until it actually has decent unicode
support, there's just no way I can.

------
zvrba
Ocaml: the practical and the ugly one. (I hate Ocaml's syntax mainly due to
the noise of let ... in clauses)

------
Altenuvian
including mythryl, a sml/nj derivative with c-flavored syntax to the
comparison would be interesting. see
[http://mythryl.org/](http://mythryl.org/) for further info.

~~~
Altenuvian
ups - copy and paste error - this should have read: it would be interesting to
include Mythryl to the comparison.

------
agumonkey
Sml syntax is indeed very nice, and emacs sml-mode is pretty strong too. A
great joy to use, almost as good as paredit.

