3 ms·
> it's hard to refactor Python or change a large codebase and have it keep working correctly, so huge Python projects tends to ossify. Although I don't work in
by pizza234 4y ago
> it's hard to refactor Python or change a large codebase and have it keep working correctly, so huge Python projects tends to ossify.
Although I don't work in Python, in general, projects written in dynamic languages can be refactored if they've been developed in a disciplined fashion, that is, with substantial test coverage (I guess that in modern projects, with type checking, the need is significantly reduced). This is not unrealistic (I'm currently worked on a large-but-not-huge project, and it's perfectly possible to refactor), although of course, whether dynamic language with lots of testing is still more efficient (in terms of engineering resources) than static language with less testing, it's another story.
- guenthert 4y agoI was working on a code base where testing was inconvenient (re-striping a large RAID array took hours) and I can think of scenarios where testing is impossible (or at least very costly). Test driven development isn't always the right approach.
- pizza234 4y agoHaving substantial test coverage is a different concept from TDD (which is an approach to software development). It's not clear how restriping an array is related to a test suite, also because if an API is slow to test (e.g. restriping), it's slow with either static or dynamic languages. In general, if a certain API is impossible to automatedly test (this is a common case in both static and dynamic languages, for example, for web services), one stubs the API; with dynamic languages one will be certain that the tested codepaths until the API are correct. With this strategy, the difference with a static language is minimized (or not existing at all).