I don't understand why the author felt so defensive about accepting packages. As far as I can tell, they've always had this attitude.
Why even make a project open source if you don't want to consider patches? The whole idea is that even if you think a thing is boring, someone else may not and they'll do that work for the community.
Weirdly, this is now some kind of grave affront to the maintainer who appears to take the idea that a compiler check could be added to their general framework as an insult.
This is a false dilemma - making a project open source can have plenty of motivations besides "I want to be a project manager for free!". Some other motivations:
* Someone may find this useful even if I don't ever touch it again.
* This could show others an example of a different way to solve a problem.
* This is cool, look what I did!
* Github is a free host, and there's no reason to keep this private.
* I just need some code I wrote in a public place for hiring managers to peruse.
But isn't it also a false dilemma to suggest that the only lens by which you accept PRs is in the role of "project manager?"
> Other reasons offered
Sure but those are hypothetical. That's not what was going on here. The author of this diatribe was actively soliciting patches and maintaining the project publicly.
We certainly aren't coercing him to take a role he didn't want (at least initially).
Here's an analogy for you. When you pour yourself a glass of pop, and you over-pour - do you then pour the drink back into the bottle?
I know some people that would return that drink to the bottle, and some that would rather pour that little bit into the sink. Those that would "backwash" believe that the bottle will be fine - sure, you've maybe transferred a little bacteria in, but it probably won't cause any problems. Those that throw it away believe that the hygiene of the bottle - even from a clean glass - would otherwise be compromised.
So if you come to my battle-tested codebase, and tell me "Hey, I've made you code better. It now has a theoretical metric of cleanness, instead of your proven metric of cleanness" - you may well have just introduced a bug. I now need to test your code, ensure it meets my real-world standards of cleanness. And maybe it does! Maybe your code has fixed a glacially-slow memory leak, but I won't see that. Maybe your code has introduced a complex interaction that none of my examples exploit, but other people's examples blow up because of it.
Maybe the bottle of pop will be fine. Maybe in a couple of days time, when I have guests over, the unhealthy layer of scum floating in my mother-in-law's glass will make me look bad.
Either way, it's a lot of work, and little certainty, and only theoretical benefit - vs no work, and full certainty in the real-world correctness of my code.
And it's a question of which do I value more - my big bottle of pop, or the dribble you'd rather give me back.
> So if you come to my battle-tested codebase, and tell me "Hey, I've made you code better. It now has a theoretical metric of cleanness, instead of your proven metric of cleanness"
The flaw with this is that just running code in production for a modest amout of time proves nothing. That is in fact the opposite of proof, it's an anecdote. Safe code from a sound compiler can be literally proven to hold certain properties, with a margin of certainty that depends on then compiler.
Now of course, the proof guarantees of the specific code in question are weak compared to what you can do with something like Liquid Haskell or Idris or Coq, but they're definitely more than this pride-based programming you're holding up.
> Maybe your code has introduced a complex interaction that none of my examples exploit, but other people's examples blow up because of it.
And maybe your code already had that. That's why I trust compiler checks a hell of a lot more than people. And that's why I find this entire movement of pride-based programming that you and the subject of this thread so problematic. You're just holding up your haphazard experience as evidence. And honestly, not many people's experience would move me that way. Maybe if you're running it as Google or Facebook's frontend I'd find that reassuring, but short of that...? No.
Have you load tested your software? How did you simulate it? Have you validated your algorithm with a tool like TLA+? Have you watched your memory use carefully? Have you measured the latency variance? Under what kinds of loads? Is your data real or a projection using something like USL4J?
> Either way, it's a lot of work, and little certainty, and only theoretical benefit - vs no work, and full certainty in the real-world correctness of my code.
Pull requests on GitHub are generally the click of a button. If they're not good on grounds of completeness, then reject them on those grounds. Not, "Oh here we go again this code is so much more mechanically verified than mine, don't start this again."
I'm absolutely not talking about pride. That's a straw man - nowhere in my answer did I discuss a person's pride. I'm a big proponent of egoless programming (as far as any human being can) and while I have no idea whether ego came into this, pride is not the only reason a person might reject these kinds of patches.
That said, ego is a great reason for you to dismiss valid arguments, so I'm guessing you've made up your mind.
> The flaw with this is that just running code in production for a modest amount of time proves nothing. That is in fact the opposite of proof, it's an anecdote. [...] proven to hold certain properties [...]
You've just made exactly my point, but from the opposite side. You are saying that Safety, and those "proven properties" are of higher importance than being bug-free in the real world.
The issue is that it is impossible to prove that code is correct via tools. You can prove some properties, but you cannot prove fitness for purpose.
> Have you load tested your software? How did you simulate it? Have you validated your algorithm with a tool like TLA+? Have you watched your memory use carefully? Have you measured the latency variance? Under what kinds of loads? Is your data real or a projection using something like USL4J?
Generally speaking, I have no idea. In this scenario, I know the project owner has done some performance testing, so maybe. But honestly, I've no idea what you're trying to argue here.
> Pull requests on GitHub are generally the click of a button
This seems like a big flip from the previous statement. No, Pull requests on GitHub for a trusted and depended-on project are NOT a single click. If that is how you run your open source PR pipeline, very quickly your users will not trust you.
You don't know its bug free. You're saying you haven't seen obvious bugs. That may work for you, but I try to gamble as little as possible when it comes to code.
But even if we ignore safety, you're also skipping expressiveness and more self-evident code for what?
You're not qualifying your "real world experience" with any sort of alternative rigor that might represent some sort of nod to modern practice. Until you do, you're shouting "I believe in this because of my pride."
You can deny that characterization, but that's what it is.
> Generally speaking, I have no idea. In this scenario, I know the project owner has done some performance testing, so maybe. But honestly, I've no idea what you're trying to argue here.
As opposed to your "pop" metaphor, you think asking for some demonstration of rigor is confusing? Well... The world is full of different ideas I guess.
> No, Pull requests on GitHub for a trusted and depended-on project are NOT a single click. If that is how you run your open source PR pipeline, very quickly your users will not trust you.
You didn't read very carefully if this is your takeaway and I won't entertain a straw man. Perhaps next time spend less time on a labored "pop" metaphor?
> You don't know its bug free.
And I haven't said that I did. What I have said is that - unless you give some evidence to the contrary - I'd rather trust the code as it stands, to new code that hasn't had the same amount of airtime. So if there is a known bug, and your bug fix ALSO introduces some correctness, then brilliant! I applaud your girl/boy scouting. If you are rewriting someone else's code because you don't like it on a philosophical level - however much the community appreciates this philosophical viewpoint - the project owner is under no obligation to gamble on your new code, and is right to accuse you of hubris, self importance and a lack of any kind of empathy.
> You're saying you haven't seen obvious bugs.
No - I'm saying you haven't seen any proven bugs. I'm saying that care and attention has been made to eradicate the bugs that were in the first versions of the code. With every code change you make, every line of code has a 1-in-X chance of containing bug(s) (that X varies from language to language) so if you change a lot of lines, unless the code is _really very very_ broken, the more lines you add, the greater the likelihood that you're adding bugs.
> That may work for you, but I try to gamble as little as possible when it comes to code.
I think I've made the point above, but in case I haven't: Both choices are gambles. One is a gamble with the evidence to back it up, the other is a gamble on something that has next to no evidence at all. One is the pragmatically certain choice, the other is a lot of risk with no known reward (in this case).
> But even if we ignore safety, you're also skipping expressiveness and more self-evident code for what?
I can't answer that. That is a very very good question. But not asked as hypothetical question - ask it for real. What has the original developer gained? Why is that more valuable to them than enhanced memory safety? Why does the original developer believe this code to be safe enough? Until you ask this question and can answer with certain knowledge, you have not earned the right to rewrite his code.
> You're not qualifying your "real world experience" with any sort of alternative rigor that might represent some sort of nod to modern practice.
Oh, I'm sure the original code had no behaviour-driven tests, single-character method names, that the original author reimplemented GOTO just to get the thing to work.
> Until you do, you're shouting "I believe in this because of my pride."
> You can deny that characterization, but that's what it is.
I'm happy to assume that pride did come in to it. The original author is proud of their work, the new author is proud of theirs. Great. But making a work that only exists to trample on someone else's decisions is crappy behaviour, unless you can prove that your change actually fixes a real problem.
And I do deny the characterization, but only in the sense that you have some kind of weird fixation on this as the only conclusion. I've been making an argument for pragmatism - the pragmatic choice is to ignore the rampantly self-assured meddler.
> As opposed to your "pop" metaphor, you think asking for some demonstration of rigor is confusing? Well... The world is full of different ideas I guess.
You can ask for a demonstration of rigor, but as I pointed out previously, I'm not in any position to give it. I don't know what he did or didn't do to the code. My question is, why does that actually change the gambles above? Are you saying that the author of the pull review DID do all this? Are you saying that the project owner, working in his spare time for free on a project used by thousands who are probably making money from it, should be required to implement this level of testing? Your statement was presented without any context, which is why I was confused.
But here's the rub: Absolutely none of the strategies you mentioned can guarantee correctness in the real world! None of them. Sure, they can help. Maybe they'll make that 1-in-X bugs-per-LOC turn into 1-in-2X, or 1-in-20X. But they won't fix a fundamental misunderstanding on the way a method should work. They won't tell you that some client code is now broken because you introduced an assumption that wasn't in the original code.
What they will do is reduce the amount of time that the original author has to spend with their family, because they now need to test your code change for all the bugs and bad assumptions that the original author probably made the first time they wrote the code, and a few more beside. Maybe they do now have to rewrite their TLA+ constraints, rerun their benchmarks, etc.
The original author might be willing to use his spare time to make his codebase work better. He does not have to spend that time massaging your pride because you rewrote his code because you knew better.
>>> Pull requests on GitHub are generally the click of a button
>> No, Pull requests on GitHub for a trusted and depended-on project are NOT a single click
> You didn't read very carefully if this is your takeaway and I won't entertain a straw man. Perhaps next time spend less time on a labored "pop" metaphor?
I'm not seeing how this is a straw man. You were minimising the effort that goes into PRing... I pointed out that lack of effort in PR process is bad... you shout straw man and try to insult me?
Hey - I'm just trying to give you another perspective here. If you're not a fan of analogies, that's a shame, sorry you feel that way, some people find them useful. You started this by saying:
> I don't understand why the author felt so defensive about accepting packages.
The guy basically flat-out said that the problem was with entitled idiots who think they know best rewriting vast swathes of code without understanding the original decisions.
Since you didn't understand that, I gave you an allegory. If that doesn't help, and this doesn't help, well, don't know where we can go from here.
It was a metaphor, not allegory. And literally no one understood it. I only saw your comment because I was briefly reminded of this discourse after some other community sites found your attempt at metaphor and mocked it in front of a wide audience.
Not the outcome I was hoping for, but I hope that the exposure helps you get your message of "I do what I want and don't have to prove anything to anyone" when writing code. I look forward to seeing how that helps your professional reputation.
That's what he is doing: simply walking away.
But he doesn't owe you anything, and that'exactly what you are getting.
It's astonishing how some people feel entitled to other people's life work. It's like you believe others owe you everything just because you like their work.
I certainly think he had the right to do what he did, and the people who were rude deserved to have the door bricked up, but the people who read the notices he put up before hand about how he was holding open the door and it was a good way into the house might feel he is sort of a jerk.
If you're interested in the project you can still access the source code.
Hell, the author asked for volunteers to pick up where he left off.
Yet, you're only complaining that he is no longer working for you and complying with your personal whims.
That's the problem. A guy volunteers himself and donates his expertise and work to give you a gift, and in return some moochers just want to mooch off of him and, worse, attack him for not complying with their whims.
>> the author even asked for volunteers
citation needed
This obviously means also that he has not given me a gift.
Finally I am not sure what reasoning has led you to assume that if he gave me a gift moochers would want to mooch off of him, and how they would do so by virtue of him giving me a gift. Whatever reasoning it was, I'm forced to think there must have been little of it.