4 ms·

> which means it's much harder to apply any sort of rigor, and much harder to get an actual result. But that shouldn't be an excuse to stop trying! By this com

> which means it's much harder to apply any sort of rigor, and much harder to get an actual result. But that shouldn't be an excuse to stop trying! By this comment, if you program, I sincerely hope you've never written a buggy line of code in your life. As well I expect you have fewer bugs per line of code as your programs get larger and more complex. As well I'd expect your code experiences the opposite of "code rot" the more changing requirements you receive.

TeMPOraL 6y ago
Of course I make bugs! But I strive to make less of them. For instance, after I've reached programming maturity (i.e. the stage at which I'm not attached to a specific language, but are proficient in several, and can do basic work in any language you ask me to), I've learned to appreciate and make use of strong typing, precisely because it lets me add more (compiler-checked) rigor to my code. Even my Common Lisp code is as typed as the type system will allow me to (which is quite much). Programming this way is still difficult and fuzzy, but a little less fuzzy. Same with embracing certain styles and patterns of programming, that all help to narrow down the scope of things any piece of code could be doing at runtime. I stand by my point: the more difficult your field is, the more care and rigor should be used in approaching it, if you care at all about making some kind of definitive statements about something that can survive the test of time.