I am not sure how constructive posts like these are. We all stand on the shoulders of giants.
That said, the longer I code, the more borrowing from the crufty old langiage/system/community/technology I see in the "shiny new thing", even if many folks slam the old entity.
The constructiveness of this is that people trying to find a solution for an already solved problem can easily take from them the solutions already implemented; instead of struggling through making their own solution. "Stealing" is highly recommended and looked upon favourably by Perl people.
And as you say, it also serves to show newer programmers that there is no need to badmouth older languages, there is only to learn.
> trying to find a solution for an already solved problem can easily take from them the solutions already implemented
The 'solution already implemented' in this case seems to be 'Email the PAUSE admins who will deal with each case individually'. It seems kinda condescending to imply that 'have more volunteers' is something that the ruby community just hasn't thought of; as if projects short of manpower just need to learn from the wisdom of the perl community in just, y'know, having more.
One of the main motivations for Benjamin to write his post seems to have been the reply in the initial thread from the Rubygems admin saying "I want these decisions to not be on my (or anyone's) shoulders. It's stressful and nerve-wracking if I get it wrong"[0]. Given that, a reply saying, essentially, 'What's the problem, just get the RubyGems admin to make the decisions' seems.... unconstructive at best.
In short: Make an account, email admins and cc author, then shotgun every place the author's likely to see your intent, then wait a few weeks, and if your efforts have been clear, and the author unresponsive, admins will transfer rights to you.
Typically following this procedure results in the original author reacting, and if they don't, then there's nothing wrong or nerve-wracking about a transfer. CPAN has a big body of history pointing to this working just fine.
Besides, if i interpret this right that the number of rubygem admins is low enough that simply handling such a simple matter would be a problem, then you have bigger fish to fry.
----
Edit: Then again, Benjamin admits that his post doesn't solve:
> deal with gems whose owners are AWOL
Which is the real problem, and the solution to which solves pretty much all other cases too.
You see this a lot in some Go newbies that never used the Mesa/Modula-2 family of languages or any other language with native code compilers besides C and C++.
Suddenly, language features known outside C and C++ world in the last 40 years, become new shiny features.
Compilation speed. Production quality native code compilers for modular languages always compiled quite fast. Just as an example with Turbo Pascal 4.0 (the first version with units) you could "fix 1 compile error->compile->fix next error" in just a few seconds.
Static binaries. Something any native code compiler should be able to do.
Method declaration syntax. Goes back to Oberon-2 (1991).
Most of the other stuff is a refinement of previous Rob Pike languages Alef (1992) and Limbo (1995).
Some people use coroutines, cooperative threading, channels etc. for years. In fact, the whole Solaris OS threading model was build around some of these features.
Nobody really claims any of Go's features are new in any way. And yet, Go put them together in a fashion that attracts developers because it is put together in an absolutely easy to use way.
There's this wonderful comparison of Go and Algol-68, actually meant as "Go is boring" criticism, but it really shows that Go has all these exciting features that have been around for several decades, and yet nobody bothered to implement them, integrate them and popularize them until the Go development team did so.
Could you link the comparison ? Can't find it with simple searches.
About the "Go is boring" thing, I also tend to think of Go as a boring language... but no more than C or Java. I feel it more like a "new but not so much" effect which I found it disappointing. By no mean it imply that's not a practical and useful language. In the end, the project and the code-base count more than the language itself.
That was published just about a month or two after Go was first released, it contains syntax errors (like the placements of curly braces), and Go has moved on significantly since then.
Condescending tone aside, what I read as being proposed for Ruby isn't the same as what is being shown for Perl.
In Perl, a dev says "Huh, I don't think this is being maintained properly", and then proceeds to contact the original author, and failing that, a set of admins.
The Ruby proposal, on top of that, allows a dev who is abandoning a project to mark it as such, and that then is individually findable or noticeable. This is actually a rather more interesting approach, as it means those downstream know when a library they're using is being abandoned, and can decide -immediately- what to do about it, from switching to another library, up to and including taking ownership of the existing one. The community can have a proactive notification of abandonment, if you will.
While I agree with a majority of the posts, I have some reservations - uploading to CPAN and PrePan is not as simple as a git push. Registering through PAUSE and then properly uploading to CPAN with a zip file through their UI or through FTP.
I think CPAN and co could use an infrastructure update.
That said, the longer I code, the more borrowing from the crufty old langiage/system/community/technology I see in the "shiny new thing", even if many folks slam the old entity.