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 perfo…
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…
The Future of Standard ML (2013) [pdf]
11–20 of 82 posts
Re: The Future of Standard ML (2013) [pdf]
#12Re: The Future of Standard ML (2013) [pdf]
#13I'm just glad to a an "ML" article that's referring to MetaLanguage and not Machine Learning.
Re: The Future of Standard ML (2013) [pdf]
#14Earlier quoted context omitted.
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…
I find it interesting that you list all of the ML derivatives except the popular one.
Re: The Future of Standard ML (2013) [pdf]
#15Re: The Future of Standard ML (2013) [pdf]
#16Cutting 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 perfo…
> operators (not named functions) are to programming
> languages as icon-only buttons are to web pages;
> they are completely unusable.
I see ( ) ; . you are using already. Latin letters are gibberish to people who don't use it.Re: The Future of Standard ML (2013) [pdf]
#17Re: The Future of Standard ML (2013) [pdf]
#18Earlier quoted context omitted.
Poly/ML?
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.
Re: The Future of Standard ML (2013) [pdf]
#19Cutting 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 perfo…
> operators (not named functions) are to programming > languages as icon-only buttons are to web pages; > they are completely unusable. I see ( ) ; . you are using already. Latin letters are gibberish to people who don't use it.
val list = a +: l :+ b
And I knew I had to put in a comment because that stuff always makes my eyes cross over when I come back to it.Re: The Future of Standard ML (2013) [pdf]
#20Cutting 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 perfo…
Holy cow, poly/ml looks outstanding, threads, sockets, signals, a ffi, a lot of things I've been missing in SML all these years. Is there support for unicode in the string library? How's the generated code performance wise? I will definitely keep an eye on this project.