3 ms·
Maybe it's more coherent, but the fact that, after learning the language, you discover that you have 20 more extensions to learn feels like a never-ending quest
by elbear 6y ago
Maybe it's more coherent, but the fact that, after learning the language, you discover that you have 20 more extensions to learn feels like a never-ending quest. I think that's what the previous commentators mean.
If the language is more coherent with the extensions, they should enable them by default.
- pyrale 6y agoMost haskell programmers I know don't know or use all extensions, and do just fine without them. I personally don't know most of them, and I've been doing haskell professionally for years now. Once in a while, I will need to do a specific thing and will google up stuff, and the thing I'll write will remain contained in a couple files, and callers won't have to know about it. It is absolutely not a prerequisite to know all extensions to earn one's living doing Haskell, just like one doesn't have to know the JVM or the dozens of design patterns inside and out to program in Java.
- rattray 6y ago> It is absolutely not a prerequisite to know all extensions Which ones are a prerequisite? OverloadedStrings? TemplateHaskell? How many others? If the answers to that list were enabled by default in the language, and most Haskellers agreed on them, there really wouldn't be much complaint – you'd reach for these fancy macros when you need them, like you say, and that'd be that. A newcomer wouldn't know that some of them are required reading and others aren't and not know which is which.
- tome 6y agoLearn them when you come across them, like any other language feature. It's as simple as that. That they are enabled via an extension is really just a historical quirk of the language having been originally defined by a standard.
- pyrale 6y agoI have never touched template haskell. OverloadedStrings is one of the few extensions you'll see everywhere, but there's nothing to remember about it. It's really the kind of thing you'll understand in 10s and find obvious forever after. > If the answers to that list were enabled by default in the language, and most Haskellers agreed on them, there really wouldn't be much complaint Here is the thing: just moving all the extensions into the language and removing the pragma would basically mean there would still be the same amount of things in the language, but with no convenient way to know what's used in a specific file, and it would be hard to research that topic which you don't know. Extensions are great in that they force devs to label files with searchable names for the concepts they use in the code. > A newcomer wouldn't know that some of them are required reading and others aren't and not know which is which. A newcomer, just like a seasoned haskeller, shouldn't bother learning new extensions if they're not about to use them. That's the way to go forward.
- dllthomas 6y agoI like TemplateHaskell, but it's very much a "turn it on where you need it" thing. On the other side, ScopedTypeVariables is the way the language should have always worked, and should probably just be enabled globally. OverloadedStrings is a trivial syntactic convenience, where every use of a string literal is replaced by (fromString "the string literal"). This makes code substantially more readable when you are wanting literal values of (typically) Text. The downside is that the compiler can't always know what type fromString is expected to return, so you sometimes need to add more type annotations, which gets messy again. I don't care much which way it's set at a project level - I toggle it per file if the project default is too much of a pain locally.
- tome 6y ago> If the language is more coherent with the extensions, they should enable them by default. The main reason that they are not enabled by default is that Haskell has a standard. It's like gcc having -std=c++11, except the opposite way around.