Live data from Hacker News

The end of an era: Saying goodbye to search.cpan.org

log.perl.org

41–50 of 125 posts

Re: The end of an era: Saying goodbye to search.cpan.org

#41

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 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

#42
post #38

Earlier 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).

Odd number releases are dev releases, even number are production releases. After 5.12 or so releases became time-boxed so that there is a new even release every year around this time (hence 5.28.0-rc1 dropping now, and in a year 5.30.0 will drop).

Re: The end of an era: Saying goodbye to search.cpan.org

#43
post #2

This 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?

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 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

#44
post #2

This 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.

I am a Perl hater, but mostly from having to dig into 10 year old legacy code for apps that nobody has touched for 5 years that still run.

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

#45

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 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.

They likely don't search the entirely same set of data (that is, cpan's search is likely a subset of metacpan's search). Also, metacpan groups results by package, which cpan returns individual modules (that is, you might have multiple results, one for each module in a package that matches in some manner). Page load speed isn't everything, and the the very quick search suggestions from the metacpan search that on a regular basis get me exactly what I want without a full search page load more than make up for it for me.

Re: The end of an era: Saying goodbye to search.cpan.org

#46
post #43

Earlier 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…

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.

Re: 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

#49
post #43

Earlier 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 would be very leery of trusting that PHP 4 was adequately patched (given the last PHP 4 versions was EOL almost a decade ago), for a number of reasons that don't just include df.eu's technical capability. It's just a much less likely to be looked at system, but that doesn't mean it's not rife with lots of exploits that newer techniques could quickly find, and I imagine that hosting company is generally just patching obvious and reported exploits in PHP 4 (hopefully!). Best case scenario there's an active fork of PHP 4 that some company is monetizing support for (which doesn't negate all the problems I mentioned, but helps a few).

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

#50
post #23
post #2

This 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…

Python adds new syntax in nearly every minor release. You can see samples here:

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.

Post reply on HN