I find the "I'm more productive with Python" claim in the post to be specious. Maybe I've been abused (and abusive) by bad programming practices with python in

I find the "I'm more productive with Python" claim in the post to be specious. Maybe I've been abused (and abusive) by bad programming practices with python in the past, but it seems you really need to lint and exercise python code to have any kind of confidence that something you think is correct won't blow up at runtime. False confidence that something is "ready to go", is the worst, and it can cost a lot of money, and sometimes human life. Erlang has this problem too. It's so late binding you can make spelling mistakes and it won't be caught until runtime. It's actually the basis of some very powerful features, but you really have to know that coding in Erlang is not like coding in Rust, Haskell, or something else strongly typed. So while I think the author has a point that concretions can get you into an inflexible, hard to refactor mess over time, I think sometimes those concretions don't have to be as bad as they seem. Consider Go. Interfaces are a form of concretion too, but the advice is to keep them small. An interface of exactly one function can be a beautiful thing. I think it's better to have a type implement many interfaces than to have a type implement one huge interface.