... and pattern-matching. But yeh, patterns are a sign of a weakness in the language. And it's not infrequent that patterns really turn out to be anti-patterns.
> But yeh, patterns are a sign of a weakness in the language.
That line of reasoning never ceases to be amusing by how silly and self-defeating,particularly as those who make those claims try to pin ignorance on others while manifesting their own ignorance. They seem to be entirely oblivious to the fact that the main goal and usefulness of patterns is to communicate intent and provide semantics and use a common language to describe common problems. A function is a function but a strategy pattern isn't a state pattern. Those who miss this fundamental difference are totally oblivious to what design patterns actually are.
The point is that patterns shouldn't be patterns in books—they should be abstractions in libraries. You know what's better than having a shared vocabulary you expect everyone to know from a book? Having a shared vocabulary defined in the language and accessible not only to programmers but to the compiler and tooling as well.
> The point is that patterns shouldn't be patterns in books—they should be abstractions in libraries.
And how you go about developing those "libraries"?
By writing code using the programming language, isn't it?
Just because C++ and Java and Python and many other programming languages added support for iterators and generators it doesn't make them out to be less of a design pattern. Heck, supporting emcapsulation and composition and information hiding doesn't make a facade pattern, as well as its concept and the semantics of implementing one, magically disappear.
This fundamental fact regarding design patterns is what these self-important fools miss. While they are too busy grandstanding with their criticism, they are actually showing off their ignorance and demonstrating they don't even understand the basic problems solved by design patterns, which are orthogonal to programming languages and their features.
> A function is a function but a strategy pattern isn't a state pattern.
Funny you should mention that. What does "state pattern" communicate about the design, that "state machine" does not? Because state machine is a well-established term, applicable across paradigms.
And what can you communicate with "strategy pattern"? I mean, pick a design for solving a problem (any problem), and explain the design in writing using the words "strategy pattern". I bet I can rephrase it to be at least as simple, and use common-language terms that predate the "strategy pattern".
I've heard people try to take this stance before, that "design patterns are a way to communicate your designs", but to me, it doesn't hold water. How do you communicate your designs simpler, with them?
Right, a function isn't a pattern. But a pattern in the common usage is some functionality that needs to be communicated outside the core language. In languages that offer that functionaliry in the core, I would argue there no longer "patterns". I don't think many of the gof patterns are remarkable in a modern Language like clojure, because the options are obvious.
It should be clarified that the whole thing is about functional patterns in Clojure that are expressing same functionality as well known OO patterns in Java.
Adding "it's just..." in front of functional patterns doesn't make them non-patterns.
Patterns are named ideas on how to approach/solve similar problems.
They are not tied to OO programming, Java, they are not good or bad per-se; it's just a cookbook with recipes that have names.
Presumably the point is that most functional programmers wouldn't have bothered giving dedicated names to, say, “strategies” or “factories”, more or less the same way nobody would bother calling “(a + b) / 2” the “average pattern”.
> But a pattern in the common usage is some functionality that needs to be communicated outside the core language.
What a truism. Programming languages exist to implement functionalities outside of the core language. So what? Does this mean that software projects aren't designed, and parts of the design may not be shared and integrated in other projects? Those working on software projects still need to discuss design issues, and it's easier and more efficient to assign names to recurring patterns. Those who don't understand this issue and opt to manifest their ignorance by criticizing the existence of patterns are simply fools who try to feign competence by ridiculing the consequences of their own ignorance.
Names are useless unless they convey a precise meaning. And, if you can't write down that meaning in a formal system (such as a programming language or mathematics), then it can't be that precise after all.
> Names are useless unless they convey a precise meaning.
They do convey a precise meaning. You simply fail to understand it, and even make it your point to complain about something you systematically fail to understand where you stand on your dunning-kruger corner.
No idea what you mean by “strong language”, but a high-level programming language is one in which patterns are expressible directly as libraries or frameworks.