Hacker News new | past | comments | ask | show | jobs | submit login

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.




The 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.


I 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.


> 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.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: