Perl Did That First
variousandsundry.com
variousandsundry.com
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.
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.
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.
[0] https://groups.google.com/d/msg/rubygems-org/niS5ZO9DNgk/9gF...
http://www.cpan.org/misc/cpan-faq.html#How_adopt_module
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
"Don't shade your eyes, plagiarize."
It meant the same thing you said. Lots of what you are trying to do has already been done, reuse it.
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.
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.
Nobody from the Go team, that is true.
My point was about some Go newbies and their respective blog posts advocating the language.
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.
I think CPAN and co could use an infrastructure update.