←back to thread

99 Bottles of OOP now available in Python

(sandimetz.com)
249 points mattcollins | 5 comments | 15 Nov 24 15:39 UTC | HN request time: 0s | source
Show context
cutler ◴[20 Nov 24 02:16 UTC] No.42190248[source]▶
OOP is an industry of its own which generates a ton of incidental complexity. See "Object-Oriented Programming is Bad" by Brian Wills (https://www.youtube.com/watch?v=QM1iUe6IofM) and most of Rich Hickey's excellent videos, especially his keynote at Rails Conf 2012 where he basically told the Ruby crowd they're doing it wrong (https://www.youtube.com/watch?v=rI8tNMsozo0).
replies(4): >>42190770 #>>42191094 #>>42191386 #>>42191490 #
chipdart ◴[20 Nov 24 06:55 UTC] No.42191386[source]▶
> OOP is an industry of its own which generates a ton of incidental complexity.

I think you're confusing "OOP is used in projects and I've seen accidental complexity in projects" with "OOP generates accidental complexity".

The truth of the matter is that developers create complexity. It just so happens that the vast majority use OOP.

I challenge you to a) start by stating what you think OOP is, b) present any approach that does not use OOP and does not end up with the same problems, if not worse.

replies(3): >>42193090 #>>42193446 #>>42193844 #
galangalalgol ◴[20 Nov 24 12:01 UTC] No.42193090[source]▶
a) I'm not sure what OOP is, and it doesn't seem like the people who tout it are either. I'm sure someone would look at code I think is good and call it OOP, and someone who wouldn't. It is so many buzzwords old at this point that using it is more a label of a viewpoint than a coding style. Combined with the book's apparent focus on TDD and carefully selecting names, it zeros me precisely in on a set of people I have worked with over the years. I don't, as a rule, like the code those people generate.

b) The best style is no style, or at least pick a more recently popular dogma like FP, at least it gets you easy/safe parallelism in exchange for throwing some of the tools out of your toolbox.

replies(1): >>42197238 #
layer8 ◴[20 Nov 24 19:24 UTC] No.42197238[source]▶
The core of OOP is encapsulation (into objects) and polymorphic interfaces. You program against interfaces with well-defined contracts. Implementation details are encapsulated behind those interfaces. The same interface can have different implementations. The same interface-typed variable can point to different implementations at different times within the same program execution. The caller who invokes operations on an interface is supposed to not care about the implementation details behind it, and thus be decoupled from them. Interfaces can have an inheritance/subtyping relationship. (Implementations may as well, but that’s optional.) This enables abstracting over the commonalities of several related interfaces without having to introduce an adapter/proxy object. That’s basically it.
replies(1): >>42197665 #
1. ryao ◴[20 Nov 24 20:13 UTC] No.42197665[source]▶
After making those interfaces, the moment you need to do something that breaks those interfaces, you suddenly have a headache. I wrote a program in college that daemonizes by being an instance of a daemon class. Years later, people wanted the option to not daemonize. With C, this would be easy. With the way that I did things according to OOP principles in C++, I need to delete all of the code related to starting the program and write it from scratch.

You could say that I just did not do it right, but that is the problem. You need to know precisely what the future will want to do it right and that is never possible to know in advance. OOP encapsulation is heavily overrated. There are a ton of headaches in C++ that do not exist in C because C does not try to do these things. Ever hear of the diamond problem? It does not exist in C. Nonsensical types that span multiple lines when trying to figure out why there is a type error? Not an issue in C either.

C++ was advertised as reducing complexity, but in reality, it that encourages developers to drown themselves in complexity. If it were not for C never gaining a widespread STL equivalent, C++ would be far less popular. Sun Microsystems did make libuutil to provide such facilities, but sadly, it never caught on outside of Sun Microsystems technologies. The BSD sys/queue.h is the closest we have to it, but it is only for lists, and we need trees too to get a good equivalent to the C++ STL. That said, libuutil is available through ZFS, so it is not that people cannot adopt its awesome AVL tree implementation on other platforms. It is just that people do not know about it.

replies(1): >>42198296 #
2. carmackfan ◴[20 Nov 24 21:28 UTC] No.42198296[source]▶
Your problem was a misuse of inheritance, not encapsulation or interfaces.
replies(2): >>42199144 #>>42204087 #
3. Sohcahtoa82 ◴[20 Nov 24 23:16 UTC] No.42199144[source]▶
Misuse of inheritance is often the biggest generator of criticism of inheritance, sadly.

People use the wrong tool for the job, or use it incorrectly, and then blame the tool. It's like using a hammer to play drums, obliterating the drum set, then ranting against hammers.

replies(1): >>42204106 #
4. ryao ◴[21 Nov 24 13:24 UTC] No.42204087[source]▶
That is exactly what I said you could say:

> You could say that I just did not do it right, but that is the problem. You need to know precisely what the future will want to do it right and that is never possible to know in advance.

Every time inheritance causes a headache, you can call it a misuse of inheritance, but that is only obvious after you have been to the future.

5. ryao ◴[21 Nov 24 13:26 UTC] No.42204106{3}[source]▶
OOP is a tool that causes people to hang themselves with it by design. The only way to avoid misusing it is to be to the future to see the impact of every single decision involving it to make only the ones that do not cause problems.