To the extent that design patterns are ever useful at all, they are useful when talking about code. They give you a common vocabulary that you can expect other programmers to know covering many technical abstractions that had no official names before patterns came to prominence. In other words, when used correctly the notion of design patterns was about terminology.

I'll agree that they're useful terminology.

But terminology is only useful if it is providing greater specificity than ordinary language more succinctly. Design patterns often don't do this. It's succinct to call some class X an adaptor, say, but you are not really saying anything. It is less succinct to say that "Class X wraps the old library and exposes the interface that the new version of the software expects" but at least that is actually saying something about class X. In other words, if you say, "Class X is an adaptor that wraps ... blah blah blah" what exactly is the word "adaptor" actually adding?

Disagree with this. If I want to perform a task over every element in an array, I reach for a "loop". Or in some cases, a "ForEach". Both succinctly describe the operation I am performing, AND provide two different ways to accomplish the task with their own benefits and downsides.

Both "loop" and "ForEach" are patterns of designing a method for operating on a collection of objects. Ones we use every day.

Also the whole subject seems a little confused in that in some cases patterns are sort of common themes in how algorithms interact with data structures; in other cases they seem to be the data structures themselves (e.g. the composite), and in other cases they seem to be styles of programming (e.g. wikipedia lists RAII as a design pattern. Is RAII even meaningful in languages besides C++?)

Maybe we do need two terms. Maybe we need "data design patterns" and "algorithm design patterns".

And to address RAII, it can be meaningful outside of C++, but most languages outside of C++ do not have the scope-based constructor/destructor resource management system required to support it. Ironically, some other languages have added similar systems after the fact (C#'s IDisposable and using patterns) once they realized that memory is not the only resource that must be managed by a program.

Calling everything pattern will not make your code any better, especially when there are established better names already.
If you write a for loop you just say so, no need to call it loop pattern.
If you write a wrapper class for some library, there is no need to call it adapter pattern.
If you use a global variable, it does not get better if you obfuscate it by wrapping it in a class and calling it use of the singleton pattern, when it would be better to have no global variable in first place.
If you feel like calling a method, it does not get bettter if you obfuscate it by adding code to subscribe to calls first and then doing indirect calls where you cant easily see what is called, even if you call it observer pattern (essentially its just some form of spaghetti code).
If you construct an object, it does not get better if you hide that and call it factory pattern.
I never before saw anyone call a programming paradigm design pattern and that is needless obfuscation, too.
The stack is the stack, which is a data structure, not a design pattern.

I get it, you hate the word pattern. Feel free to use your own word for "reusable chunk of data/code".

No need to keep drawing this out.

I think the point that's more salient to this thread is that solving problems in terms of Gang of Four-type design patterns (as opposed to just solving problems) does not necessarily make the resulting code better.

Of course, without knowing more about OP's problem, it's hard to say whether an adapter or an abstract adapter or simple conversion functions is the right decision.