What’s the word for when you keep reading an article even though the page is really long because you assume it’s got a lot of comments at the end padding it out and then as you get further and further down you start to realize it’s just a super long article and you never would have started reading it in the first place if you had known up front how long it was?
Here’s a summarized version: http://trelford.com/blog/post/oops.aspx
I find myself agreeing with just about everything said here, but I hate the whiney tone to the writing. There must be a better way to convince OO programmers that there’s a better way.
I’m strongly in favour of Lispy, Schemeish, FP'ish languages and write a lot of Ruby, so you’d have thought I’d love this article…..
But I won’t ever recommend this article.
Attacking something starting off complaining about the “No True Scotsman fallacy” is always counter productive.
Why? Because the attacker then proceeds to set up strawmen.. and when the defender says, “But I wouldn’t….” the attacker says “Aha! You’re using the No True Scotsman fallacy!” and all reasoned discussion ends.
The entire article is strawman after strawman and he is happy with it snug behind his “No True Scotsman” front.
OO doesn’t have one, there is the OO of Kay and Smalltalk there is the OO of Actors and Erlang and there is the OO of C++, all are vastly different.
I think it has everything to do with our education system. Universities systematically switched to Java and OOP to teach first year students. Many are now switching to python and few are switching to scheme. At the time I went through school, we were taught software engineering principals and were forced to memorize and apply various design patterns. We were taught that this ultimate technique has code re-use and encapsulation blah blah blah.
As beginners, we did not know better. All i knew is that I hated that course and didn’t find the translation of ideas into code very natural at all. I much preferred data flow and mathematical models that we studied in engineering. Those felt far more natural to me. Then I learned functional programming.
I have worked out what this article needs.
It needs vigorous pruning.
I sincerely wish the Author would challenge himself to remove three quarters of the verbiage whilst retaining the essence… and then challenge himself to do so again.
I feel like articles like this tend to devolve into semantic confusion: what’s OO programming? What’s functional programming? What affordances does a specific language environment provide for one style as opposed to another? What sorts of problems are more amenable to a “OO approach”? What is an OO approach? There’s a lot of category error in this article (and it is shamelessly overlong) and it never really expends the energy on definitions. If you don’t define the terms of your argument, you’re just begging for the most superficial of arguments.
I just think that there’s a lot of sound and fury expended on a devoted lack of depth of analysis.
The “Scala” example of hasUpperCase is Java. A Scala implentation would look more like this:
def hasUpperCase(word: String) = word.exists(Character.isUpperCase)
i.e. nearly identical to the clojure example.
In fact, after explicitly calling out Scala as a target at the beginning, most criticisms (e.g. no language-level data structures, poor concurrency, mutable-by-default, lack of external specification of behaviour using a mechanism like type classes) don’t apply to Scala, which by the author’s own reasoning mean they’re not valid criticisms of OOP. The failure to precisely define his terms makes a significant impact on what could have been a compelling argument.
I think the core essence of OO is dynamic dispatch, everything else is somewhere between nice-to-have and cruft.
Sadly, when functional-first/functional-only proponents argue that they can replace OO code with better FP code, dynamic dispatch is usually left out; probably because the functional alternatives are either completely horrible or can’t actually express the use cases one would use dynamic dispatch in the first place for.
Dynamic dispatch is incredibly powerful and dangerous, but also very useful and expressive, especially in cases where other abstractions have been exhausted.
Plus, a good object system can be a great module system, another thing some flagship-functional languages like Haskell are struggling with.
There has been this traditional thing of saying “functional is good for code in the small” and “OO is good for code in the large”, but I’d offer a slightly more nuanced view from small to large which works extremely well in good hybrid languages: