Comment by tjradcliffe | Hacker News Reader

Comment by tjradcliffe | Hacker News Reader

Parent Full thread

> at this point

Which is a huge problem. Optimizing around the current fashion is generally a mistake.

As for the rest: the argument seems to come down to "there are no junior developers in Haskell, because if you don't understand the deep and dark abstractions you're really hardly better than a barbarian anyway."

This translates to: Haskell is doomed as a production language in the real world beyond a few niche/fetish applications, because "real" Haskell devs are always going to be scarce and expensive.

This was the selling point of Java back in the day: you could hire junior Java devs to do much the same things as senior C++ devs because the language was so much safer. I saw this in action. It was impressive. It was also around the time when the current fashion in Haskell was lazy evaluation, which I've seen modern Haskell fashionistas pronounce "not really so important after all".

Fashions change, and Haskell is a highly fashion-driven langauge, which means there will be a lot of unmaintainable Haskell code out there in five or ten years.

That's my prediction at least. Let's look at the issue again in a decade and see if I'm right or wrong!

> > at this point

> Which is a huge problem. Optimizing around the current fashion is generally a mistake.

I think this invokes the invention vs. discovery debate. There are many "design patterns" in Haskell, some of which might be regarded as clever inventions (for example conduits and pipes), in which case I agree that there's an element of "fashion" involved, which leads to incompatibilities and churn.

However, Monad and Applicative are clear examples of discoveries. Even if we try to write code without them, the pattern will still be lurking in there somewhere. Applicative is basically a "static" data-flow graph; ie. the graph is fixed, data flows through. Monad is a "dynamic" graph; parts of the graph can be generated from the data. These patterns will still be present, even if we use a completely different language.

Fashion? Haskell's core abstractions are not design patterns du jour. They're math. They're not going away.

The fashionistas are the programmers who want to pick up a bit of Haskell to impress their colleagues but don't want to learn the abstractions that make it a languange worth learning in the first place. They're the people who read about it on Hacker News and decide it's worth a few hours—enough that they can slap it on their résumé and garner a few more calls from recruiters—but no more. They're the people who insist there's something wrong with your code if a Javascript programmer can't immediately comprehend what's going on, and who can't be bothered to learn how and why to use applicatives.

Despite its minor vogue, Haskell as a language is, by its nature, about as far from fashionable as you can get. And, yes, that's true in part because it takes a lot of time and effort to learn it to a productive level. Haskell has never claimed Java's selling points. There's a lot to learn. But it rewards the effort you put in, eventually.

>Fashion? Haskell's core abstractions are not design patterns du jour. They're math. They're not going away.

That doesn't really make any sense. Just because the abstractions have some kind of Platonic existence doesn't mean that people are going to keep using them.

Significant use of applicatives in day-to-day code is a relatively new development in the Haskell community. I used to write a fair bit of Haskell code around five or six years ago (well beyond basic Haskell 98), but the operators in that code were not familiar to me. (They may have been once, but I clearly didn't come across them often enough to remember them.) It's easy enough to understand the code once you look up the operators, but Haskell does seem to be gradually collecting a lot of abstractive cruft.

There's something to be said for deploying the fancier abstractions when they significantly reduce code size, rather than whenever you possibly can.

Yes, applicative code is a relatively new development in Haskell: applicative functors were discovered only in 2008.

It has nothing to do with fashion. The Haskell language has been around for decades and has grown in different directions based on experience and knowledge earned throughout it's lifetime. There are apps and libraries on Hackage which are 5-10 years old which are still in wide use among Haskell and others (Parse,XMonad, and Pandoc to name a few).

You have some points which are to a point, and in general, true. But you present them in such a ridiculously hyperbolic way that it seems divorced from reality.

Applicative is a pretty standard type class which are often used in introductory resources. It is not likely to be replaced by anything any time soon. If you think that it is a fashion then you should have an idea about what it can/is likely to be replaceable by. So, please do tell.

If anything, Applicative might be less controversial than Monad. I haven't really seen much complaints about the downsides of the usages of Applicative.

"Barbarian" - of course any fairly level-headed explanation of Haskell concepts gets regarded as elitist. It's practically a cliché at this point.

Lazy evaluation - this was pretty much the whole point of the language. A fashion? It permeates the language, being the default evaluation strategy after all. But it is controversial whether it is better than strict (eager?) evaluation. If opinions change about this it might be because someone unearths some way to get more of the benefits of lazy evaluation, and less of the space leaks. And potential discoveries are kind of the point of research languages like this.

Reply on news.ycombinator.com