This looks really cool. Perhaps someone can explain to me why we need new languages, in the face of rich, powerful, languages/tools such as this. Is it just not-invented-here syndrome + better advertising? More forgiving to beginners? Corporate backing? Better/worse documentation/tooling?
I see new languages with features that don't seem significantly different from what already exits in languages with many years of development and optimization.
I wonder if instead of designing new languages, we should just choose ones with most of the features we want, and build out from there. It would save each team from rewriting (and debugging, hardening, optimizing) the wheel every tie.
"Perhaps someone can explain to me why we need new languages, in the face of rich, powerful, languages/tools such as this."
I became familiar with ML two years ago when I went back to college for a graduate program and had to take an undergrad pre-req. We used the SML/NJ compiler set. Immediately I loved it.
ML looks to be 43 years old according to the Wikipedia page. The answer to your question is a confluence of factors: paradigm shift, a greater need for efficiency years ago, and no corporate backer. In 1973, I think it was just too much of a departure from established programming patterns: think assembly, COBOL, LISP, and FORTRAN. The large computer technology companies were not willing to bet on it. Hence, fewer financial and human resources for fixing some warts people are pointing out in this comment thread.
When I was an undergrad around 1985, the grad CS students were crazed to get as much C experience as possible. Although I can't be certain of their motivation, I speculate that it allowed them to break from coding for insurance and banking companies using COBOL. C was simple to learn and made efficient use of the hardware: perfect for what was needed at the time with IT about to spread to medium and small companies.
In the 90's, OO became a big deal and we were looking for a language that allowed us to reduce the time it took to build against different hardware platforms. Java, with Sun as the parent and cheerleader, fit the bill.
Functional came into the spotlight maybe 10 years ago. (I'll give Scala a lot of credit for drawing developers into learning about the functional paradigm.) As a result of this paradigm's exposure, languages initially created to explore that space are coming into the spotlight. However, they haven't had the advantage of industrial financial backing for the past four decades, so warts are still there.
ML is a beautiful, powerful language. (I'd love to work with it as my daily language.) Had we adopted it instead of C or Java years ago, we would likely have not been familiar with off-by-one and null pointer exception errors. Certainly, people would be writing code much differently.
It's a shame, but we can only go forward. Maybe ML will have its day yet.
> It's a shame, but we can only go forward. Maybe ML will have its day yet.
Maybe, though I suspect its more like that newer ML-derivatives will. I like ML, too, but I don't think ML -- or at least Standard ML -- is likely to have a big renaissance. I think instead that newer ML derivatives or languages influenced by ML -- languages like Haskell or Rust -- will have their day.
Let's not forget F# and OCaml. Places like Jane Street become very attractive for the sake of working with OCaml and (presumably) people with a high level of skill.
Haskell is very attractive. Good run-time performance, the ability to avoid common errors through higher-order functions, and the ability to abstract complex patterns.
I looked into Rust and Kotlin a month ago for a Summer coding project. They were intriguing but not enough to choose. I wound up going back to Scala, which I'd set aside for a couple of years. (Scala pays some tribute to ML as well.) I may go back to one of them at some point.
SML is old, very old. SML has quite a few implementations and MLton is one. This is a fork of MLton with some special features. There's also MLkit which has region types similar to Rust. I don't know if MLkit was first though, but the idea existed before Rust, so it's possible.
I'm a fan of Poly/ML myself. MoscowML is cool, but it seems like the devs either don't have the time or the will to give it any love anymore, and it has been languishing without any updates for years now. It doesn't even build on Cygwin anymore. Meanwhile, Poly/ML is still maintained, and considerably faster (though I couldn't make heads nor tails of its parser code...).
Fun fact, first versions of Rust compiler were written in OCaml before Rust was able to bootstrap itself. Admittedly not really relevant to the discussion at hand.
I deleted my comment after reading yours. I missed the key three words: "such as this". You're right, I read what (s)he meant in reverse. (S)he didn't mean "why did people create SML when other stuff exists", (s)he meant "why does other stuff exist when SML exists".
I see new languages with features that don't seem significantly different from what already exits in languages with many years of development and optimization.
I wonder if instead of designing new languages, we should just choose ones with most of the features we want, and build out from there. It would save each team from rewriting (and debugging, hardening, optimizing) the wheel every tie.