3 ms·
Doesn't "tolerant of poor programmers" just mean "even better for strong programmers"?
by jononomo 4y ago
Doesn't "tolerant of poor programmers" just mean "even better for strong programmers"?
- sidlls 4y agoAnd usual it depends on the context. “Strong programmer” practices don’t actually bring much to the table with respect to scientific computing. Regression testing (alluded to above), for example, is actually (mostly) implicit, as future results depend on the continued stable output of past results. If the new code caused the old code to produce different outputs for the new result, it would show somewhere. At least it did when I was doing computational astrophysics in academia.
- BeetleB 4y ago> If the new code caused the old code to produce different outputs for the new result, it would show somewhere. At least it did when I was doing computational astrophysics in academia. For libraries others use, sure. For mere code bases that stay in one professor's team and have been there for 20+ years - not really. As an example, I know one computational group where it often took several hours (possibly days) to generate a single data point in the curve they were trying to produce. None of that team's grad students was willing to waste computational resources to see if their code changes would break prior data points.
- BeetleB 4y ago> Doesn't "tolerant of poor programmers" just mean "even better for strong programmers"? Not sure. BASIC is very tolerant of poor programmers as well.
- lmm 4y agoNo. Do you prefer to consider all failure conditions upfront, or only as and when they happen? When two things are similar but not exactly the same, how much do you want to distinguish between them? Programming language design picks positions on these axes, and the answers for poor programmers and strong programmers tend to be different.