|
|
|
|
|
by rspeele
16 days ago
|
|
> Static types are, in a real sense, a compensation for the gap I just described - the gap between the description and the running thing. When you can't easily inspect or reshape the live system, you want the compiler to tell you as much as possible before you cross that gap. I think this underrates static typing. For me the biggest value add of a static type system is that while doing a big, breaking-change refactor, I can near-instantly see all the places I need to update callers. Getting the code to work in the place I was actually working on is easy, I was already focused there. Static types pay off by helping me know when my change broke other parts of the system I wasn't even thinking about. |
|
What the static typing camp can't acknowledge is that not all dynamically typed languages are equal. I agree with your sentiment e.g., on Python codebases - it's legit pain, but PLs like Clojure and Elixir are a different story.
Data-orientation flattens the call graph. Most Clojure functions take and return plain maps/vectors/seqs. A "breaking change" to a data shape doesn't ripple through type signatures across the codebase the way it does when every layer has its own nominal type. You change the shape at the edges (parsing, validation via Spec/Malli) and most intermediate code keeps working.
Fewer, more general functions. map, filter, reduce, get-in, update, etc. replace dozens of bespoke typed methods. There's just less surface area to break. But then again, I would say `(map)`, and someone familiar with Javascript's `map()` would have some wrong assumptions.
You really just can't evaluate ANY language by picking a single aspect of it without wholly understanding the holistic picture in practical, battleground scenarios. Yes, Clojure is dynamic, but it doesn't mean it's harder to maintain or to more difficult to build with, or you just can't write robust software in it. It genuinely has qualities that shine in some domains.
My claim wasn't "static types are useless for refactoring" - it was that they're a compensation for the gap between description and running system. Your refactor scenario fits that exactly: you need the compiler to tell you about distant breakage because you can't cheaply ask the live system "who calls this, and does it still make sense?"
In a live image, that question is answerable directly. find-usages, instrument the function, exercise the path, watch what flows through. The "places I wasn't thinking about" announce themselves the moment they're touched, with real data in hand - not as a list of locations I now have to go read and reason about cold.