4 ms·

What do you mean with es6 lifted closures into the language? As far as I remember, closures have been in JS right from the start (and given that Brendan Eich jo

by patrec 7y ago

What do you mean with es6 lifted closures into the language? As far as I remember, closures have been in JS right from the start (and given that Brendan Eich joined mozilla to "do scheme in the browser", we can be pretty sure where they came from). ES6 just added a more lightweight syntax. I agree that SML isn't even on the map, in terms of practical programming language choices (one of the most hilariously titled CS books of all time must _ML for the working programmer_ where the final "real project" chapters consist of writing such working programer perennials as a lambda calculus interpreter and a theorem prover). And I believe that even scheme is less suited to write almost any type of practical software than Haskell. But that's precisely my point: a language having a positive influence on the state of applied programming does not mean that it is actually a good choice for solving practical problems with. And vice versa.

agumonkey 7y ago
You're right, I just meant the lexical closure syntax (..) => (giving a clear fp feel to the language by promoting closure syntactically). and this is part of a wide move from all dyn langs to lift fp features like destructuring. es6 was just one tiny point that I had in mind when commenting above. btw I love sml. I'm just being realist about it's mainstream existence. Lastly, it's as if you consider haskell as proof of concept and nothing more. I don't see any real hurdles why haskell is less practical than typescript (except the fact that TS relies on the years of js project they can compile and interop with)
- patrec 7y ago
  How about: a typical typescript project does not start off with a dozen compiler pragmas non-trivially changing language semantics? Or: no matter their background, it will take at least 10x more time to spin up new developers with Haskell than typescript?
  - tome 7y ago
    Haskell language extensions do not change the language semantics. They extend the semantics with additional functionality. Existing code does not change its meaning when you enable an extension.
    - patrec 7y ago
      Strict. Not a change in language semantics at all.
      - tome 7y ago
        Ah, great counterexample! StrictData is another. Do you know any others that change language semantics non-trivially? I would roughly define "non-trivially" to mean "correct programs become incorrect". By the way, I'm particularly interested because I am writing about Haskell myths. I have a very rough draft at http://h2.jaguarpaw.co.uk/posts/haskell-myths/ http://h2.jaguarpaw.co.uk/posts/haskell-myths/
        cannabis_sam 7y ago
        There’s also QuasiQuoter which can make valid code with list comprehensions not compile, but it doesn’t just compile it, it gets stuck looking for the end tag. Not sure if that qualifies :P

by patrec 7y ago

agumonkey 7y ago

You're right, I just meant the lexical closure syntax (..) => (giving a clear fp feel to the language by promoting closure syntactically). and this is part of a wide move from all dyn langs to lift fp features like destructuring. es6 was just one tiny point that I had in mind when commenting above. btw I love sml. I'm just being realist about it's mainstream existence. Lastly, it's as if you consider haskell as proof of concept and nothing more. I don't see any real hurdles why haskell is less practical than typescript (except the fact that TS relies on the years of js project they can compile and interop with)

patrec 7y ago
How about: a typical typescript project does not start off with a dozen compiler pragmas non-trivially changing language semantics? Or: no matter their background, it will take at least 10x more time to spin up new developers with Haskell than typescript?
- tome 7y ago
  Haskell language extensions do not change the language semantics. They extend the semantics with additional functionality. Existing code does not change its meaning when you enable an extension.
  - patrec 7y ago
    Strict. Not a change in language semantics at all.
    - tome 7y ago
      Ah, great counterexample! StrictData is another. Do you know any others that change language semantics non-trivially? I would roughly define "non-trivially" to mean "correct programs become incorrect". By the way, I'm particularly interested because I am writing about Haskell myths. I have a very rough draft at http://h2.jaguarpaw.co.uk/posts/haskell-myths/ http://h2.jaguarpaw.co.uk/posts/haskell-myths/
      - cannabis_sam 7y ago
        There’s also QuasiQuoter which can make valid code with list comprehensions not compile, but it doesn’t just compile it, it gets stuck looking for the end tag. Not sure if that qualifies :P