2 ms·
> it’s best for everyone if a problem is identified and called out as close in time to when it’s created as possible, and as clearly as possible. Sure. But it
by lisper 4y ago
> it’s best for everyone if a problem is identified and called out as close in time to when it’s created as possible, and as clearly as possible.
Sure. But it does not follow that it is beneficial for your language to forbid you from testing some code you wrote over here until you fix a completely unrelated problem over there, indeed until you fix every single problem that the compiler can find.
> Doing it manually delays the feedback cycle
I'm not talking about "doing it manually", I'm talking about the compiler issuing warnings instead of errors.
- lazide 4y agoIf you can check in those problems, and make them problems for everyone else - it absolutely is an issue! If the policy is ‘you can generate “warnings” all your want locally, but you can’t check them in’ then sure. The issue of course is folks want to check things in as soon as they ‘work’ in their basic use case, even if it means bypassing a bypassable alert. So it means enforcing it at check-in time, in a non bypassable way (usually), which just means folks have a lot of ‘hidden’ cleanup to do before submitting, while they have their code ‘working’, which is always a drag.
- hbrn 4y agoSuch policies should be defined by the company, not enforced by the language. Even in static languages world, a lot of projects allow dev/nightly builds to be unstable. Which is literally what you're talking about: checking in problems for everyone else. But checking in policy is a VCS/CI domain, not a language domain.
- lisper 4y agoAnd what is to prevent someone from checking in code that doesn't compile?