6 ms·

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

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.

marktangotango 12y ago
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 12y ago
  > 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.
  - marktangotango 12y ago
    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 12y ago
      Ok, makes perfect sense !
  - avsm 12y ago
    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 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...
- pjmlp 12y ago
  I remember reading that book on my crossings over the tagus river in Lisbon, after we got introduced to Caml Light. Time flies!
larsberg 12y ago
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 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 http://www.cs.cmu.edu/~rwh/talks/mlw13.pdf
- bjz_ 12y ago
  That's certainly a pretty exciting presentation! Looks like a huge effort though... how much progress has there been since?
  - larsberg 12y ago
    We did the first part and very recently put http://www.sml-family.org/ 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 12y ago
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 12y ago
> 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 12y ago
  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 http://blog.camlcity.org/blog/multicore1.html [2] http://projects.camlcity.org/projects/dl/ocamlnet-4.0.0test2/doc/html-main/Intro.html#netmulticore http://projects.camlcity.org/projects/dl/ocamlnet-4.0.0test2... [3] https://ocaml.janestreet.com/ocaml-core/109.24.00/doc/parallel/Std.html https://ocaml.janestreet.com/ocaml-core/109.24.00/doc/parall...
- edwintorok 12y ago
  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.
adultSwim 12y ago
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).

marktangotango 12y ago

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 12y ago
> 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.
- marktangotango 12y ago
  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 12y ago
    Ok, makes perfect sense !
- avsm 12y ago
  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 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...
pjmlp 12y ago
I remember reading that book on my crossings over the tagus river in Lisbon, after we got introduced to Caml Light. Time flies!

larsberg 12y ago

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 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 http://www.cs.cmu.edu/~rwh/talks/mlw13.pdf

bjz_ 12y ago
That's certainly a pretty exciting presentation! Looks like a huge effort though... how much progress has there been since?
- larsberg 12y ago
  We did the first part and very recently put http://www.sml-family.org/ 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 12y ago

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 12y ago

> 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 12y ago
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 http://blog.camlcity.org/blog/multicore1.html [2] http://projects.camlcity.org/projects/dl/ocamlnet-4.0.0test2/doc/html-main/Intro.html#netmulticore http://projects.camlcity.org/projects/dl/ocamlnet-4.0.0test2... [3] https://ocaml.janestreet.com/ocaml-core/109.24.00/doc/parallel/Std.html https://ocaml.janestreet.com/ocaml-core/109.24.00/doc/parall...
edwintorok 12y ago
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.

adultSwim 12y ago

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