Live data from Hacker News

99 Bottles of OOP now available in Python

sandimetz.com

41–50 of 93 posts

Re: 99 Bottles of OOP now available in Python

#41
post #24

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 ).

As it pertains to Python in particular I think OOP is great for libraries but of limited usefulness at the application layer. Things like pytorch's nn.module IMO is a great abstraction, but every time I've tried to map some concrete business concept to an OOP construct I've regretted it.

Re: 99 Bottles of OOP now available in Python

#42
post #27

Earlier quoted context omitted.

Why on earth do you put composition and OOP as opposing techniques? Composition is just one more technique in the OOP toolbox and there is nothing in OOP that mandates an inheritance based architecture.

Mainstream OOP languages (looking at you Java) have failed to make composition as convenient as inheritance.

How is composition inconvenient?

Re: 99 Bottles of OOP now available in Python

#43
post #27

Earlier quoted context omitted.

Why on earth do you put composition and OOP as opposing techniques? Composition is just one more technique in the OOP toolbox and there is nothing in OOP that mandates an inheritance based architecture.

Mainstream OOP languages (looking at you Java) have failed to make composition as convenient as inheritance.

Very true, in Java, at least in the last 20 years, inheritance is de-facto deprecated, all new bits and bolts like enums, annotations, lambdas or records do not support inheritance.

So you have to use composition.

Re: 99 Bottles of OOP now available in Python

#44

I’m gonna buy the book but I prefer composition over OOP. I prefer to have an init that takes some params where those params are fully baked clients of whatever services I need and then the class just uses them as needed. I don’t see a lot of value in having a Python class that might have a few or more classes that it extends where all the functions from all the classes crowd up the classes namespace. Class Foo.__ini…

Then you're going to be pleasantly surprised, because composition is actually a genuine OOP technique and Sandi Metz advocates for exactly this kind of sane OOP focused on encapsulation and objects making sense, instead of masturbating with class hierarchies.

What’s funny is I did composition for a take home project when interviewing at a place and they said the approach was too complicated and failed me for it. They wanted multiple inheritance instead. Fair enough. Their codebase probably had a lot of it and my not showing it probably told them I didn’t understand it.

Re: 99 Bottles of OOP now available in Python

#45

I’m gonna buy the book but I prefer composition over OOP. I prefer to have an init that takes some params where those params are fully baked clients of whatever services I need and then the class just uses them as needed. I don’t see a lot of value in having a Python class that might have a few or more classes that it extends where all the functions from all the classes crowd up the classes namespace. Class Foo.__ini…

>I’m gonna buy the book but I prefer composition over OOP.

The GoF book (the design patterns book) says in a page right near the start, "Prefer composition over inheritance", in the middle of an otherwise blank page, presumably to emphasize the importance of that advice.

As others have replied, composition is one technique you can use in OOP, not something that is the opposite of OOP.

You can also use composition in non-OOP procedural languages like C, by having a struct within a struct.

https://www.google.com/search?q=can+you+have+nested+structs+...

Re: 99 Bottles of OOP now available in Python

#46
post #24

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 ).

> 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 approac…

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.

Re: 99 Bottles of OOP now available in Python

#47
post #27

Earlier quoted context omitted.

Why on earth do you put composition and OOP as opposing techniques? Composition is just one more technique in the OOP toolbox and there is nothing in OOP that mandates an inheritance based architecture.

Mainstream OOP languages (looking at you Java) have failed to make composition as convenient as inheritance.

How is composition in Java inconvenient?

Re: 99 Bottles of OOP now available in Python

#48
post #24

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 ).

> 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 approac…

OOP is a mental crutch that breaks complex problems down into a easy mentally discoverable world/domain model with objects that have a life of their own, that is capable to derive correct results to complex problems via the relations of the objects.

Meanwhile its creators can not hold the whole complexity in mind (often barely in spec) and still can produce a artifact that produces correct results.

Re: 99 Bottles of OOP now available in Python

#49
post #2

HN's automatic title editing strikes again. The title of this submission should presumably be: "99 Bottles of OOP now available in Python".

Note to anyone who submits an article: If the title gets mangled like this, edit it.

> edit it.

How???

Re: 99 Bottles of OOP now available in Python

#50
post #20
post #4

Previous Discussion Bottles of OOP - https://news.ycombinator.com/item?id=12129821 - July 2016 (71 comments)

that was not for the Python version

I have the book and don't speak Ruby at all. Nevertheless, is so we'll written, that you can take the lessons and apply them in any language with virtual polymorphism. A Python version of the book means bigger audience, to the benefit of the trade.
Post reply on HN