5 ms·

I consider myself a functional programmer, and I also have an interest in logic and type theory, and have learned enough Haskell to write some student-level pro

I consider myself a functional programmer, and I also have an interest in logic and type theory, and have learned enough Haskell to write some student-level projects in it. But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast. There are too many language extensions, and more and more conceptually sophisticated features keep getting added to it. Every project uses a different set of GHC extensions. I feel that without more standardization or stability, Haskell can never be more than a playground for PL researchers who can afford to spend all their time learning and implementing advanced language features.

chrisseaton 11y ago
For me all the extensions and abstractions induce a kind of choice paralysis, and fear that my program isn't abstracted far enough. I don't feel that when working in C, Java or Ruby.
- jasperry 11y ago
  That captures my feelings really well. And then I think that if I'm going to stick to the "meat and potatoes" of functional programming, I might as well just use a language in the ML family.
  - kqr 11y ago
    Except controlled side effects are a godsend, even for meat and potatoes.
    - vu3rdd 11y ago
      Yes, indeed. Even with the 101 level haskell I write, it feels so right. I exactly know where the side effects are and the semantics of the program is so clear.
- throwaway6969 11y ago
  That's why Go succeeds too.
- jberryman 11y ago
  Are you really talking about ghc extensions? I think it's quite possible you'd feel that if the haskell library state of the art just had advanced in a strictly haskell-98 world.
- mbrock 11y ago
  Abstraction, like optimization, is nice when it serves a purpose. If it doesn't serve a purpose, you're probably just making your program harder to understand for no reason. You can see this in Java too, with proliferating class hierarchies introducing needless concepts. Haskell is also a research language and there are people working on abstractions for the sake of it, much like mathematicians sometimes do. If that's not your interest, just write programs that work and don't worry about being abstract for the sake of abstraction!
- vu3rdd 11y ago
  > ...fear that my program isn't abstracted far enough... This. I feel exactly the same. I read various concepts like Free Monads, I go find papers and read them. But when I sit down to write code, my code is a blob doing IO. I can use State monads, StateT etc. But the result is not the elegant programs that I see on books and blog posts. I am also very pragmatic. I want to build tools that implement an idea I have. I want to build as soon as possible to try these ideas out. But when programming in Haskell, I find myself code golfing and lost in the means rather than the ends.
thinkpad20 11y ago
I don't really feel that way. In fact, I think that there's just so much going on in Haskell that it kind of frees me from having to understand it all. Being comfortable with fundamentals of purely-functional programming (basically ADTs and use of first-class functions e.g. with maps/filters/folds), and the essential types and type classes (Functor, Applicative, Monad, State, etc) give one enough of a grounding as to be able to write pretty much any program one could want. Sure, I could try to learn lenses, or the parallelism libraries, or software transactional memory, or DataKinds, or the infinitude of Ed Kmett Prosemicofunctor type classes... or not. If it turns out I need those, or I think they'd be particularly useful, I can learn them, but I don't need to. I'll never know everything there is to know, so I don't feel an obligation to.
- platz 11y ago
  Part of the problem is a 'relative' lack of material covering practical development in haskell, compared to material explaining/exploring fancy type featues ( i.e. Prosemicofunctor type classes ) , and those that do blog about more mundane issues dont get voted up or are as visible in the community since its not interesting to those that have already passed that level.
implicit 11y ago
This matches my experience. At the company I work at, we use Haskell for HTTP services. The software stack we've grown is extremely opinionated about how to do things. We provide just one way to do things like report errors, run queries, do work asynchronously, and so forth. We get people up and running with about the same amount of effort as we spend getting people going on our PHP, and I think a big part of the reason why is because we're able to constrain the education effort to the slice of Haskell that we want them to read and write. For instance, we accept the fact that we have new teammates who haven't yet truly understood what "do" blocks are all about. These people are nevertheless able to write perfectly serviceable, production-ready code. They've learned that they can chain imperative actions together in a particular way, and that's enough for awhile. Deep understanding comes later.
- kornish 11y ago
  Two questions - first, did you reply to the wrong comment? Seems like you might've meant to reply to thinkpad20's comment, which is about not needing to know everything to be productive. Second - where do you work?
  - implicit 11y ago
    I'm at IMVU. We're hiring! :) http://www.imvu.com/jobs/index/ http://www.imvu.com/jobs/index/ I intended to react to the comment "But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast." I think this is true. There are too many ways to do everything in Haskell and they're changing too often. If you don't get very specific guidance, you're going to be totally paralyzed with indecision. I have good evidence that you can do very well by confining the solution space.
    - kornish 11y ago
      Nice! How long have you been there? It'd be interesting to hear how things have gone running Haskell in prod (and hiring, and such) since your guys' blog post in March of 2014. Gotcha. It also doesn't help that many of the canonical learning materials (e.g. LYAH, or Real World Haskell) are slowly drifting out of date.
lambdasquirrel 11y ago
I don't know if I'd entirely agree. I feel like the way we package up javascript deps changes all the time (gulp seems to have won the battle for now?) and Scala's build system wasn't even really usable until maybe 2 years ago. It's an issue, but I think that having a usable IDE, devops toolchain/integration are bigger issues.

chrisseaton 11y ago

For me all the extensions and abstractions induce a kind of choice paralysis, and fear that my program isn't abstracted far enough. I don't feel that when working in C, Java or Ruby.

jasperry 11y ago
That captures my feelings really well. And then I think that if I'm going to stick to the "meat and potatoes" of functional programming, I might as well just use a language in the ML family.
- kqr 11y ago
  Except controlled side effects are a godsend, even for meat and potatoes.
  - vu3rdd 11y ago
    Yes, indeed. Even with the 101 level haskell I write, it feels so right. I exactly know where the side effects are and the semantics of the program is so clear.
throwaway6969 11y ago
That's why Go succeeds too.
jberryman 11y ago
Are you really talking about ghc extensions? I think it's quite possible you'd feel that if the haskell library state of the art just had advanced in a strictly haskell-98 world.
mbrock 11y ago
Abstraction, like optimization, is nice when it serves a purpose. If it doesn't serve a purpose, you're probably just making your program harder to understand for no reason. You can see this in Java too, with proliferating class hierarchies introducing needless concepts. Haskell is also a research language and there are people working on abstractions for the sake of it, much like mathematicians sometimes do. If that's not your interest, just write programs that work and don't worry about being abstract for the sake of abstraction!
vu3rdd 11y ago
> ...fear that my program isn't abstracted far enough... This. I feel exactly the same. I read various concepts like Free Monads, I go find papers and read them. But when I sit down to write code, my code is a blob doing IO. I can use State monads, StateT etc. But the result is not the elegant programs that I see on books and blog posts. I am also very pragmatic. I want to build tools that implement an idea I have. I want to build as soon as possible to try these ideas out. But when programming in Haskell, I find myself code golfing and lost in the means rather than the ends.

thinkpad20 11y ago

I don't really feel that way. In fact, I think that there's just so much going on in Haskell that it kind of frees me from having to understand it all. Being comfortable with fundamentals of purely-functional programming (basically ADTs and use of first-class functions e.g. with maps/filters/folds), and the essential types and type classes (Functor, Applicative, Monad, State, etc) give one enough of a grounding as to be able to write pretty much any program one could want. Sure, I could try to learn lenses, or the parallelism libraries, or software transactional memory, or DataKinds, or the infinitude of Ed Kmett Prosemicofunctor type classes... or not. If it turns out I need those, or I think they'd be particularly useful, I can learn them, but I don't need to. I'll never know everything there is to know, so I don't feel an obligation to.

platz 11y ago
Part of the problem is a 'relative' lack of material covering practical development in haskell, compared to material explaining/exploring fancy type featues ( i.e. Prosemicofunctor type classes ) , and those that do blog about more mundane issues dont get voted up or are as visible in the community since its not interesting to those that have already passed that level.

implicit 11y ago

This matches my experience. At the company I work at, we use Haskell for HTTP services. The software stack we've grown is extremely opinionated about how to do things. We provide just one way to do things like report errors, run queries, do work asynchronously, and so forth. We get people up and running with about the same amount of effort as we spend getting people going on our PHP, and I think a big part of the reason why is because we're able to constrain the education effort to the slice of Haskell that we want them to read and write. For instance, we accept the fact that we have new teammates who haven't yet truly understood what "do" blocks are all about. These people are nevertheless able to write perfectly serviceable, production-ready code. They've learned that they can chain imperative actions together in a particular way, and that's enough for awhile. Deep understanding comes later.

kornish 11y ago
Two questions - first, did you reply to the wrong comment? Seems like you might've meant to reply to thinkpad20's comment, which is about not needing to know everything to be productive. Second - where do you work?
- implicit 11y ago
  I'm at IMVU. We're hiring! :) http://www.imvu.com/jobs/index/ http://www.imvu.com/jobs/index/ I intended to react to the comment "But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast." I think this is true. There are too many ways to do everything in Haskell and they're changing too often. If you don't get very specific guidance, you're going to be totally paralyzed with indecision. I have good evidence that you can do very well by confining the solution space.
  - kornish 11y ago
    Nice! How long have you been there? It'd be interesting to hear how things have gone running Haskell in prod (and hiring, and such) since your guys' blog post in March of 2014. Gotcha. It also doesn't help that many of the canonical learning materials (e.g. LYAH, or Real World Haskell) are slowly drifting out of date.

lambdasquirrel 11y ago

I don't know if I'd entirely agree. I feel like the way we package up javascript deps changes all the time (gulp seems to have won the battle for now?) and Scala's build system wasn't even really usable until maybe 2 years ago. It's an issue, but I think that having a usable IDE, devops toolchain/integration are bigger issues.