[dropping Larry from Cc because we don't appear to have significant common ground in this discussion]
I had this mentally queued for reply; thanks, Dave, for writing and prompting me to finally shift on it. :) At 2022-12-09T15:52:11-0600, Dave Kemper wrote: > I have no opinion about this particular change, but to address this > general point: I can see both Alex's and Larry's points, as I understand them, on this issue. On the one hand, I agree that without some concrete evidence of groff using strncat() unsafely, it cannot be urgent to refactor away from it. I have multiple times downgraded bug reports from Bjarni, for instance, that raise only theoretical problems. (Sometimes I later discover behavior that makes one non-theoretical, and I raise its severity and go ahead and fix it.) On the other hand, I don't share Larry's effort estimate with respect to tracing the history of code. Notwithstanding any suggestions that BitKeeper was bigger, more complex, more sophisticated, and written and maintained by people with much bigger brains than poor old groff, I have on _many_ occasions traced groff bug histories back to their origins, and I include this information in the ChangeLog when I have confidence in it. Thanks to TUHS, I can dig back even farther than the dawn of our repository's history (groff 1.02) and gaze upon groff 1.01.[1] It does not take me a day, or even the better part of one, to perform this exercise. It's a matter of iterating "git blame", locating a source line of interest, and "git checkout HASH^" (note the trailing caret). I don't think this procedure has ever taken me longer than 10 minutes for any issue--git bisects are often slower simply due to build times--which makes me only half as speedy as one of Larry's non-refactoring engineers, but still far ahead of the day-long turnarounds he dreaded. Because I value clarity, and the removal of absurdities like "internal name" meaning two completely different things when referring to fonts, I regard the trade-off as worthwhile.[2] > On 12/5/22, Larry McVoy <l...@mcvoy.com> wrote: > > I used to run a company that did source management tools and we > > strongly discouraged these sorts of "clean ups" because they change > > the author of that line of code. Our system made it painless to go > > from a line of code to the commit that added that line of code. > > Which, if it goes back to the original commit, is super pleasant for > > debugging. If I have go to your commit, then realize, oh, it used > > to be the commit before that and so on, it takes longer to figure > > out the bug. > ... > > So there is real value to asking yourself "Am I actually fixing a > > real bug?" In languages like C and C++, it can be nearly impossible to answer this question. > While I'm a big proponent of the "if it ain't broke, don't fix it" > school of thought, just in my limited trawling of groff's "git blame," > this already seems like a lost cause. Especially recently, there's a > lot of churn in the source code. I wouldn't say a _lot_... ;-) I did a pull of Texinfo recently, and for a project that was once moribund, it's a hive of activity these days. > If that's representative (which I bet it roughly is, as input.cpp is > pretty central to groff), over 1/3 of groff's code changes do not > affect its operation. I have no idea whether to be proud, ashamed, or simply indifferent to that statistic. Because the behavior of any nontrivial program cannot be exhaustively characterized--well, not easily, anyway, and not without formal methods--it is hard in the abstract to even value operational changes as positive or negative on a basis independent of their intended purposes. > > And it is groff, not some mission critical database. Nearly every change I make to groff is in the direction of improved quality of implementation as I understand it. > > If I were in charge, I veto these sorts of commits and fix the > > problems if/when they arise and have a cleaner history. "These sorts" is a broad and ill-defined classification. We know how these work in practice; the guy in charge is an oracle. Oracles are unreliable; this is why modern technology and medicine are based on the scientific method rather than getting stoned on hydrocarbon vapors in Pythia.[3] The usual way around this to pronounce the oracle infallible, a method that suits chief executives just fine. Larry has demonstrated, for example, that his opinions of groff, insofar as its documentation goes, are not informed ones.[4] I see that there is recent literature on "minimizing guesswork with unreliable oracles".[5] I reckon bosses intuitively figured this out long ago; it's why they cultivate techniques for making their underlings shut up. Savvy subordinates find ways to avoid interacting with them at all.[6] > That knife cuts both ways: because it's not mission critical, the time > it takes to debug problems is less important, so there needn't be any > particular effort to minimize the amount of changes in the history. > (If such effort even has the effect of speeding up debugging: as Alex > points out in his reply, whatever the cost of making a useful > refactoring commit, there is also a cost associated with NOT making > that change, in terms of code readability or comprehensibility. These > can also be impediments to debugging.) Armchair economists usually venture something about opportunity costs at this point in a discussion. Austrian-school types deploy the immeasurable subjectivity of value judgments as a shield against any falsification of their program on empirical grounds, so I will simply that say that it's worth it to _me_ to make groff more robust, better documented, and more helpful when it issues diagnostic messages. On a happier note, if you want a _good_ book about opportunity costs, I recommend John Quiggin's _Economics in Two Lessons_. (His _Zombie Economics_ is more fun, though.) Regards, Branden [1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=Net2/usr/src/usr.bin/groff/VERSION [2] We'll probably ship 1.23.0 with this absurdity because it's only visible when you dig fairly deep into font management. I don't regard my own itches as urgent just because they're mine. [3] Though it would be fair to point out that we moderns are more addled by hydrocarbons than our Athenian forebears could have conceived. [4] https://lists.gnu.org/archive/html/groff/2022-07/msg00182.html [5] https://ieeexplore.ieee.org/document/8437509 [6] https://www.reddit.com/r/EnoughMuskSpam/comments/z2ofwk/i_was_an_intern_at_spacex_years_ago_back_it_when/
signature.asc
Description: PGP signature
