Have you written significant sized code base with dynamic languages (at least > 50K LOC)? If so how do you manage quickly and effortlessly finding errors like bad typo, passing around bad types etc? How do you refactor your code efficiently? My experience is that dynamic languages are great for small size projects but as the size grows the tax of maintaining things grows much faster than for statistically typed languages. People who have worked on large size projects in dynamic languages have to pay very careful attention to unit testing, for example. Little bit of lax attitude and you are looking at dreaded issues that will be uncovered only at runtime.
So genuinely wish to know what best practices you follow that makes developing large projects in dynamic languages make as inexpensive as typed languages to backup your comments.
From my perspective, I don't need to write a 50k LOC monolith codebase in clojure, which has just a few core types. I have become a fan of its `clojure.spec` data validation system if I do ever end up in such a world.
I've written those huge codebases in java, where our weekly github commits pushed like 5-10k lines of code per user. It would have been worse if it weren't for Lombok, and totally untenable if it weren't for IDE-assisted refactoring. I've since worked on much larger and more impactful problems with smaller clojure teams and seen work consistently get done in 1/10th of the LOCs.
I used to be a fan of static types -- I still am in limited contexts, but I've come to realize that statically-typed languages (especially object-oriented ones) usually lead to projects that _require_ static typing to even be maintainable. In contrast, a philosophy common to functional languages (which don't always have to be dynamic) is:
> "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." —Alan Perlis
I think discussions focused around type systems often miss the context of what languages' type systems we're actually talking about, and that context is way more important than making sweeping judgments about types.
I can count _on one hand_ the number of times I've defined a custom type in clojure in the 3 years I've been writing it professionally. Yes, sometimes I've called a hash map function on some kind of a list, but that cost has felt really small (and caught early) compared to the cognitive cost of keeping track of class hierarchies, interfaces, access rules, and annotations. And for what win? I still get NPEs, ClassCastExceptions, and RuntimeExceptions in Java, but now I have a whole class of errors and processes introduced around playing well with its inheritance model.
So, great, it's stopping me from directly instantiating an abstract ApiClient class, and quickly catching that I tried to get an HttpApiClient from an HttpsApiClientBuilder.build() call -- but that pattern would not have existed to present an issue were it a different language
>Have you written significant sized code base with dynamic languages (at least > 50K LOC)? If so how do you manage quickly and effortlessly finding errors like bad typo, passing around bad types etc?
Have you written 50K LOC C/C++? How do you manage finding errors like buffer overflows, use after free, and so on? And did the program have the same functionality as 50K Python, or had 1/10th the features?
(Also: you can run a linter and find typos, and you can have tests and know about bad types. And that's assuming those are actual errors people have and matter in the first place...)
In large sized projects, one of the most frequent activities you do is refactoring. For every refactoring, type errors often constitutes the largest class of errors by volume during initial development phases.
Which is neither here nor there, as a contrived case.
In actual languages people us e(e.g. that have more than 2% of the job market), type errors caught by the compiler don't catch "all computation" errors.
