Hacker News Reader

Comment by jasperry | Hacker News Reader

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.

View on HN

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.

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.

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.

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?

I'm at IMVU. We're hiring! :) 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.

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.

Sounds very similar to approaches we've taken with C++ with a team that largely didn't have C++ experience(~15 devs, 2-3 C++ "experts", I use the term losely). Also similar to the approach DropBox said they use with their cross-platform C++ code form a talk a while back.

In cases like this I feel like convention does a good job of keeping a codebase from spawling out into using every feature of the language.

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.

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.

Except controlled side effects are a godsend, even for meat and potatoes.

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.

That's why Go succeeds too.

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.

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!

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

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.

Reply on news.ycombinator.com