[Veedrac]

IMO, the key issue is to differentiate between abstractions in language-space and abstractions in problem-space. Turning a chess board into an object is language-space, since it affects vocabulary; writing a function to count the pawns is problem-space, since it defines a step towards the problem one wants to solve.

Nobody programs without problem-space abstractions any more; this is effectively what you get with functions and libraries. When someone uses a prebuilt tangent function, that's working in problem-space.

Language-space abstractions don't pull the same weight. If they did, Haskell programmers would be so much higher productivity than C programmers that the latter would be simply competed out of the market. Instead we see marginal benefits against marginal costs, and the gamut of C, C++, Go, Haskell, Python, Javascript, etc. are, if not equally good, at least sufficiently similar that there is genuine debate.

If in doubt, abstract the problem. If you do an abstraction and don't have less work to do afterwards, maybe you've abstracted the wrong thing.

[macintux]

> If they did, Haskell programmers would be so much higher productivity than C programmers that the latter would be simply competed out of the market.

That implies a much smarter market than I believe exists.

I think it’s possible (not arguing it’s true) that Haskell is dramatically better yet entrenched interests (e.g., managers afraid of not being able to find programmers, and programmers afraid of being obsoleted) block the logical conclusion.

[seanmcdirmid]

I’m pretty sure most of the Haskell crowd doesn’t believe this. There are benefits to learning, thinking in, and using Haskell, but raw easily measured productivity increases isn’t one of them (nor is it for almost any other programming language).