> design-patterns are just well-established workarounds for limitations baked into the language

Strict functional programmers have been saying that for years. They may be workarounds, but as patterns they have value in allowing one programmer to structure code in a way that is recognizable to another, even months later. You could say that a steering wheel, gas pedal, and brakes are workarounds for limitations baked into the automobile we wouldn't need if cars could drive themselves, but still value the fact that the steering wheel and the rest of the controls for a driver generally look and work the same across vehicles.

Right you are - but my point is that language designers (especially Java’s) aren’t evolving their languages to render the more tedious design-patterns obsolete - instead they seem to accept the DPs are here to stay.

Take the singleton pattern for example. It’s not perfect: it only works when constructors can be marked as private and/or when reflection can’t be used to invoke the constructor to create a runtime-legal second instance. A better long-term solution is to have the language itself natively support passing a reference to static-state, which completely eliminates the risk of a private ctor invocation - but that hasn’t happened.

OOP Design Patterns are like JavaScript polyfills: they enable things that should be part of the native platform. They’re fine to keep around for a few years when they’re new, but when you’re still using what is essentially an aftermarket add-on for 5+, 10+ or even 25+ years you need to ask if it’s the way things should be or not...

Patterns are commonly (but not only) symptoms of some failure of features on the language but at the same time they are just vocabulary.

Patterns exist in functional programming as well, any map/reduce operation is a pattern, any monad is a pattern. It's a proven way to achieve a goal, it's easy to compartmentalise under a moniker and refer to the whole repeatable chunk with a name.

Unfortunately a lot of people only learn how to properly apply design patterns after doing it wrong and/or overdoing it (mea culpa here!). It's easy to spot the bad smells after you've been burnt 2-3 times.

If map and reduce were design patterns, you’d be writing out the iteration bits every time you used them. Instead map and reduce are abstractions, and you only have to plug in your unique functions and values.

piva00 probably meant that implementing map and reduce for a data structure, rather than the use of them, is a design pattern.

That was my point, thanks for clarifying it :)

This reminds me of a talk by Rich Hickey [0], where he introduces the Transducer pattern, which is actually an abstraction for map/reduce/fold/filter etc.

(But I'm not trying to invalidate your claim that patterns exist in FP in general, only that specific case. Afaik, the Transducer abstraction isn't even widely-known nor used.)

[0]: https://www.youtube.com/watch?v=6mTbuzafcII

What resources would you recommend for learning more about design patterns that are essentially missing language features?

By writing enough code using design-patterns that you see a pattern to the usage (and abusage) of design-patterns - and get plenty of experience with other languages and paradigms where said patterns are irrelevant.

Start with https://wiki.c2.com/?AreDesignPatternsMissingLanguageFeature...