5 ms·

From what I dimly remember last time I looked, there were a bunch of ways to deal with strings and lists/arrays/etc. Googling "most popular haskell language ex

From what I dimly remember last time I looked, there were a bunch of ways to deal with strings and lists/arrays/etc. Googling "most popular haskell language extensions", I see this article: https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/ https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated... which lists 34 recommended extensions and admits "a few of them are likely to be more controversial than others". Half of them don't have names which make their purpose immediately obvious to me. A more data-driven approach is turned up here: https://gist.github.com/atondwal/ee869b951b5cf9b6653f7deda0b7dbd8 https://gist.github.com/atondwal/ee869b951b5cf9b6653f7deda0b... which concludes "only 10 extensions show up in more than 10% of the Haskell files on GitHub, and 20 show up in more than 5%!" Its discussion on reddit (https://www.reddit.com/r/haskell/comments/916jj0/popularity_of_haskell_language_extensions/ https://www.reddit.com/r/haskell/comments/916jj0/popularity_...) highlights some gaps in the analysis, but also the general notion that "everybody uses language extensions, but not everybody uses the same ones". Of course, each language extension changes the syntax and/or semantics of the language, so in order to "learn Haskell" I'd have to learn one or more flavors/styles of it – and there doesn't seem to be one standard set of language extensions that are commonly used.

T-R 6y ago
You say "of course... I'd have to learn one or more flavors/styles of it", and that seems like a reasonable assumption, but it's not accurate in practice - the extensions largely just add features, so you just turn them on if you're using that feature; there's not much of a separate style for coding around not using one. It's like, if your Java project used a Singleton class, you might feel a need to document it, but if it doesn't, it doesn't mean you have a separate "Singleton-less" style, you just didn't feel the need to use one. Which isn't to say they're not an issue - Haskell really needs a new language standard to clean up that mess, but they don't really fragment the ecosystem the way that, say, the Python 2 vs 3 split did.
- rattray 6y ago
  Hmm, okay, thanks, that's reassuring! To share more on where I'm coming from, one example: when I look at things like Yesod's "Hello world" section in "Getting Started", the first thing I see is 4 pragmas: https://www.yesodweb.com/book/basics https://www.yesodweb.com/book/basics and I just don't have much information on what those are, how commonly they're used[0], whether (and why) I need them to use Yesod, etc. I have a kneejerk reaction to that since I want to be able to understand the code I'm seeing and I'm not sure what's going on behind the scenes. But kneejerk reactions are bad, so I'll give them the benefit of the doubt next time! [0] Well, I definitely understand OverloadedStrings and TemplatHaskell to be very widely used, and think I get their gist.
  - T-R 6y ago
    TemplateHaskell and QuasiQuotes are very closely related. They're where that square bracket syntax comes from: [whamlet|Hello World!|] I would say that they're closer to the situation you're concerned about - they're very much like C++ templates, and equally controversial for exactly the same reasons. Still, I don't usually think of C++ templates, or Haskell ones, as being a different style per-se, just an advanced feature to use sparingly, mostly just when they'll save you from writing a bunch of boilerplate. For completeness - Overloaded strings are the Haskell parallel to Python's b-string, f-string, u-string, etc. TypeFamilies are "let me write functions over types", which sounds like it would be dramatic enough to introduce a different coding style, but since it, like other extensions, needs to play nicely with the type inference, it doesn't conflict with other extensions, so things mostly just work as you'd expect. Since extensions generally work nicely together, most people just turn on "the usual" extensions for the whole project (all the more reason we need a new standard), and only add explicit pragmas in files to call out heavyweight things like TemplateHaskell. In tutorials you're more likely to see them all listed at the top, though, to be clear about what's being used.
    - rattray 6y ago
      Thanks!

T-R 6y ago

You say "of course... I'd have to learn one or more flavors/styles of it", and that seems like a reasonable assumption, but it's not accurate in practice - the extensions largely just add features, so you just turn them on if you're using that feature; there's not much of a separate style for coding around not using one. It's like, if your Java project used a Singleton class, you might feel a need to document it, but if it doesn't, it doesn't mean you have a separate "Singleton-less" style, you just didn't feel the need to use one. Which isn't to say they're not an issue - Haskell really needs a new language standard to clean up that mess, but they don't really fragment the ecosystem the way that, say, the Python 2 vs 3 split did.

rattray 6y ago
Hmm, okay, thanks, that's reassuring! To share more on where I'm coming from, one example: when I look at things like Yesod's "Hello world" section in "Getting Started", the first thing I see is 4 pragmas: https://www.yesodweb.com/book/basics https://www.yesodweb.com/book/basics and I just don't have much information on what those are, how commonly they're used[0], whether (and why) I need them to use Yesod, etc. I have a kneejerk reaction to that since I want to be able to understand the code I'm seeing and I'm not sure what's going on behind the scenes. But kneejerk reactions are bad, so I'll give them the benefit of the doubt next time! [0] Well, I definitely understand OverloadedStrings and TemplatHaskell to be very widely used, and think I get their gist.
- T-R 6y ago
  TemplateHaskell and QuasiQuotes are very closely related. They're where that square bracket syntax comes from: [whamlet|Hello World!|] I would say that they're closer to the situation you're concerned about - they're very much like C++ templates, and equally controversial for exactly the same reasons. Still, I don't usually think of C++ templates, or Haskell ones, as being a different style per-se, just an advanced feature to use sparingly, mostly just when they'll save you from writing a bunch of boilerplate. For completeness - Overloaded strings are the Haskell parallel to Python's b-string, f-string, u-string, etc. TypeFamilies are "let me write functions over types", which sounds like it would be dramatic enough to introduce a different coding style, but since it, like other extensions, needs to play nicely with the type inference, it doesn't conflict with other extensions, so things mostly just work as you'd expect. Since extensions generally work nicely together, most people just turn on "the usual" extensions for the whole project (all the more reason we need a new standard), and only add explicit pragmas in files to call out heavyweight things like TemplateHaskell. In tutorials you're more likely to see them all listed at the top, though, to be clear about what's being used.
  - rattray 6y ago
    Thanks!