Metacpan is great, why continue with a double effort that needs a rewrite. It has served the community well for many years.
The end of an era: Saying goodbye to search.cpan.org
11–20 of 125 posts
Re: The end of an era: Saying goodbye to search.cpan.org
#12Many thanks to Graham!
search.cpan.org was invaluable during my college senior projects in 2002 and much more so in my first gig. Back then I couldn't imagine being a Perl dev without it.
FWIW I can't imagine a better way to transition a project. Kudos to the MetaCPAN team!
Re: The end of an era: Saying goodbye to search.cpan.org
#13This is truly a down moment, to be sure, but it's pretty telling that the site became too hard to maintain because it's written in old Perl. I'm not a Perl hater. I like Perl! I got my start in Perl and spoke at a YAPC::NA a few years ago. It's telling, is all I'm saying. It tells us something.
It could be more about MetaCPAN just being better. Or the maintainer looking to move on for other reasons. Not worth the maintenance for a variety of reasons other than that it is made out of Perl. I’m assuming MetaCPAN is written in Perl, at least in part. But I’m on mobile and I don’t want to research right now; I could be wrong. Edit: also, 2005 era Python or Ruby, for a website, would likely be unpleasant to main…
The backend API is indeed (modern) Perl and the repository is here: https://github.com/metacpan/metacpan-api
Re: The end of an era: Saying goodbye to search.cpan.org
#14This is truly a down moment, to be sure, but it's pretty telling that the site became too hard to maintain because it's written in old Perl. I'm not a Perl hater. I like Perl! I got my start in Perl and spoke at a YAPC::NA a few years ago. It's telling, is all I'm saying. It tells us something.
It tells is, that the world changes and we evolve on different dimensions.
For one there are features added and need by users change.
Additionally paradigm usage changes over time. Sometimes doing more OOP is modern, nowadays people want to be more functional.
Thirdly deployment changes ("Microservices" etc.)
Maintaining an old code base is always work and if you don't have a dedicated team doing refactoring continously you have a hard time to keep it up2date.
... Not to mention that all this is probably using third party modules which may change ... or not be updated.
Re: The end of an era: Saying goodbye to search.cpan.org
#15Countless hours saved. Countless discoveries made. Goodbye search.cpan.org.. It was a fun run.
Re: The end of an era: Saying goodbye to search.cpan.org
#16This is truly a down moment, to be sure, but it's pretty telling that the site became too hard to maintain because it's written in old Perl. I'm not a Perl hater. I like Perl! I got my start in Perl and spoke at a YAPC::NA a few years ago. It's telling, is all I'm saying. It tells us something.
It tells us that a solo maintainer of a large project - with no assistance from the community possible, because closed source - trying to do it in his spare time, will eventually result in a massive accretion of technical debt.
It's a testament to Graham's productivity that he was able to keep maintaining it for so long in spite of those disadvantages, and says very little about perl.
Re: The end of an era: Saying goodbye to search.cpan.org
#17Wow.
I'm still thankful to that site for helping me find the incredibly useful SSH::Batch library. Whether you're using Perl or not, it's an incredibly helpful command line tool for simple operations on multiple machines.
Never would have found it without search.cpan.org.
Re: The end of an era: Saying goodbye to search.cpan.org
#18Since metacpan.org has been around, I've always hated search.cpan.org.
Case in point, at a previous employer, a contractor was tasked with integrating Jira with an existing hacked together monitoring system in order to 'automatically' create trouble tickets. Not hard to do, but the problem is he just googled 'perl soap' (since the jira api was SOAP). Which lead to a soap package on cpan.org, and it (the google index) didn't even show the latest version but a tarball version from 2001 (this was in 2012) which he installed manually.
Fast forward a few months and randomly the tickets that this perl script was creating in Jira were sometimes only have filled out and full of gibberish. It was quite the head scratcher to figure out, but in the process I noticed the super old SOAP package installed, I updated it via cpanm and all the problems went away. Apparently the old soap version didn't even have support for UTF8 and that was the issue (the script actually copied comments from employees in the other monitoring system and some new employees were given new laptops with Win8 that for what ever reason was sometimes using the UTF8 version of non breaking space chars...)
Re: The end of an era: Saying goodbye to search.cpan.org
#192005 era Perl is still Perl 5. It might not be using the more modern extensions, but it's not like it was written in Perl 3 or something.
I wonder if they were building the pages in the CGI module directly? That was pretty common back then but has been depreciated for a few years now, although it still works for now.
Re: The end of an era: Saying goodbye to search.cpan.org
#20Not a knock against the people who created metacpan, but it is interesting how much faster search.cpan.org is than metacpan.org when displaying basically identical information on module pages. The page load time is consistently about 5 to 10 times faster on search.cpan.org on the first load of a page, though subsequent loads are faster on metacpan, so they must have some caching in front.