[freyrs3]

> The way this problem manifests in Haskell is in how incredibly clever it makes you feel to get something done in it. Haskell is different enough from most languages that everything feels like an achievement when writing it. “Look, I used a monad! And defined my own type class for custom folding of data! Isn’t that amazing?“. “What does it do?” “It’s a CRUD app”.

The fallacy here is that type classes, folds and monads are not esoteric structures within the context of Haskell, and using them to structure regular business is pretty mundane. If someone feels a sense of achievement from doing this, they're probably very new to the language. The author of the article has baked in a value judgement about the "normal" way to structure a CRUD application that precludes alternative approaches to structuring application logic.

You could just as well argue that laying out object class hierarchies and using inheritance is "[solving problems] that have nothing to do with what you’re actually trying to achieve."

[DRMacIver]

> You could just as well argue that laying out object class hierarchies and using inheritance is "[solving problems] that have nothing to do with what you’re actually trying to achieve."

Could, indeed semi-regularly do. I actively dislike solving problems with inheritance.

I also actively dislike people missing the point. The problem is not "using programming to solve problems". The problem is letting the novelty of the programming you're using to solve problems con you into thinking you're doing something more clever than you actually are.

[iand675]

I think you're equally missing the point– for serious Haskell programmers, using a monad to structure computation for a CRUD app is nothing to write home about. Having personally written quite a lot of CRUD code with Haskell, I have never thought "Gee, I wrote this with a monad. I deserve a back pat."

If we're talking about things that make me smug as a Haskell developer, I'd probably say that I feel most accomplished when I figure out how to encode more invariants into the type system so that the compiler helps me make fewer errors. I still stand by Haskell as being the best language for that that's not just a university research language.

[DRMacIver]

> I think you're equally missing the point– for serious Haskell programmers, using a monad to structure computation for a CRUD app is nothing to write home about. Having personally written quite a lot of CRUD code with Haskell, I have never thought "Gee, I wrote this with a monad. I deserve a back pat."

Missingthepointception!

It's almost like I didn't explicitly point to this as a phase most serious Haskell programmers grow out of right in the goddamn article.

[iand675]

Yeah, sorry for not addressing that. I guess what I'm getting at is that I don't agree with the fundamental premise of the article. I don't really see "a large enough subset of the Haskell community never reaches that stage and just continues to delight in how clever they are for writing Haskell", and I've used Haskell for about 9 years now. Where are these people?

[DRMacIver]

They're mostly the hobbyists. They're also the people you encounter in other languages (e.g. Scala) telling you how much better this all would be if you just understood Haskell. Unfortunately, due to the relative lack of success of Haskell in industry this is the majority of the people who consider themselves Haskell programmers, and certainly the majority I encounter on the internet.

[wwweston]

> I have never thought "Gee, I wrote this with a monad. I deserve a back pat."

Another way of putting this doesn't have anything to do with how clever the developer thinks they are (or how serious they are now that they no longer think they're clever)...

It's "now you have two problems" -- the original problem you wanted to solve, and the problem of working with the tool/framework/paradigm you've chosen to solve it. So, great, you're doing object/design-pattern oriented development! And then you find this starts to lead you to a place where a significant portion of your overhead is sunk into solving problems that don't seem to have much to do with the original problem domain.

I don't know Haskell well enough to pick on it. I'd love to believe it escapes that kind of problem, but I think it's only somewhat less likely than beating entropy.

[skj]

> You could just as well argue that laying out object class hierarchies and using inheritance is "[solving problems] that have nothing to do with what you’re actually trying to achieve."

Definitely, 100%.

[jbooth]

A lot of people do argue that about big object-class hierarchies and inheritance, and they've been declining since the mid-2000s at least in mainstream OO languages like Java and C#.