Off topic from the article, but this is something I literally just spent my morning wrestling with and fixing, so I'd like to talk/rant about it a little. My ap

Off topic from the article, but this is something I literally just spent my morning wrestling with and fixing, so I'd like to talk/rant about it a little. My apologies in advance for rambling. You can use doc comments to signify types. You mention you use PyCharm in your article, and it supports doc comments in it's autocomplete and code analysis, I find most popular libraries are commented well enough that PyCharm can understand them. I also always try (and encourage others) to use names that are declarative for both purpose and type. Of course, you can't always rely on third party libraries (or even colleagues) to be so nice, but I find a good name (almost) always removes all the confusion that normally comes from a lack of static typing. For example, one of Codecademy's very first Python lessons includes some code like this: meal = 44.50 tax = 0.0675 tip = 0.15 Which I think is unclear. Imagine these were function arguments. calc_total(meal, tax, tip) is vague. Is meal an object, or a numeric value? (I could possibly see it containing a list of all items in the meal with prices). Tax is almost always a percentage, but what about tip? Judging by the the above values, we can assume a 15% tip, but we don't know if the customer was stingy and tipped $0.15, and by just name alone, we can't tell at all. calc_total(meal_cost, tax_percent, tip_percent) It's now immediately clear to me the type and range of values it accepts. The tip_percent is also an example of when a good name can provide info that even static typing could not, because in either case it is a floating point (please let's not get into a debate about Decimal or currency types :P ). This is a very basic example, but it applies at all levels. Don't call the parameter "users" if the function is not expecting an iterable of User objects. Maybe "usernames" would be better. Etc. But of course, this only helps if the code you're working with is named well. In something like Java, you have better protection and tools when working alongside lower quality code. I also completely agree with you on point #2 about No Static Types. Navigating through my editor is so much easier in a static language than it is in PyCharm with large projects. And the most annoying thing is that autocomplete breaks with ORMs, and most ORM usage is actually flagged as a warning or error. Ugh. I also feel very confident in the automated refactoring in something such as an IntelliJ Java project, or ReSharper, but am apprehensive about using PyCharm to refactor anything with usages spanning more than one file. Same goes for Javascript (or any other dynamic language, I suppose. Those are just the two I use). Enjoyed the posts by the way, adding your blog to my reading list.