> the better programmers (the ones that know how not to couple shit) favor dynamic typing while those that regardless of experience haven't learned how to keep

> the better programmers (the ones that know how not to couple shit) favor dynamic typing while those that regardless of experience haven't learned how to keep coupling at bay prefer static types. I don't agree with this. Static typing is the stronger sense (than C or C++) is mostly represented by: - ML - oCalm/F# - Haskell - ADA Coupling is not idiomatic on them. This is mixed with the functional + inmutable aspect (not much on ADA, but as someone that used to work on pascal is not the mess of the C family...), but certainly coupling is WAY higer on JS/Python/Ruby. By TONS. And certainly less skilled developers code on them. By orders of magnitude. Haskell scare people. Python not. And that is despite the fact I totally love python. I don't say python is bad. Skilled developers totally love pytyhon too. --- What I think is better to say, assuming always a capable programmer: - A good programmer can program good. - A good programmer prefer to use better tools, if posible - A good programmer wanna do things faster (also, to make programs faster, but let's focus only in his own productivity) But exist two ways! to do this: - A good programmer love dynamic typing because he can manipulate the program in do things past what is obvious. He can do complex stuff easy. But it miss the simple stuff OR - A good programmer love static typing because he can avoid to worry about trivial things, like always check if something is null, look at the documentation/code to see what is returning, etc. So he can focus in the complex stuff. However, do certains kinds of complex stuff make him wish to use something else. However, I bet MILLON TIMES that truly everyone wanna: - To have both static types for the code that is in the past/stable and dynamic for now. Static when things are settle and dynamic when not. And move between boths with fluidity so he can construct things on runtime and then get back on tracks for the stuff that not need to change!