[brenden2]

It still blows my mind that people don't use strongly typed languages in the first place and spare themselves from all this future pain.

My guess (based on my experiences) is that companies wind up in this position from having inexperienced people building early versions of products instead of hiring experienced engineers (who are usually more expensive).

[b3orn]

Python is strongly typed, just not static.

[brenden2]

Python uses duck typing: https://en.wikipedia.org/wiki/Duck_typing

I would categorize it as a subset of dynamic typing, and that's what Wikipedia says too.

[rectangletangle]

Dynamic typing vs. static typing is on a different axis than strong vs. weak typing. Python is a strong dynamically typed language, with some "static lite" features introduced in Python 3.

Dynamic typing means that types can be changed arbitrarily at runtime, compared to statically typed languages which define all types at compile time.

Strong/weak means that type coercions rarely/never happen automatically. For instance JS has some interesting behavior enabled by weak typing `[] + [] -> ""`. Whereas Python rarely coerces things for you. The division operator in Python 2 was strongly typed, while they changed it to weak typing in Python 3 (inline with the practicality vs. purity convention).

[tom_mellior]

"strong typing": everything has a type and cannot be accessed at some other type; "static typing": everything's type can be determined statically (according to one definition)

In Python everything has a type, and you can't use a float as a list, for instance. It's correct to call it both strongly typed and dynamic, those are not antonyms.

[ainar-g]

It's a constant struggle against the current. Dynamically-typed languages are often “good enough for the time being”. I have the same issue explaining to our C/C++/Obj-C team why they should use static (Clang-Tidy, Infer, PVS-Studo) and dynamic (ASan, MSan, UBSan) analysis tools. They just keep giving me basically the same response of “I am a good programmer, and my code is good, and shame on you for even daring to think that a mere machine could find bugs in my code!”. I don't know what kind of status anxiety causes it. It also makes me think about what kind of other I am missing because of the was I keep thinking that I do that thing well-enough myself.

[ken]

I'm confused. It should be easy to demonstrate the benefit, if there is one. Just show them the bugs!

For me, it's not "status anxiety". It's simply not worth the effort.

The last couple static analysis tools I ran on my programs, I spent a while getting the tool to not-crash (because even though the authors obviously had a static analysis tool themselves, they either didn't bother to run it on their own code, or it wasn't good enough to find actual issues). These tools flagged only a couple issues, and almost all of them were places where it couldn't really cause any problems, but the type system was not strong enough for me to prove why it couldn't go bad. So I spent a while sorting through false-positives.

I'm not going to spend hours with a tool to find only a couple (real) bugs, which no user has ever reported seeing, and which I've gotten no automated crash reports about. I have much better uses for my time.

[ainar-g]

See, that's another thing that a lot of people don't understand about static analysis. It's not just there to find bugs in existing code, it's there to find bugs as you write or edit the code! Of course it won't find a lot in a tested code base. It's tested after all. But it immensely shortens debug time as you develop, and thus reduces testing time as well.