4 ms·
I've heard that argument before, but I've never seen that sort of behavior in practice. If anything, statically typed (or heavily annotated) codebases I've work
by zbentley 8y ago
I've heard that argument before, but I've never seen that sort of behavior in practice. If anything, statically typed (or heavily annotated) codebases I've worked on have been much more amenable to change when it comes to adapting to "code that doesn’t neatly fit the puzzle’s constraints" as you say. The refactoring tooling and assurances provided by the type system tended to make people more willing to start rethinking their "puzzle" (type design) earlier in the process, rather than doubling down on a flawed model.
I've seen people do similarly great work in highly dynamic languages, too, so this isn't a "static > dynamic types" statement; just an anecdote in contrary to your claim.
- keymone 8y agoThe puzzle is not some inherent problem within the one you’re actually solving, it only arises because of limitations of any type system you choose to work with.
- zbentley 8y agoI don't think that's true. But even if I did, it doesn't address my point above that, in return for having to solve the "puzzle", programmers in more strongly-typed languages gain numerous other advantages.
- keymone 8y ago> in return for having to solve the "puzzle", programmers in more strongly-typed languages gain numerous other advantages advantages and disadvantages. and solution to the puzzle is almost always wrong or becomes outdated and requires major rethinkings often.