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

61–70 of 93 posts

Re: 99 Bottles of OOP now available in Python

#61

Post by lioeters »

corytheboyd wrote: post #59
nailer wrote: post #52

Earlier quoted context omitted.

A. OOP as practically implemented for the last 25 years is glueing functions to state B. Functions and structs.

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

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.

Re: 99 Bottles of OOP now available in Python

#62

Post by chipdart »

nailer wrote: post #52
chipdart wrote: post #39

Earlier quoted context omitted.

> 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. OOP as practically implemented for the last 25 years is glueing functions to state B. Functions and structs.

> A. OOP as practically implemented for the last 25 years is glueing functions to state

I see you opt to go with a huge amount of handwaving over the question.

> Functions and structs.

That's what a class is, and thus OOP, except it supports information hiding and interfaces. So your alternative to OOP is... OOP?

Re: 99 Bottles of OOP now available in Python

#63

Post by darrenf »

randlet wrote: post #60
hansvm wrote: post #54

Earlier quoted context omitted.

Here I was assuming bottles might fit nicely into the Flask ecosystem.

There's already a bottle web framework [1]. It came out around the same time as Flask I think. It might have even started as a spoof of Flask even? Or vice versa? [1] https://bottlepy.org/

IIRC, it's vice versa. Bottle predates Flask by a few years I think.

Edit to add: Bottle's own FAQ says so: https://bottlepy.org/docs/dev/faq.html#what-about-flask

Re: 99 Bottles of OOP now available in Python

#64

Post by chipdart »

lioeters wrote: post #61
corytheboyd wrote: post #59

Earlier quoted context omitted.

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

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.

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

Re: 99 Bottles of OOP now available in Python

#65

Post by Joker_vD »

chipdart wrote: post #62
nailer wrote: post #52

Earlier quoted context omitted.

A. OOP as practically implemented for the last 25 years is glueing functions to state B. Functions and structs.

> A. OOP as practically implemented for the last 25 years is glueing functions to state I see you opt to go with a huge amount of handwaving over the question. > Functions and structs. That's what a class is, and thus OOP, except it supports information hiding and interfaces. So your alternative to OOP is... OOP?

I suspect "functions and structs" here meant "functions and structs, separately, instead of gluing functions together with structs into unholy amalgams". Basically, Wirth's "Algorithms + Data Structures = Programs" idea.

Compare e.g. to "What should a language have instead of Lua-like tables? Maps and vectors" — "But that's what a table is, so your alternative to tables is... tables?"

Re: 99 Bottles of OOP now available in Python

#66

Post by bnchrch »

lelanthran wrote: post #33
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…

Is your argument that

1. its ok to add incidental and unnecessary complexity

2. so long as it's less complex than your most complex component?

Because that's a formula we can all agree leads no where good nor productive.

Re: 99 Bottles of OOP now available in Python

#67

Post by jdminhbg »

amelius wrote: post #55
codetrotter wrote: post #21

Earlier quoted context omitted.

It definitely took me quite a bit of time from I joined HN until I learned that if you edit your submission title then you can override the automatic edits that HN makes to the title you originally submitted. And I would guess that likewise there are still a lot of people that don’t know this. Also, sometimes one might not realize that the title got changed until it’s too late to edit the title of the post.

I wish HN could just take the url and then fetch the title of the page. That would save quite a hassle, especially on mobile.

In this case, the missing '99' isn't a typo, it's deliberate by HN to eliminate clickbaity headlines like '7 Ways To Be A Better Programmer.'

Re: 99 Bottles of OOP now available in Python

#68

Post by bccdee »

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.

But I've read the book, and her solution to the "bottles of beer" problem involves encoding all the logic into an elaborate class hierarchy!

I'm not rabidly anti-OOP, but the point at which I turn against it is when the pursuit of "properly" modelling your domain with objects obscures the underlying logic. I feel like this book reaches that point. This is her stance on polymorphism:

> As an OO practitioner, when you see a conditional, the hairs on your neck should stand up. Its very presence ought to offend your sensibilities. You should feel entitled to send messages to objects, and look for a way to write code that allows you to do so. The above pattern means that objects are missing, and suggests that subsequent refactorings are needed to reveal them.

Absolutely not! You should not, as a rule, be replacing conditional statements with polymorphic dispatch. Polymorphism can be a useful tool for separating behaviour into modules, but that trade-off is only worthwhile when the original behaviour is too bloated to be legible as a unit. I don't see an awareness of that trade-off here. That's my problem.

Re: 99 Bottles of OOP now available in Python

#69

Post by jonathaneunice »

lastofus wrote: post #5

This is one of my favorite software development books of all time. It's the book that finally offered straight forward guidance and wisdom on how to properly utilize OOP language features. I'm very happy to see it out for Python!

Concur. I took Sandi's workshop based on the 99 Bottles book, in Ruby with a Ruby crowd, but was immediately able to apply it to Python programming.

Very helpful and clear thinking about refactoring out complexity—and not just refactoring for its own sake, but under the constraint that you want to move your program forward, add new functionality, etc. Refactoring with a direction, purpose, and direct payoff.

Re: 99 Bottles of OOP now available in Python

#70

Post by nineplay »

chipdart wrote: post #64
lioeters wrote: post #61

Earlier quoted context omitted.

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.

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

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

Post reply on HN