All the Perl that's Practical to Extract and Report
use Perl Log In
jdavidb (1361)
(email not shown publicly)
http://voiceofjohn.blogspot.com/
J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.
A git nit
Yesterday I probably became a git convert. I've already got a long message composed that may become an email to some folks or a journal entry or both about what I think is great. But of course every software has stupidities, and here's one:
The --shared option to git-init has only three possible settings, but you can specify seven different values for it. One of the three settings (with two different names) simply says, "leave this default; don't set this option." This is silly.
It's not the end of the world, but it's silly. It probably didn't cost much to implement this "feature," but it probably doesn't gain anything. What's it supposed to do, make it possible to run the command without reading the documentation? Is that really a good idea? Are the semantics of some of those synonyms going to change some day?
I, on the other hand, got something out of writing this journal entry (which probably cost more than it did for some developer to implement that feature). I got to organize some of my thoughts about software design. I got to think about the TIMTOWTDI principle and muse on whether or not providing more than one name for things is related or not, and carries the same value or not. (I don't think it does; you don't often see Perl provide multiple special variables that do the same thing, do you? Or multiple command-line switches that do the same thing?) And the expected value of this journal entry is even greater to me because there's a chance I might get some insightful comment in reply which I could benefit from.
Speaking of costs, I think another cost of this feature is it makes the documentation more cluttered and harder to read. (Although again, it cost me more to write this journal entry than it did to read that manpage section.) But maybe one of the benefits is it forces people to slow down and read that documentation more carefully. But is that really necessary for this feature? Did somebody measure ahead of time and see they were getting a lot of time-consuming support emails about this?
--Donald E. Knuth
Some context (Score:1)
The configuration item
core.sharedrepositoryused to be a boolean, and backward compatibility is highly valued with the Git developers. So that explains theumask/falseandgroup/truevalues.The
everybodyvalue is a suggestion by Linus, after which Junio anticipated a requesAll that is gold does not glitter...
Re: (Score:2)
Very cool. Thank you for the archaeology work.
Having the possibility to specify an option, even if it is the default does not seem silly to me
It doesn't to me, by itself. It starts to seem silly though when there's seven values you can specify with only three meanings, and two of those values simply specify the default.
Having a little more context now, it still seems like a bad design decision to me that they "anticipated" world, and "threw in" all for good measure, because at the moment, if I'm understanding the docs correctly, those two options have exactly the same semantics as "everybody."
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Re: (Score:1)
allandworldmean something other for thecore.sharedrepositoryconfiguration item doesn't seem like a big loss to me. How wouldallmean something different thanworldin the context of Unix file permissions?All that is gold does not glitter...