4 ms·

I dunno, I think it's fine -- the article never attacks Hamano or calls him a bad person. Criticizing a person's decisions on technical grounds isn't an ad hom

by panic 9y ago

I dunno, I think it's fine -- the article never attacks Hamano or calls him a bad person. Criticizing a person's decisions on technical grounds isn't an ad hominem argument, whether you mention them by name or not.

khazhoux 9y ago
The author personalizes (literally) the problem: The problem is that Junio Hamano made these bad decisions, Junio Hamano wrote this code, Junio Hamano made git worse. And what about the code reviewers, the other people he discussed with, others who could have improved the system? No, it's all Junio Hamano's fault. Elsewhere in codeland we usually say "this code is doing the wrong thing" not "Bob did the wrong thing."
- m0llusk 9y ago
  In the section titled "You or I might have done the same thing" the author says "if I were Hamano, I probably would have made the same mistake". This is about the complexity of growing a new kind of distributed system where best practices are still unsettled. Specific commits and contributors being identified is part of taking this subject seriously. If you are above having your work questioned then you should not be contributing to a big critical part of open source infrastructure.
- cookiecaper 9y ago
  I still don't see a problem with this. Why should Junio not be responsible for the issues in his code? There is no shame in taking deserved blame. Project maintainers are usually pretty used to that, and they're typically their own worst accusers. It's not like someone as storied as Junio, who has maintained git for as long as its been a serious project with applications beyond the kernel, risks being fired because he made a handful of questionable decisions. He is, after all, only human. Only the insecure fret over every shed of blame. It is, in fact, considered rude to circumvent/bypass/ignore the original author by saying "the code was wrong" without first giving the author a chance to explain the rationale. Ultimately, the point at which "naming" transitions into "shaming" in a technical discussion is a matter of interpretation and balance, but I don't think we need to completely remove considerations of code parentage from technical discussions, which you seem to be advocating.

by panic 9y ago

khazhoux 9y ago

The author personalizes (literally) the problem: The problem is that Junio Hamano made these bad decisions, Junio Hamano wrote this code, Junio Hamano made git worse. And what about the code reviewers, the other people he discussed with, others who could have improved the system? No, it's all Junio Hamano's fault. Elsewhere in codeland we usually say "this code is doing the wrong thing" not "Bob did the wrong thing."

m0llusk 9y ago
In the section titled "You or I might have done the same thing" the author says "if I were Hamano, I probably would have made the same mistake". This is about the complexity of growing a new kind of distributed system where best practices are still unsettled. Specific commits and contributors being identified is part of taking this subject seriously. If you are above having your work questioned then you should not be contributing to a big critical part of open source infrastructure.
cookiecaper 9y ago
I still don't see a problem with this. Why should Junio not be responsible for the issues in his code? There is no shame in taking deserved blame. Project maintainers are usually pretty used to that, and they're typically their own worst accusers. It's not like someone as storied as Junio, who has maintained git for as long as its been a serious project with applications beyond the kernel, risks being fired because he made a handful of questionable decisions. He is, after all, only human. Only the insecure fret over every shed of blame. It is, in fact, considered rude to circumvent/bypass/ignore the original author by saying "the code was wrong" without first giving the author a chance to explain the rationale. Ultimately, the point at which "naming" transitions into "shaming" in a technical discussion is a matter of interpretation and balance, but I don't think we need to completely remove considerations of code parentage from technical discussions, which you seem to be advocating.