Live data from Hacker News

99 Bottles of OOP now available in Python

sandimetz.com

21–30 of 93 posts

Re: 99 Bottles of OOP now available in Python

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

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.

Re: 99 Bottles of OOP now available in Python

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

Re: 99 Bottles of OOP now available in Python

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

Code in any form can generate a ton of incidental complexity. The issue isn't the tool rather than the education to properly wield those tools. Especially when you introduce the team dynamic where everyone has varying understandings of what is being built and how it should be built.

Re: 99 Bottles of OOP now available in Python

#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.__init__(self, db, blob_storage, secrets_manager, …)

Instead of class Foo(DB, BlobStorer, SecretsMgr)

Etc

Re: 99 Bottles of OOP now available in Python

#27

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.

Re: 99 Bottles of OOP now available in Python

#28

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…

These are complementary not contradictory ideas. One of the principal takeaways from the Ruby edition (and many of Sandi Metz’s conference talks) is undoubtedly a mindset of, and techniques for, writing compositional OO code.

Re: 99 Bottles of OOP now available in Python

#29
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!

Sandi's earlier book, POODR, was also great. While it is focused on Ruby, most of the advice applies more broadly. Reading these two really helped me understand just how impoverished the concept of OOP has become by C++ and Java, from its Smalltalk roots.

Avdi Grimm preaches a similar gospel.
Post reply on HN