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?
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.
Strict. Not a change in language semantics at all.
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/
Re:Haskell Problems for a New Decade
by cannabis_sam on Sunday January 26, 2020 @01:40PM
(#22153780)
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
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)