Yet composition in the OOP sense seems like it can be easily achieved in any other paradigm - so OOP does not seem to address composition in any distinct way.
I disagree. I think the criticisms in the GGP post are largely targeted at a very particular form of OOP (which is granted probably the most popular form): That popularized by C++ and later doubled down on by Java. Inheritance heavy, overly mingling interface and structure, etc.
The Smalltalk/Ruby/arguably Erlang form of OO does not really treat composition and inheritance as things at odds -- the way the object you're talking to has achieved its composition (where inheritance is a specialized form of composition) is basically irrelevant to you as the caller does address this, and quite well imo.
I agree with you but it is worth noting that many people I've come across will claim that the other forms of OO aren't really OO. For instance the OO system that we see in CLOS, Dylan, R's S4, etc. I vehemently disagree with them but my point is that for many people OO is by definition the one "popularized by C++ and later doubled down on by Java"
Indeed. For many people, the question "what is OO programming?" has an answer that mentions the word "class" a few times before it mentions the word "object".
That's why I call that subset of OO "class-oriented programming", instead.
Fully agreed. But how many Java/C++ programmers doing "OOP" would you guess are familiar with Smalltalk and Self? I'm not talking about people interested in PL theory, but the thousands of programmers out there working for the maintream industry and "doing OOP".
I'm going to guess: not many.
Lest I seem dismissive or condescending: I shamefully count myself among those industry programmers. I'm not at all familiar with Self, and my only knowledge of Smalltalk comes from one CompSci course and a presentation at OOPSLA.
Recently I was making a case to coworkers that the typeclass pattern in Scala (and presumably typeclasses in Haskell, I'm not personally familiar) was a completely OOP construct in the vein of CLOS/Dylan. I was met with raised eyebrows all around, and some of the people in the room were pretty far beyond "those industry programmers" so the problem isn't just one of naiveté
"Smalltalk and Self" more dramatically illustrates why its disturbing (to people familiar with the history of OOP), but what applies to them also applies to their more-currently-popular descendants, Ruby and JavaScript (among others).
Composition in this sense is talking specifically about composition of objects. By definition, that's only going to be possible in languages with objects. No other paradigm achieves that (for better or worse).
From what I understand, composition in OO basically means that I put another object as a field in my new object. Is that correct? If so, I don't really see the fundamental difference from doing the same thing with a struct/record: put another struct/record inside another struct. Especially if I can use encapsulation to hide the internal structure of the struct/record.
Composition is far more useful and effective means of code reuse in OOP.