Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

99 Bottles of OOP now available in Python

sandimetz.com

Post reply on HN
Print view View original

31–40 of 93 posts

Re: 99 Bottles of OOP now available in Python

#31

Post by InitialBP »

henning wrote: post #12
PaulRobinson wrote: post #9

Earlier quoted context omitted.

Can you actually give an example? I believe in mechanical empathy. I think developers should - win performance is a concern - think about how their code ends up on the CPU, what ends up on the heap, how caches are used, and so on. But for most Python developers, and Ruby developers, it's more important, in more use cases, to have clear and readable code that is easily maintainable. I've met Sandi, I've gone through h…

Look at the fastest linting/build tools/runtimes for JavaScript. They are mostly not written in JavaScript, because JavaScript is slow and no amount of hotspot profiling/optimization will fix that. This is also why Python's core data types for dictionaries and so on are not implemented in Python. You can also look at any microbenchmark between pure Python and a native language of your choice, even one that uses GC li…

A lot of time (most?) writing software isn't about writing software for the pleasure of doing so, but for building something that helps generate revenue.

For businesses, having a highly optimized web application that takes a long time to develop and doesn't allow for quick additions of new features is not worth the cost. Instead, they can have a poorly optimized web application with way more features and a faster feature production because Python/Ruby/Javascript are more approachable than other native languages.

Re: 99 Bottles of OOP now available in Python

#32

Post by Toutouxc »

gigatexal wrote: post #26

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.

Re: 99 Bottles of OOP now available in Python

#33

Post by lelanthran »

cutler wrote: 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.

And that "ton" is still miniscule compared to front-end development which almost completely eschews OOP and has 10x more incidental complexity.

I guess my point is that, while OOP's incidental complexity is large, it's still insignificant compared to other technology stacks which developers are showing a great appetite for anyway. Things like "incidental complexity" is irrelevant to developers anyway, today, at the tail end of 2024.

IOW, OOP introduces significantly less $BAD_THING, when the clear majority of developers don't even care about the quantity of $BAD_THING in the first place, making the whole "should we use OOP" argument moot.

Doesn't matter if you use it or not, the extra introduced incidental complexity is still going to be insignificant due to the complexity load of the entire project, more so in front-end.

Hence, there's no point in having the argument in the first place.

Re: 99 Bottles of OOP now available in Python

#34

Post by crabmusket »

yxhuvud wrote: post #27
gigatexal wrote: post #26

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…

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.

Re: 99 Bottles of OOP now available in Python

#35

Post by crabmusket »

I'd like to mention that despite OOP being in the title, I thought this book had a lot to teach that isn't specific to OOP architecture or OOP languages. Really, I think the star of the show is TDD and refactoring.

For a short intro to Sandi's style and approach, I always recommend this 35min talk: https://youtu.be/OMPfEXIlTVE?si=Ird6t8uDN86T06Y7

Aside from any specifically educational content, as a talk it is fantastic - funny, smart, well put together.

Re: 99 Bottles of OOP now available in Python

#36

Post by flakes »

crabmusket wrote: post #34
yxhuvud wrote: 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.

The common toolkits today (spring boot, google guice, etc) are much more focused on composition over inheritance, by injecting arguments and implementing pure interfaces rather than extending base classes. Older legacy Java frameworks and bad teachers are more at fault than the Java language itself IMO.

Re: 99 Bottles of OOP now available in Python

#37

Post by crabmusket »

flakes wrote: post #36
crabmusket wrote: post #34

Earlier quoted context omitted.

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

The common toolkits today (spring boot, google guice, etc) are much more focused on composition over inheritance, by injecting arguments and implementing pure interfaces rather than extending base classes. Older legacy Java frameworks and bad teachers are more at fault than the Java language itself IMO.

I take your point, though having `extends` as a first-class language feature surely encouraged that culture and approach in older frameworks right?

Re: 99 Bottles of OOP now available in Python

#38

Post by flakes »

crabmusket wrote: post #37
flakes wrote: post #36

Earlier quoted context omitted.

The common toolkits today (spring boot, google guice, etc) are much more focused on composition over inheritance, by injecting arguments and implementing pure interfaces rather than extending base classes. Older legacy Java frameworks and bad teachers are more at fault than the Java language itself IMO.

I take your point, though having `extends` as a first-class language feature surely encouraged that culture and approach in older frameworks right?

There are some valid cases where extends really can help, and IMO the language would feel limited without it. Maybe if the language designers had their time back they could have taken an approach like Golang with nested structs and syntactic sugar for calling their attributes/methods.

The main reason I see new devs opt for extends, is because that was 99% of the content in their Java 101 programming course, not because it exists in the language. Imagine how many more `friend`s we would have in cpp if that was crammed down everyone's throats? :)

Re: 99 Bottles of OOP now available in Python

#39

Post by chipdart »

cutler wrote: 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 approach that does not use OOP and does not end up with the same problems, if not worse.

Re: 99 Bottles of OOP now available in Python

#40

Post by gigatexal »

Toutouxc wrote: post #32
gigatexal wrote: post #26

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.

I used to work at a flask shop that did views with 3-5 or more inherited classes. Nobody could really follow how everything worked. It was insane.

Anyways yeah give me composition and flat classes all day long.

Post reply on HN