A defense of object-orientated programming
1 points by lim
1 points by lim
This article almost ignores inheritance which is the most characteristic feature of OOP. It describes OOP as if it is the same thing as abstract data types (it even leaves out dynamic dispatch), and argues that because abstract data types are a good thing, it’s bad to reject OOP. But it is inheritance that has become less popular, in favour of languages that allow you to use abstract data types and dynamic dispatch without inheritance.
It’s silly to defend OOP by defending the features that post-OOP programmers still use after they dropped the more awkward trappings of OOP.
This article is full of "object-orientated". Has "oriented" become "orientated" the same way "commentor" became "commentator"? I find the "-ator" jarring, and I'd like it to not happen in this particular instance.
Per Google Books ngram viewer, object-oriented is the much more popular of the two, but object-orientated started its climb even a bit earlier than object-oriented. They both peaked around 1995, so as far as that part of the shape is concerned, they're probably tracking the same idea.
Since then, "object-oriented" use fell, while object-orientated remained more stable (at its much lower level).
From that I'd say that this is a long-standing linguistic quirk of a particular culture, not some new trend. For example, Google Scholar gives me a bunch of Lisp-adjacent papers from 1984/1985 that use the term "object-orientated".
All of the posts examples are from cultures from use object-oriented, though. And other posts on their website indicate they're a Rubyist. I did Rails for 5 years and never saw "object-orientated" until today!
If we truly want to discourage the adjective ‘object-orientated’, I fear our best approach is to call the practice ‘object-oriention’...
This post is confusing. It says that Rust/Go don't support OOP. Then it goes on to explain that the benefits of OOP are polymorphism & encapsulation. But Rust/Go do support those.
edit: I'm not trying to make an argument that Go/Rust are or are not OOP.
Polymorphism (parametric, functional, whatever) can be achieved in almost any language -- it's just a question of how natural and straightforward it is to do so. OO languages made polymorphism a central theme, an intrinsically supported feature, but the concept didn't originate in OO and it's not limited to OO.
Encapsulation is similarly a concept that predates OO, but that OO made into a central theme, and which its constructs intrinsically support.
These are both important concepts in software construction, but do not require classes and objects to implement. However, classes and objects are fairly obvious and easy ways to achieve polymorphism and encapsulation.
As far as Rust and Go being OO or not: Languages that have emerged after the big OO wave all have OO concepts in them. The mark of good language design is the theft of previously discovered useful ideas. I've used both Rust and Go a little bit, and they both feel kind of OO to me, but they're far different than e.g. Java. Rust enums and traits are what you'd probably focus on in this regard.
p.s. And yes, the post is a bit confusing. I would not have considered it worthy of a post on Lobsters.
Rust and Go support inheritance of interfaces but not implementation (subclassing). It’s an important distinction.
Interfaces are mostly a mechanism to enforce type-checking at compile time, so from the standpoint of a dynamic language like Smalltalk, they don’t provide any inheritance, only polymorphism.
(The weird thing with Go is that it also supports static inheritance (one struct embedding another) but trying to combine this with interface inheritance doesn’t work right, at least it doesn’t produce OOP. I tried this in my early days with Go and gave up.)
Rust and Go support inheritance of interfaces but not implementation (subclassing). It’s an important distinction.
Yeah I agree, I wasn't trying to make an argument that Go was or wasn't OOP. I was just commenting that the examples in the post didn't really back up the claim.
Interfaces are mostly a mechanism to enforce type-checking at compile time
That wasn't true until the generics implementation co-opted them for type parameter constraints. Prior to that, they were exclusively a mechanism to achieve dynamic dispatch.
Does Rust? Closest thing to polymorphism is auto-deref or dyn, but neither of these nearly accomplishes it in the traditional sense.
Do traits and trait bounds count for polymorphism? spangle<T: Draw>(shape: T, banner: Canvas) lets you spangle your banner with any shape, as long as it implements the Draw trait.
Do traits and trait bounds count for polymorphism?
Yes: traits were introduced by the paper How to make ad-hoc polymorphism less ad hoc
Interesting! I have always thought about this as "no" since they are not "a Draw" but "can Draw", but this is probably a pointless philosophical distinction rather than a functional distinction.