
The Future of Standard ML (2013) [pdf] - virtualwhys
https://www.cs.cmu.edu/~rwh/talks/mlw13.pdf
======
eatonphil
Cutting to the chase: use Haskell or Scala or F# if you need to do some
scripting or build a web application that requires lots of different tasks
(being a web server, rendering templates, connecting to a database, etc.).
Haskell and Scala have great libraries and polymorphism that allows you to
express things succinctly. Dunno much about F# except .NET.

Use OCaml if you want easily native binaries, predictable performance and need
very little in the way of well-documented, high-quality third-party libraries.

Use Standard ML if you want to learn OCaml/Haskell/F#/Scala. Why? Ultimately
it comes down to usability. First off, operators (not named functions) are to
programming languages as icon-only buttons are to web pages; they are
completely unusable. The only reason Standard ML avoided the plague of the
operators is because it's a simpler language that was used less. Second, since
it's a simpler language, you get a much cleaner introduction to things like
monads and modules. It makes it very simple to jump into more complex
languages like Haskell or OCaml or Scala.

I work on Ponyo [0] because I want to allow people (myself) to program at a
high-level in Standard ML. Furthermore, I want to promote quality and
usability. Basically, every function's type is annotated and we avoid abusing
operators. The current state is such that you can parse CLI args,
parse/marshal JSON, serve web pages, make http requests, browse file trees,
and many other ideas in the works. But the most important part about Ponyo is
that it is a large, (hopefully) well-documented project that others can study
to learn Standard ML (and Haskell and Scala and OCaml and F#) better.

Scala, Haskell, F#, OCaml have their place and do their jobs well. If you
don't know their place or just want to get exposure to the history behind
these modern languages, I recommend giving Standard ML a shot. You can get
started by reading the /r/sml wiki [1] or joining #sml on Freenode.

[0] [https://github.com/eatonphil/ponyo](https://github.com/eatonphil/ponyo)

[1]
[https://www.reddit.com/r/sml/wiki/index](https://www.reddit.com/r/sml/wiki/index)

~~~
virtualwhys
Coming from Scala I'd like to see successor ML become a reality. Whether it's
1ML, Ponyo, Ur (without the /Web), or another ML derivative that's not OCaml
(petty, but the crufty syntax makes Scala seem elegant in this regard) isn't
all that important.

As it stands every year Rossberg publishes a paper on latest 1ML enhancements;
Harper does the same wrt to PLT, and by proxy SML. Meanwhile, nothing's really
happening AFAICT in terms of the ML torch really being taken up and carried
forward (beyond OCaml and Haskell).

Perhaps a charitable donation from an SV unicorn founder or two, corporate
backing of some form, or academic backing similar to EPFL for Scala could
really get the ball rolling.

Moving forward we've got OCaml and upcoming modular implicits; Haskell and the
new module system, Backpack; and Scala's transition to Dotty -- basically a
lot to look forward to, but would love to see SML in the mix, such a beautiful
language...

~~~
cwyers
I find it interesting that you list all of the ML derivatives except the
popular one.

~~~
hroman
Poly/ML?

~~~
cwyers
No.

I mean, I know Tiobe isn't great, but the only ML-derivative I see on the top
50 is F#. ML and OCaml crack the top 100.

~~~
groovy2shoes
F# is an OCaml derivative. I'd reckon that OP's feelings about F# would be
rather similar to their feelings about OCaml.

~~~
cwyers
The only objection to OCaml is "the crufty syntax," which I think F# has taken
steps to improve upon.

~~~
sixbrx
But F# didn't bring along the beautiful module system from the MLs, nor does
it have type classes. Polymorphism there is basically just the OO + generics
variety found in C#. That can rub some people (like me) the wrong way.

~~~
ZenoArrow
F# does have type classes, they're just called interfaces.

[https://msdn.microsoft.com/en-
us/visualfsharpdocs/conceptual...](https://msdn.microsoft.com/en-
us/visualfsharpdocs/conceptual/interfaces-%5Bfsharp%5D)

~~~
lkitching
Type classes are quite different from interfaces. How would you encode the Eq
typeclass in F#? .Net has the IEqualityComparer<T> interface but you need to
manually pass that around (unlike Eq instances) and you also lose the global
uniqueness property.

~~~
ZenoArrow
You don't have to rely on the built in interfaces provided by .NET, you can
create your own. Just like in Haskell in F# you can use pattern matching
against types to define which of the equality operators to use.

Also, I'm not sure what you mean by "manually pass that around". When you
define a class in Haskell that inherits from a typeclass you reference that
typeclass in the header of the new class. You follow the same approach in F#
with interfaces.

~~~
lkitching
By 'pass around', I mean pass around instances, not definitions. You could
define your own Eq interface in F#

    
    
      type IEq<'a> =
        abstract member eq: 'a -> 'a -> bool
    

but you then need to explicitly pass instances of this interface around into
every method that requires it e.g.

    
    
      let allEq (s: 'a seq) (eq: IEq<'a>) = ...
    

whereas the haskell version would receive the Eq instance for the input type
implicitly.

Typeclass instances are globally unique for each type, which cannot be
enforced with the interface solution. If you have an ordered map type, you can
be sure the Ord instance used for insertion is the same that is used for
retrieval. With the interface approach, clients cannot know which instance to
use since there could be multiple implementations. The Haskell approach has
its own problems, such as the proliferation of newtype wrappers to manage the
dispatch mechanism.

Interfaces also hide the representation of one of their arguments (the
receiver) whereas typeclasses are just a dictionary of functions.

~~~
ZenoArrow
I'm not sure I understand all of what you've said, as I'm not familiar with
Haskell, but there are at least some Haskell programmers have recognised the
similarities between type classes and interfaces. Do you disagree with any of
the following?

[https://wiki.haskell.org/OOP_vs_type_classes#Type_classes_ar...](https://wiki.haskell.org/OOP_vs_type_classes#Type_classes_are_like_interfaces.2Fabstract_classes.2C_not_classes_itself)

"Type classes are like interfaces/abstract classes, not classes itself

There is no inheritance and data fields (so type classes are more like
interfaces than classes)....

For those more familiar with Java/C# rather than C++, type classes resemble
interfaces more than the classes. In fact, the generics in those languages
capture the notion of parametric polymorphism (but Haskell is a language that
takes parametric polymorphism quite seriously, so you can expect a fair amount
of type gymnastics when dealing with Haskell), so more precisely, type classes
are like generic interfaces.

Why interface, and not class? Mostly because type classes do not implement the
methods themselves, they just guarantee that the actual types that instantiate
the type class will implement specific methods. So the types are like classes
in Java/C#.

One added twist: type classes can decide to provide default implementation of
some methods (using other methods). You would say, then they are sort of like
abstract classes. Right. But at the same time, you cannot extend (inherit)
multiple abstract classes, can you?

So a type class is sort of like a contract: "any type that instantiates this
type class will have the following functions defined on them..." but with the
added advantage that you have type parameters built-in, so:

    
    
      class Eq a where
        (==) :: a -> a -> Bool
        (/=) :: a -> a -> Bool
        -- let's just implement one function in terms of the other
        x /= y = not (x == y)
    

is, in a Java-like language:

    
    
      interface Eq<A> {
    
        boolean equal(A that);
        boolean notEqual(A that) { 
           // default, can be overriden
           return !equal(that); 
        } 
      }
    

And the "instance TypeClass ParticularInstance where ..." definition means
"ParticularInstance implements TypeClass { ... }", now, multiple parameter
type classes, of course, cannot be interpreted this way."

------
equalunique
I'm just glad to a an "ML" article that's referring to MetaLanguage and not
Machine Learning.

~~~
bboreham
I always took it to be Milner Language.

Prof Milner was my first CS lecturer, many years ago. Ironically the language
for that course was Pascal.

~~~
marktangotango
That is amazing, how was he as a lecturer?

~~~
bboreham
Well, that first course was very basic and open to all students, and I didn't
know who he was. Just seemed like a typical lecturer way down the front of a
big hall.

A couple of years later, he taught my class of ~20 his Calculus of
Communicating Systems; I think it was the first time he tried it out on
undergraduates. He was incredibly kind and patient; really interested to find
out which parts of the explanation didn't work, and how he could get it across
better.

------
agentultra
> Dependent types are the future

I think so too. Having a solver fill in my program from the proof obligations
is way too amazing. I feel like there could be a connection from high-level
specification -> implementation either by proof obligation or possibly
synthesis via this route.

Plus I like ML/OCaml and would be happy to see more of it in the world.

~~~
tennix
Agreed on dependent type, and I also love ML syntax more than haskell(yes I
don't like indentation sensitive language). BTW I suggest you give FStar a
try, it has dependent type and OCaml/F# like syntax and support theorem
proving

~~~
pklausler
You don't have to use indentation for nesting in Haskell. Haskell's syntax is
actually defined with curly braces and semicolons and you're free to use them.
It's just smart enough to add missing curly braces and semicolons at the right
places according to indentation when they're missing.

~~~
tennix
Yeah, you're right. But almost all of the community uses indentation which
defined as layout in _Haskell2010 Language Report_ instead of semicolons and
curly braces

------
climber_mac
I was taught functional programming through SML in university two years ago. I
have never had my brain twisted with so many interesting and clever concepts -
it was one of the most valuable semesters I had, and my favourite class.

Go learn functional programming if you haven't, it will force you to look at
problem with a new set of eyes!

~~~
lokeshk
okay

------
pklausler
I revere ML and loved using it back in the day, but I code now in Haskell and
am even happier. I _like_ never having to figure out what parts of a program
or library are referentially transparent. Why would I ever want to use an
impure language again?

~~~
auggierose
Maybe because you need to write some performant code?

~~~
pklausler
I write fast code instead.

~~~
pekk
What do you think the difference is between "performant" and "fast"?

~~~
pklausler
"fast" is in my dictionary.

~~~
auggierose
Thanks for pointing out that "performant" is not in any english dictionary!
([http://weblogs.asp.net/jongalloway/performant-isn-t-a-
word](http://weblogs.asp.net/jongalloway/performant-isn-t-a-word)) Didn't know
that.

Besides that, your "fast" code will not be as fast as it can be if you are
only relying on purely functional code, at least on current architectures.

~~~
bsummer4
Do be fair, he said "impure language" and not "impure code".

 _" Looks like we need to let the scholars know - there are 18,300 uses of the
non-word "performant" in scholarly papers"_ <\- If that's not sarcasm,
something is wrong. Performant is a word!

~~~
auggierose
It is a word, just not an English one it seems! It certainly is a German word.
That might explain a lot ;-) It might also explain the many occurrences, as
there are many Germans writing papers in English.

------
99999
It would be nice if the author provided some actual evidence for sweeping
claims like "modules are far better than objects" and "the world is converging
on ML as the language of choice". If there really is evidence, that would be
great to hear about. If there isn't then these statements seem a bit self-
serving.

------
graycat
For newbies (like me): Apparently in this context, ML abbreviates _meta
language_ , not machine language or machine learning.

------
throwaway000002
Can someone provide me with references for a succinct, lucid introduction to
the ML module system and what problems it solves, and what shortcomings is has
that are (partially?-)resolved by later variants?

~~~
jez
Danny Gratzer wrote about this a while back:

[http://jozefg.bitbucket.org/posts/2015-01-08-modules.html](http://jozefg.bitbucket.org/posts/2015-01-08-modules.html)

