[ssivark]

Though I’m not much of a Haskell programmer (spent some time learning it and writing toy programs), I would use a different motto to characterize Haskell: Stop prescribing (loose) design patterns; make them tight and refactor them into libraries, so they need only be written once.

More than anything else, the language aims at providing modularity (and terseness, on the macro scale) for the programmer (while trying very hard to compile to something efficient). Even laziness is to enable more modularity.

The “make design patterns tight” part is what ends up needing abstract mathematical reasoning (category theory is basically mathematical pattern reasoning distilled to its essence).

The other consequence of abstracting patterns into libraries is that novice programmers end up with a lower “writing code” -vs- “reading+thinking” ratio compared to other languages. And this can be jarring to folks whose attitude is to learn by writing code (to discover patterns in the process).

[ncmncm]

"All patterns are anti-patterns."

A pattern is a common expression form that your chosen language is unable to capture in a library. As we get better languages, what had been patterns turn into ordinary library components. Patterns composing those with one another and with core language features either become more library components, or challenges for subsequent language design.

[mikekchar]

I really disagree with this viewpoint. Patterns are just patterns. It doesn't matter if your language is able to express the pattern in a reusable form or not. The whole point of a pattern is that it is a common solution to a class of problems given a set of circumstances. Even if you have a "super awesome pattern" widget that you can use, you still need to know whether or not that pattern is appropriate for the problem you have and the circumstances in which the problem is expressing itself. Even beyond that, most programmers will be dealing with many more than one programming language in their lifetime. Learning well known design patterns is about understanding the abstractions, the problems and the circumstances so that when you are faced with a similar situation in another language you can efficiently see if there are capabilities that will help you out.

Basically, consider the situation where you say, "Here's how I do X in this language. How would I do a similar thing in that language"? A design pattern gives you a name that you can use instead of "X". It also gives you a context where you can realise, this pattern is appropriate in here, but not appropriate there. When you talk to people you can simply say, "Can I easily implement a functor here? If not, how can I get similar utility in the same circumstances? Are there any caveats that are different than the normal ones?" It seriously speeds up the conversation. It also allows one to think about programming more generally rather than thinking of it only in terms of a specific programming language.

Edit: grammar

[ncmncm]

You don't use the "sort pattern". You call the sort function, because it exists.

In C, you would code up, in place, an example of the "hash table" pattern, but more expressive languages have hash dictionaries in the library that are as fast as, or faster than, you could afford to code in place.

If your language can't properly express a "maybe" monad, you can cobble something together to use instead, and mention that in a comment. But it's only a pattern because you don't have it.

[mikekchar]

I'm afraid I didn't express myself well. Where I think we're not aligning is that you are under the impression that I'm using the same definition of pattern that you are. It was my intent to express that I disagree with your definition.

It's important to understand that a pattern is a solution to a problem along with contexts in which it is both appropriate and inappropriate. To document a pattern you need: a description of a problem, a description of the solution, contexts in which this solution is appropriate, contexts in which this solution is inappropriate. If you read the early literature on patterns and pattern languages (Beck and Cunningham's initial paper, or really any of Coplien's writings), I hope it will be more clear.

"Sort" and "hash table" are not patterns. They are simply solutions without problems. They are also not specific enough to discuss various contexts. When is it inappropriate to sort? That's a meaningless question without a lot more information. Sorting may indeed be a solution to a problem, but it is not in itself a pattern.

We could say that the maybe monad implements a particular pattern for representing optional data. It is, however, not the only method for representing optional data. There are many others. The point is to be able to understand which one you should use in which context. That it can be implemented in a library is fantastic (less code for you to write), but that was never the point of design patterns (hence the word "design"). The point was to give you a vocabulary with which to discuss the merits of various solutions to problems and to pick appropriate ones for your circumstance.

[lmm]

Do you consider the things in the "gang of four book" to be patterns? If so, how do you distinguish them from something like "sort" or "hash table", since they are also solutions without problems? If not, I'd argue that your definition of pattern doesn't match the present meaning.

[ncmncm]

"Pattern" comes from the Gang of Four book, by way of confusion about an entirely different concept from architecture.

The book has not aged well. Its vocabulary has turned out to be decreasingly useful. I go for many months at a stretch without encountering any reason to mention any of them. The only names that come to mind, at the moment, are the "visitor" and "pimpl" patterns, only the latter of which I have used in the past decade, and that because it is imperfectly supported by the library template std::unique_ptr<>.

That is not for lack of discussion of choices among possible solutions to problems. Notably, most on https://cpppatterns.com/ are just library components.

[mikekchar]

Pattern comes from here: http://c2.com/doc/oopsla87.html It even says so in the GoF book.

[zozbot234]

I wouldn't say that Haskell is "trying very hard" to enable efficient compilation. It might be trying hard given what the existing language semantics looks like, but we still don't have e.g. an elegant model that can equally account for both strict and lazy code (even though there's quite a bit of research in this area, based on fairly natural considerations).

Reasoning about what code patterns actually require the use of general GC (because they involve creating references that might outlive their pre-defined scope, as with general closures) and what patterns might dispense with this is another source of potential efficiency improvements.