9 ms·

Sorry, could you provide an example of those different styles?

jasperry 6y ago
I would have used the word "features" or "extensions" instead of "styles" but I agree with rattray's point, if I understand it correctly. It seems like every Haskell project makes use of a different subset of 10 to 20 language extensions, each of which requires some deep knowledge of type theory to understand how it affects the language. This makes me feel that, totally apart from the syntax, Haskell/GHC is still more of a laboratory for doing programming language research. Which is great for what it is; I would say Haskell's original motto "avoid popularity at all costs" still holds. I also had hope for languages like PureScript that make an opinionated choice about a subset of those features for the sake of a consistent development framework.
- unhammer 6y ago
  > each of which requires some deep knowledge of type theory to understand how it affects the language This is simply false. Quite a few of them are not much more than syntax sugars, e.g. with LambdaCase I can write eitherToMaybe = \case Left _ -> Nothing Right x -> Just x instead of eitherToMaybe var = case var of Left _ -> Nothing Right x -> Just x With OverloadedStrings I can write "foo" instead of (T.pack "foo") or whatever and it picks the right "pack" function based on the inferred type. OverloadedLists does the same for listy things, e.g. now [1] can be a literal vector and you don't have to say V.fromList [1]. TupleSections lets you write (1,) when you want a function that tuples something with 1 (so (1,) applied to 2 becomes (1,2)). NamedFieldPuns lets you write foo x = let myField = x + 1 in MyType{myField} instead of foo x = let thing = x + 1 in MyType{myField = thing} ----- And then there are a bunch of "Deriving…" extensions that don't require any knowledge either, you just enable the pragma, and it lets you say e.g. data X … deriving (FromJSON) instead of having to explicitly implement the FromJSON instance by hand. I have used Deriving a bunch and have no idea how they work :-) Looking through my main project, the only other extension I use on a regular basis is ScopedTypeVariables. That one's a bit more difficult to explain since you have to have some idea what the words "scope" and "type variable" mean, but basically lets you refer to a type variable from the outer function signature in the type signature of a where-clause. Normally, with foo :: Maybe a -> Int … where helper :: Maybe a -> Int the a's are seen as different types. With ScopedTypeVariables, you can say foo :: forall a. Maybe a -> Int … where helper :: Maybe a -> Int and the a's are the same type. So that lets you have explicit type sigs on helper functions that are restricted to the type of the outer function. (Though I am not an expert on this so maybe I've got it all wrong. But that doesn't stop me from using it to make stuff with.)
rattray 6y ago
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.
tome 6y ago
To reply to both of your respondents at once, > 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 > It seems like every Haskell project makes use of a different subset of 10 to 20 language extensions, each of which requires some deep knowledge of type theory to understand how it affects the language. These comments are both pretty off the mark. It's unhelpful to think of language extensions (the most commonly-used ones at least) as extending the language. It's more that there is one overall Haskell language and the absence of a particular language extension disables a particular feature. The language is, by and large, more coherent with language extensions turned on, not less coherent.
- 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 ago
    Most 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.

I would have used the word "features" or "extensions" instead of "styles" but I agree with rattray's point, if I understand it correctly. It seems like every Haskell project makes use of a different subset of 10 to 20 language extensions, each of which requires some deep knowledge of type theory to understand how it affects the language. This makes me feel that, totally apart from the syntax, Haskell/GHC is still more of a laboratory for doing programming language research. Which is great for what it is; I would say Haskell's original motto "avoid popularity at all costs" still holds. I also had hope for languages like PureScript that make an opinionated choice about a subset of those features for the sake of a consistent development framework.

unhammer 6y ago
> each of which requires some deep knowledge of type theory to understand how it affects the language This is simply false. Quite a few of them are not much more than syntax sugars, e.g. with LambdaCase I can write eitherToMaybe = \case Left _ -> Nothing Right x -> Just x instead of eitherToMaybe var = case var of Left _ -> Nothing Right x -> Just x With OverloadedStrings I can write "foo" instead of (T.pack "foo") or whatever and it picks the right "pack" function based on the inferred type. OverloadedLists does the same for listy things, e.g. now [1] can be a literal vector and you don't have to say V.fromList [1]. TupleSections lets you write (1,) when you want a function that tuples something with 1 (so (1,) applied to 2 becomes (1,2)). NamedFieldPuns lets you write foo x = let myField = x + 1 in MyType{myField} instead of foo x = let thing = x + 1 in MyType{myField = thing} ----- And then there are a bunch of "Deriving…" extensions that don't require any knowledge either, you just enable the pragma, and it lets you say e.g. data X … deriving (FromJSON) instead of having to explicitly implement the FromJSON instance by hand. I have used Deriving a bunch and have no idea how they work :-) Looking through my main project, the only other extension I use on a regular basis is ScopedTypeVariables. That one's a bit more difficult to explain since you have to have some idea what the words "scope" and "type variable" mean, but basically lets you refer to a type variable from the outer function signature in the type signature of a where-clause. Normally, with foo :: Maybe a -> Int … where helper :: Maybe a -> Int the a's are seen as different types. With ScopedTypeVariables, you can say foo :: forall a. Maybe a -> Int … where helper :: Maybe a -> Int and the a's are the same type. So that lets you have explicit type sigs on helper functions that are restricted to the type of the outer function. (Though I am not an expert on this so maybe I've got it all wrong. But that doesn't stop me from using it to make stuff with.)

rattray 6y ago

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.

tome 6y ago

To reply to both of your respondents at once, > 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 > It seems like every Haskell project makes use of a different subset of 10 to 20 language extensions, each of which requires some deep knowledge of type theory to understand how it affects the language. These comments are both pretty off the mark. It's unhelpful to think of language extensions (the most commonly-used ones at least) as extending the language. It's more that there is one overall Haskell language and the absence of a particular language extension disables a particular feature. The language is, by and large, more coherent with language extensions turned on, not less coherent.

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 ago
  Most 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.