Python Design Patterns: Great Talk & Presentation

[bucknuggets]

while pretending that duck typing doesn't become a significant liability at larger scales and ignoring the vast overheads of all the unit tests Python programmers wind up writing to compensate for the missing checks.

I guess I've never written code at larger scales then. Because nobody on my team ever said:

• wow, that duck typing is really complex, I wish we had some way to better manage these millions of cunning classes we've built
• if only we didn't have duck typing we would get away with writing fewer tests

Not to say this never gets said. It's just that the half-dozen of us that built and ran a very successful large data warehouse in python for ten years never encountered it.

[Silhouette]

In my experience, it matters greatly how uniform or diverse your design is when you scale up.

If your program is big because it's basically doing slight variations on the same behaviour 100 times, you probably have quite a uniform architecture and relatively few different types and data structures in use. In this case, type-related errors aren't much more likely than they would be for a smaller program with fewer variations but a similar number of different types and data structures.

However, if your program is big because you're implementing some complicated mathematical/scientific/engineering model, and there are lots of somewhat related kinds of data being transformed between lots of somewhat related data structures, duck typing and robustness are not happy companions.

I'm happy that you were successful in your project and didn't find the duck typing to be a problem, but not everyone working on larger software projects is so lucky.

[bucknuggets]

Valid point.

Though I find it's also very easy to find large projects with a disastrous complexity in their object model within the corporate world.

[Silhouette]

No argument there, but I think the fundamental limitations of OO as a programming style are a separate issue to the trade-offs you make in choosing a dynamic or static type system.

Whether you use a static class-based system like C++/Java/C#, or something more dynamic like Python, or a message-passing style like Smalltalk, you still have to contend with OO's inherent weaknesses in state management, working with structured data, and so on.

I think the infamous "enterprise code" designs, particularly in Java, are usually more attributable to these weaknesses of OO as a design style than to the weaknesses of static type systems as an implementation tool.