←back to thread

99 Bottles of OOP now available in Python

(sandimetz.com)
249 points mattcollins | 3 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 #
nailer ◴[20 Nov 24 13:40 UTC] No.42193844[source]▶
A. OOP as practically implemented for the last 25 years is glueing functions to state

B. Functions and structs.

replies(2): >>42195309 #>>42195764 #
corytheboyd ◴[20 Nov 24 16:11 UTC] No.42195309[source]▶
In the real world, where many people of varying backgrounds and skill levels are editing the same code, if the OOP method becomes a mess, why wouldn’t the functional approach also become a mess? I think that is more the point OP was making. In a vacuum with a single perfect Adonian programmer, seems like the OOP and functional approaches would becomes the same level of maintainable, because we’re in a vacuum of perfection anyway.
replies(1): >>42195675 #
lioeters ◴[20 Nov 24 16:39 UTC] No.42195675{3}[source]▶
In my experience, the mess created using OOP is harder to untangle than the mess created using a functional approach. With the latter, it's simpler to replace a different function for any part of the logic, and the data is always just data; whereas with OOP the method is usually tied up with shared state and other functions.
replies(1): >>42195837 #
1. chipdart ◴[20 Nov 24 16:54 UTC] No.42195837{4}[source]▶
> In my experience, the mess created using OOP is harder to untangle than the mess created using a functional approach.

OP complained about accidental complexity, not subjective takes on how hard it is to refactor code.

Even so, anyone who has any cursory experience with TypeScript projects that follow a functional style can tell you without any doubt whatsoever that functional style is incomparably harder to refactor than any "enterprise-grade" OOP.

replies(2): >>42196327 #>>42209066 #
2. nineplay ◴[20 Nov 24 17:38 UTC] No.42196327[source]▶
> OP complained about accidental complexity, not subjective takes on how hard it is to refactor code.

The biggest problem with accidental complexity _is_ how hard it is to refactor code. Refactoring code is a huge part of software development.

3. nailer ◴[21 Nov 24 21:52 UTC] No.42209066[source]▶
> Even so, anyone who has any cursory experience with TypeScript projects that follow a functional style can tell you without any doubt whatsoever that functional style is incomparably harder to refactor than any "enterprise-grade" OOP.

My experience differs greatly. One can see functional style has taken off in the TS world, particularly with the popularity of React, so I suspect I'm not alone.