4 ms·
Its interesting, this is a similar learning Clojure came around with, that the types weren't really useful unless everything is typed. Though Typed Racket's sol
by didibus 9y ago
Its interesting, this is a similar learning Clojure came around with, that the types weren't really useful unless everything is typed. Though Typed Racket's solution was to promote types to runtime validation at those borders between things with types and things without.
I do find it intriguing though, that adding back types manually is so hard and slow. Is it slower when done retroactively? Or is it just as slow when done at the same time, but we don't realize its overhead?
- lmm 9y agoIt's a lot slower to do retroactively. You basically have to tell the computer why you believe something is correct - e.g. if you're moving to having a distinct type for non-empty lists because some functions are only valid for non-empty lists, you have to explain why you believe a list you're passing to such a function is non-empty. That's a lot easier to do at the same time you're doing it (even in Python you'd probably still ask yourself whether you knew the list was non-empty as you were writing it) than to come back months or years later and remember why.
- mratzloff 9y agoIt's slower when done retroactively. A developer writing typed code has the problem domain and software design unmarshaled into his brain while writing his small section. Type testing occurs concurrently with feature testing. Types added retroactively need to be applied to a large codebase and undergo separate testing.