Not 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.
The end of an era: Saying goodbye to search.cpan.org
41–50 of 125 posts
Re: The end of an era: Saying goodbye to search.cpan.org
#42Earlier quoted context omitted.
If you're gonna compare to 5.9.2 (a dev version) then the newest Perl 5 is 5.27.11 with 5.28.0-rc1 having dropped after this announcement. Doesn't change the relevance of your point but the internet is a pedantic place.
Thanks (I don't know much about perl versions really, just did a /2005 in perlhist).
Re: The end of an era: Saying goodbye to search.cpan.org
#43This 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.
How many PHP websites still work, if they have been in unmaintained since 2005? Can you imagine how many bugs you can find in a 2005 WordPress site? Or PHPNuke?
For the most part you can take any Perl 5 code written in the last 20 years and just swap out the interpreter for a new one, and your code will run more secure, more stably, and faster (the list of actual deprecations that require change is generally.very small, if anything). It's a double edged sword though, as that back-compat legacy is not easily discounted when a change is proposed that would make modern Perl better but break older Perl. It's one of the reason the language is slower to adopt features than many others.
Re: The end of an era: Saying goodbye to search.cpan.org
#44This 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.
So like on the one hand, old perl is basically unmaintainable punctuation vomit, but on the other hand, there’s a lot of 10 year old perl code out there just chugging a long, which is nothing to sneeze at.
Re: The end of an era: Saying goodbye to search.cpan.org
#45Not 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.
The new site's search results are noticeably slower. On search.cpan.org, searching for "cgi" took 90 milliseconds, whereas the new site takes 1.25 seconds. I tried several times.
Re: The end of an era: Saying goodbye to search.cpan.org
#46Earlier quoted context omitted.
How many PHP websites still work, if they have been in unmaintained since 2005? Can you imagine how many bugs you can find in a 2005 WordPress site? Or PHPNuke?
Given CPAN started in 1999, you'd be talking about a PHP 4 project that was mostly finalized by 2005 (at which time PHP 5 had been out for around a year or so). You'd be insane to allow any level of external access to something running on PHP 4 without an insane level of isolation and hardening (and even it would still be a PITA to deal with in an ongoing basis). For the most part you can take any Perl 5 code written…
Re: The end of an era: Saying goodbye to search.cpan.org
#47Re: The end of an era: Saying goodbye to search.cpan.org
#48 > Luckily, there is now a viable
> alternative: MetaCPAN.org[...]
This is somewhat of a revisionist history. MetaCPAN has been around in a form where it's been a good search.cpan.org replacement since 2012 at least, but for some reason that whatever set of people that run perl.org haven't wanted to switch serch.cpan.org over.I'm very grateful to the effort of Graham Barr in creating serch.cpan.org, and fully understand that he may have his own reasons for never open sourcing it, and I respect that.
But at the same time it's really odd that the Perl project has been willing to run proprietary code on one of its main landing pages for almost a decade when a viable open source alternative has been available.
Re: The end of an era: Saying goodbye to search.cpan.org
#49Earlier quoted context omitted.
Given CPAN started in 1999, you'd be talking about a PHP 4 project that was mostly finalized by 2005 (at which time PHP 5 had been out for around a year or so). You'd be insane to allow any level of external access to something running on PHP 4 without an insane level of isolation and hardening (and even it would still be a PITA to deal with in an ongoing basis). For the most part you can take any Perl 5 code written…
There is a german Provider (df.eu) with php4 to php 7.2 support. As a customer you can choose which version you want to use. I don't know why they still support down to version 4 but I never had a problem with their products.
I imagine it's a meeting of groups that need to have some old PHP 4 app running, and a company willing to throw it on a VM and put a best effort into keeping it from becoming a script-kiddie cesspool. It's probably not even as bad as I make it sound as long as you don't need public access. Still, not a business I would want to be in...
Re: The end of an era: Saying goodbye to search.cpan.org
#50This 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.
How many languages haven't gotten any new features since 2005? Even C has seen some improvements. Python got one incompatible update openly, and some others covertly (syntax changes like f" and @-operator, where some.py written with python 3.x can cause syntax errors w/ python 3.(x-1)). Perl 6 was released. C++ has seen a couple standards revisions. A couple new ECMAScript standards were issued. Newest Perl 5 is v5.2…
https://github.com/jwilk/python-syntax-errors
I don't know what's "covert" about these updates. They are always documented.
Also I don't understand why you put disruptive syntax changes in Python 3.X in one basket with backwards-compatible syntax additions like f-strings or the @ operator.