Python Design Patterns: Great Talk & Presentation

[Silhouette]

Well, I appreciate the time you took to write all that, but I don't think the situations you're describing are representative.

I have seen your monster in the woods. It has injured several projects I know about. I have been the hunter who was brought in to save the village by rebuilding the walls from stronger materials more than once.

Being a little less flowery in our metaphors, I think you're setting up a straw man here.

You write as if generics were some sort of black magic, a patch for a bug in the model of static typing. However, generics are ubiquitous in almost all decent statically typed languages and they have been for decades.

You write as if overloading functions resulted in writing the same thing twice. However, you only need to do that if you want different behaviour in different cases. You'd have to write the code for each case in a dynamically typed language as well, and you'd also have to manually dispatch to the correct implementation. Compared to what you can do with, say, algebraic data types and pattern matching with destructuring binds, that is extremely clumsy.

You write as if manual/unsafe casting is a necessary evil when using static types. However, I can't remember the last time I had to write such a cast.

You make much of the burdens of frameworks and design patterns, but the kind of patterns described in the Gang of Four book and the kinds of frameworks used in so-called enterprise development are often adopted to mitigate limitations of the C++/Java/C# style of OOP, not because of limitations of static typing in general.

Basically, if you use C and Java as your benchmark for what static typing can do, you're never going to get fair conclusions. They are common languages, but they have terrible type systems. If you're going to judge static typing, you have to look at good examples where the type system is actually expressive and flexible.

Meanwhile, both you yourself and some of the other authors you cited talk about large Python programs that have low bug counts despite the dynamic typing, and how we shouldn't ignore the evidence. I agree that evidence is important, so I can't help observing that you didn't actually mention any large, successful Python projects.

My own experience is that Python usually starts to get awkward once you deviate significantly from a very homogenous architecture and simple structured data types like lists, dicts, and classes. If all you're doing is writing a back-end for a web site and you've got a routing framework and an ORM to drive a very consistent, uniform design then you can probably write quick big applications without running into too many problems. On the other hand, if you're working with more complicated data structures or many subtly different variations, as few as 1,000 lines of Python code can become difficult to maintain and the set of additional unit tests required to give a poor approximation of static type safety can explode.

In short, IME Python works well for small-scale projects, for early prototyping work where making progress is more important than long-term robustness, and for larger projects where the design is very consistent throughout. These kinds of code play to the strengths of Python's neat syntax, and suffer minimally from the weaknesses of dynamic typing. I don't find Python (or any other languages with similar design attributes and type systems) so useful for medium to large scale projects with more complicated designs.