[weland]

> But isn't the main point of the article that OOP just doesn't always fit the problem domain, that sometimes you want to model something in a way where forcing it into objects (nouns and verbs) only adds complexity without benefits?

Perhaps that's the point of the article, but the fact that a programmer might want to use a paradigm in an unfit manner is arguably not a problem of the paradigm.

OOP is fairly foreign to my daily work, so I'm not too attached to it, but I think a lot of the criticism it receives is unfair. It gets a lot of crap because Java and C++ implement it incompletely (and the part that they do implement is done quite poorly), and people naturally think it's a problem of the paradigm itself. I think 90% of the "OOP is bad because..." arguments are routinely handled with "Yeah, Smalltalk actually solves that by..." and should actually be phrased as "Java is bad because...".

[tsahyt]

> not a problem of the paradigm

Correct. The main problem I see with OOP is that some people advocate it as the only correct way to write maintainable code, which, of course is completely wrong. In fact, OOP doesn't translate well to some problems. There are also problems where FP doesn't work as nicely as other paradigms. In short, there is no silver bullet and advocates of any paradigm should be more open about that.

[weland]

> Correct. The main problem I see with OOP is that some people advocate it as the only correct way to write maintainable code, which, of course is completely wrong.

Yes, my opinion is similar. There are problems that naturally lend themselves to being modeled using objects, and others which have to be beaten into submission. Not having to beat them into submission with half-witted OOP implementations, like C++, does help, but it is not always sufficient to take away the sensation of "unnaturalness", if you don't mind the invented word.