99% of the time I read these articles that say $commonly_used_thing [1] sucks, the arguments are always "it is fundamentally incorrect" or some variant thereof [2], and strawmen [3] abound.
Where these arguments fall short are in addressing the simple fact that highly-skilled people produce very neat, well-designed systems that they are pretty happy with from a technical standpoint, and that make money every single day using $commonly_used_thing. If you can't acknowledge that $commonly_used_thing has some good attributes, and that it actually works well for many cases, I don't understand why I should take you seriously.
[2]: There are a handful of variants. I think my favorite is the magical phrase "impedance mismatch", which I think in non-buzzword-speak translates to "fuck you, I'm right"
[3]: Most-frequent strawman: the most essentialist, rigidly-formal version of $commonly_used_thing, when in reality, nearly every version of $commonly_used_thing compromises to cope with reality.
Every time someone says $commonly_used_thing sucks, people come out and point out that $commonly_used_thing is being used for $productive_activity.
It is possible to do amazing work with broken tools, or with the wrong tools. That doesn't mean these tools aren't broken or that they couldn't be better matched to the job.
Not that I think OOP is inherently evil. Reading the article, I don't think the author quite understands OOP. One example:
"In an OOPL I have to choose some base object in which I will define the ubiquitous data structure, all other objects that want to use this data structure must inherit this object."
If he really believes this, no wonder he's railing against OOP. That would be horribly broken.
Your point? Using inheritance the way he's suggesting is a rookie mistake.
Either that, or I'm completely misunderstanding him. He can't be talking about hating composition, though, can he? He uses it in his own Erlang examples!
I don't think Joe ever claimed to be a great programmer. Erlang looks as odd as it does because it was hacked up in Prolog, which few compiler engineers would choose as a starting point.
I think Erlang is interesting precisely because it was created by someone with a little distance.
I take it you have never written anything significant in Erlang?
Try writing something in erlang and I bet you'll see the real power of pattern matching, supervision trees, and the whole message passing infrastructure. If the people who wrote Erlang weren't good programmers they certainly got lucky.
Jokes away - the "really great programmers" for me are people who can do extremely complex things very simple.
For me, Armstrong is somewhere near Peter Norvig. Both made me change my point of view, some complex things became simple (and some simple things became not so simple).
"Erlang was hacked up in Prolog" - it's the same as "Java was hacked in C". First implementation of Erlang was written in Prolog, first implementation of Java was written in C.
No; because C is a fine implementation language. It's low-level enough to be efficient without a lot of moving parts, there's very little magic.
For me, Armstrong got interested in the idea of building reliable systems, went off and did a PhD on the topic, and then created a prototype implementation of the concepts developed therein in Prolog - a declarative language essentially built around combinatorial search with pruning. In other words, he's a fine high-level thinker, and a very competent wielder of Prolog; but I believe I've read elsewhere that it was Mike Williams who rewrote the VM interpreter in C, and all the low-level imperative stuff like GC.
I essentially agree with what you're saying, although in most cases, I would argue against the characterization of the tool as "broken". But I think that's semantics.
If this article was titled "Functional programming offers a number of advantages over OOP when dealing with $productive_activity"[1], my response would have been positive.
[1]: It goes without saying that the article would have to live up to the title. Obviously merely re-titling this article in such a way wouldn't be sufficient.
This seems to be the fashion today. You don't write an article saying "In some cases, outlined below, approach Y can be superior to approach X given conditions A, B and C". You write an article saying "X sucks! Here is how stupid it is - if you want to do N with X, you have to write {this horrible code}. Everybody should abandon X immediately, since it is broken beyond repair, and move to Y, where you can do {cool code snippet}. People use X only because they didn't know about Y or are stupid, you now know about Y, so guess what choice you've left?".
The "impedance mismatch" is not a magical phrase. It simply refers to the mixing of orthogonal concepts: like trying to fit square pegs into round holes. Sure, you can do it. But do you really want to? You have to admit that the (very old) article/blog who made that term famous saw the issue coming and was right about the current (very sad) state of affair we're in. It was "The vietnam war of software development" or something like that. The problem when trying to fit square pegs into round holes is that you end up --to use another term that's going to become "magical" to you-- with a "complected" system. The "elephant in the room" if you wish. You probably want to watch "Simple made easy" by Rich Hickey, the author of Clojure.
Where these arguments fall short are in addressing the simple fact that highly-skilled people produce very neat, well-designed systems that they are pretty happy with from a technical standpoint, and that make money every single day using $commonly_used_thing. If you can't acknowledge that $commonly_used_thing has some good attributes, and that it actually works well for many cases, I don't understand why I should take you seriously.
[1]: Examples of commonly_used_thing: ORMs, OOP, SQL databases, NoSQL databases, operating systems, platforms.
[2]: There are a handful of variants. I think my favorite is the magical phrase "impedance mismatch", which I think in non-buzzword-speak translates to "fuck you, I'm right"
[3]: Most-frequent strawman: the most essentialist, rigidly-formal version of $commonly_used_thing, when in reality, nearly every version of $commonly_used_thing compromises to cope with reality.