Hacker News Reader

Comment by BeetleB | Hacker News Reader

But I don't want my kids' minds being poisoned by OO paradigms. God forbid they start using design patterns everywhere!

Seriously, though - seeing how most adult programmers do OO poorly ...

View on HN

I can't agree enough. What other paradigm is so regularly implemented in a way that makes doing it poorly easy(Inheritance), doing it well hard(Composition), and requires a list of caveats so large that it effectively draws down to "only use it in these specific places"?

How does a paradigm like that survive? I might be a fan of functional, but I'm not even saying go that way- stay procedural! Learn your abstractions over time and only build them when necessary.

VBA's OOP doesn't have inheritance, so I had to use composition. Now I understand that the constraint resulted in better code.

How do implementations of OO make inheritance easier than composition?

I think the refrain has more to do with inheritance being heavily promoted as the reason for doing OO in the early 90's till the mid 00's. I believe even Bjarne Stroustrup said if you're not doing inheritance, it's not OO and you should stick to C.

Also, while one can do composition about as easily as inheritance, it still has its warts in languages like C++. If you want to unit test code, it's recommended to use dependency inversion instead of regular composition - there are other good reasons to do DI as well. But when you start coding the same stuff in non-OO paradigms, you realize that it's just much easier - stuff like DI was popularized to get around the flaws of the OO implementation in those languages. The same goes for most OO design patterns.

The number of languages that only support Inheritance and have no version of Composition(or severely compromised versions) is long. What's funny is how many of them make it easier to perform composition as long as you avoid the `class` keyword.

> doing it well hard(Composition),

suggest how this may be fixed

> and requires a list of caveats so large that it effectively draws down to "only use it in these specific places"?

I don't recognise this, can you explain please

Design patterns

IIRC OO is a design pattern. Just happens many langs support it directly.

> suggest how this may be fixed

Only allow composition. Allow composition techniques to add state, detect the presence of other composition types, etc.

It's like Pox Party. You're exposing them early so they get immune when they're adults from this disease.

ROFL, I remember that in the early 80s. Me and brother.

I wonder when our institutional/civilizational memory of this will fade entirely with childhood vaccination...

Yet somehow Ruby, Python, Javascript, Java, C++ remain widely used languages that implement all kinds of software.

Of these, I would consider only Java to be a true OO language.

Python: Sure, everything is an object, but you don't need to know much about OO to use them. I program in Python professionally, and rarely do I write classes (unless I'm using a framework like Django that requires them). Also, if your language doesn't support data encapsulation, can you even call it OO?

JS: Wasn't OO a later addition to the language? You can get a huge amount done in JS without classes, and that isn't considered poor JS. The general push in JS is to go more functional, not more OO.

C++ is just C with an overly complex OO appended to it. Again, you can write fantastic code in it without relying on OO directly.

JS is a prototypal language, classes are just sugar on top of the prototypes. It's still a flavor of OOP (Self, the original prototypal language, was basically Smalltalk without classes). Ruby makes heavy use of OOP, but allows procedural style of programming similar to Python. You look at Python data science libraries built on top of Numpy such as Pandas, and you see plenty of class stuff.

The web DOM is object oriented. But sure, in these languages you don't have to write your own classes and methods, use inheritance, etc. But plenty of code has used it, and somebody is maintaining, using or extending that code.

The point isn't that OOP is inherently bad and should never be used, but that writing OOP code well (as opposed to merely using objects) is nontrivial. Hence the "seeing how most adult programmers do OO poorly" comment. We've had lots of problems with universities starting off with OOP in the introductory course. I would not deem it suitable for kids unless they are already good at procedural programming.

Of course good stuff has been written in OOP. I personally like that Django uses OOP - it's a good fit. Doing it well is not easy, though. And many problems are easier solved without it.

> JS is a prototypal language, classes are just sugar on top of the prototypes.

Is OOP now a vague term, akin to "functional programming"?

I still maintain that not having data encapsulation (i.e. Python) means it's not OO. (Not that I particularly want it to, either).

Reply on news.ycombinator.com