Earlier quoted context omitted.
I find it interesting that you list all of the ML derivatives except the popular one.
Don't be silly; nobody uses Windows.
[deleted]
The Future of Standard ML (2013) [pdf]
51–60 of 82 posts
Re: The Future of Standard ML (2013) [pdf]
#52Earlier 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
What? Mutating a list? DISGUSTING!
Re: The Future of Standard ML (2013) [pdf]
#53Re: The Future of Standard ML (2013) [pdf]
#54Earlier 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
It gets even worse. Because Scala has infix syntax for method calls, you can do
l prepend a append bRe: The Future of Standard ML (2013) [pdf]
#55Earlier 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
What? Mutating a list? DISGUSTING!
It's not mutating, its returning a new list with elements prepended and appended.
Re: The Future of Standard ML (2013) [pdf]
#56> 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.
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
Re: The Future of Standard ML (2013) [pdf]
#57> 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.
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
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.
Re: The Future of Standard ML (2013) [pdf]
#58Earlier quoted context omitted.
The only objection to OCaml is "the crufty syntax," which I think F# has taken steps to improve upon.
I'm sort of sick of hearing that OCaml has crappy or crufty syntax. I like OCaml's syntax. There is just a sea of useless algol brackets in so many languages. I was sort of sad that Rust fell victim to the damn bracket. At times I don't even think Scala is that much more succinct than modern Java 8 (ala bracket indentation fun). I remember years ago (15 years.. jesus I'm old) discovering OCaml and I couldn't believe…
Was OCaml was your first ML language? It seems that most of the people who find OCaml crufty used Standard ML before OCaml.
Re: The Future of Standard ML (2013) [pdf]
#59Earlier quoted context omitted.
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
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.
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
Re: The Future of Standard ML (2013) [pdf]
#60Earlier quoted context omitted.
Learning SML isn't going to help as much with Haskell as you might think. The others, yes.
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.