3 ms·
Our 1 mln line legacy project was written without type hints, often preferring arbitrary arrays with keys, and so: 1) despite having tests, almost every day th
by kgeist 2y ago
Our 1 mln line legacy project was written without type hints, often preferring arbitrary arrays with keys, and so:
1) despite having tests, almost every day there's some bug in production because code expects data X but it receives data Y - this class of bugs is entirely non-existent in strict/static languages
2) to have some degree of control, they added a linter which infers and validates types, but it doesn't catch everything (see #1) and this step takes like 5 minutes - defeating the whole idea of "dynamic languages don't need compilation so you're faster with them", because modern static compiled languages can compile incrementally in a few seconds and you already have 100% type information without waiting for 5 minutes each time
3) refactoring code is very hard, because without proper typing, it's hard to find all instances of usage of data X or property X without manually researching tons of code (data flow); in languages with proper typing, IDE can find it all immediately, but ours fails to catch a lot of stuff
So in the end, in my experience:
1) lack of types allows for quicker debugging/hotfixing if you don't care about data/logic validity (because you don't run tests or linters anyway)
2) you waste more time and suffer more in the rest of the situations
So we started adding type hints all over the place, and banned arbitrary arrays with "magic" keys in public APIs.
I sincerely don't understand people who push against using types, it's like they never worked on large projects in teams, or never maintained a project for more than a few months. Or maybe they have some secret sauce I'm not aware of?