Earlier quoted context omitted.
I have ~4 years experience writing OCaml, and ~1 year experience writing Standard ML. I also once did contracting for a Play app in Scala for 3 months. A month ago, I started looking into Haskell for the first time for another side project and was immediately able to pick it up due to how similar it is to OCaml and Standard ML. In particular, the type syntax and function declarations are similar; understanding monads…
If you already know SML or OCaml, you'll pick up Haskell easier, but if you don't know them and want to learn Haskell, you're not taking a shortcut by learning SML or OCaml first.
The Future of Standard ML (2013) [pdf]
61–70 of 82 posts
Re: The Future of Standard ML (2013) [pdf]
#62Earlier quoted context omitted.
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.
Poly/ML produces excellent code. It's probably the second most performant SML implementation after MLton.
Re: The Future of Standard ML (2013) [pdf]
#63Earlier quoted context omitted.
I can see the argument for terseness in source, particularly in domains where the terseness in code reflects well-understood shorthand in the actual problem space. But stuff like that makes me itch, to be honest.
The alternative would be something like l.prepend(a).append(b) Horrible. Ghastly. Can't see anybody tolerating a language that looked like that.. /s
a.append(l).append(b)
?
Re: The Future of Standard ML (2013) [pdf]
#64Earlier quoted context omitted.
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.
F# doesn't even have modules. Not really in the SML spirit—it's like if you combined Classic/LCF ML from the 1970s with C#.
Re: The Future of Standard ML (2013) [pdf]
#65Earlier quoted context omitted.
Same as compsci students at TU Munich, if Prof. Rybalchenko does the intro to functional programming course. I really enjoyed it and found it much better suited for students than other languages, especially with the book by Gert Smolka.
Do you have a link to "that book?"
Re: The Future of Standard ML (2013) [pdf]
#66Earlier quoted context omitted.
The only objection to OCaml is "the crufty syntax," which I think F# has taken steps to improve upon.
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.
https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual...
Re: The Future of Standard ML (2013) [pdf]
#67Earlier quoted context omitted.
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.
F# does have type classes, they're just called interfaces. https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual...
Re: The Future of Standard ML (2013) [pdf]
#68Earlier quoted context omitted.
The alternative would be something like l.prepend(a).append(b) Horrible. Ghastly. Can't see anybody tolerating a language that looked like that.. /s
Don't know Scala but why wouldn't it be a.append(l).append(b) ?
Re: The Future of Standard ML (2013) [pdf]
#69Earlier quoted context omitted.
F# does have type classes, they're just called interfaces. https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual...
Type classes are quite different from interfaces. How would you encode the Eq typeclass in F#? .Net has the IEqualityComparer interface but you need to manually pass that around (unlike Eq instances) and you also lose the global uniqueness property.
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.
Re: The Future of Standard ML (2013) [pdf]
#70Earlier quoted context omitted.
Poly/ML produces excellent code. It's probably the second most performant SML implementation after MLton.
Does it produce native executables that are easy to distribute?