Live data from Hacker News

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

log.perl.org

111–120 of 125 posts

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

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

That, sometimes a huge, throw the baby out with the bathwater, rewrite by a separate team (via MetaCPAN) is the correct way to go to move forward? Or, that CPAN's greatest worth is the modules themselves and not the search engine of the modules? What's it tell you? Anyways, thanks for all the search.cpan.org memories. I feel that I have memories pre 2002 of the site (maybe I'm wrong?)

Metacpanhas been around for at least 5 years. It was always intended as a search.cpan.org replacement.

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

#112
post #103

I was wondering: given that - Perl6 is quite a different language from Perl5 - I am aware that there is an enormous amount of code written in Perl 5 Has anyone of you started transitioning to Perl6 ? If so, what's your experience/opinion ?

My opinion is that perl5 isnt going anywhere. Every time I have to read ruby it looks like bad perl5 or good php. Every time I have to read python it looks like good java or constrained perl5 with syntactically meaningful white space. Every time I have to read JavaScript it looks like weird and constrained perl. But then again I know perl well, and knowing a language well is counter to current industry fashion.

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

#113
post #88

Also goodbye illguts then. Illustrated guts is the description of the perl5 internals, in html and images. Metacpan still does not allow displaying it and I won't pay for hosting services. Static GitHub pages maybe, but how stable will that be, and it's another link away from the primary content. They knew of this problem for years.

[deleted]

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

#114
post #103

I was wondering: given that - Perl6 is quite a different language from Perl5 - I am aware that there is an enormous amount of code written in Perl 5 Has anyone of you started transitioning to Perl6 ? If so, what's your experience/opinion ?

There was an interesting thread on this topic a few months ago: https://news.ycombinator.com/item?id=16211864

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

#115
post #8

Now this is you how EOL a beloved product. By working with an OSS replacement such that the transition is transparent. Super thanks to the team for the CPAN search (it was a lifesaver many times for me in the past!) as well as for their awesome transition plan.

Same way that PyPI.org (Warehouse) replaced the old pypi.python.org codebase? Mostly transparently?

This is a bit easier to handle than the pypi transition. The parts of the CPAN ecosystem are more disconnected. MetaCPAN/search.cpan.org (search and docs viewer), PAUSE (upload service), and CPAN (file mirrors) are all separate systems.

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

#116
post #88

Also goodbye illguts then. Illustrated guts is the description of the perl5 internals, in html and images. Metacpan still does not allow displaying it and I won't pay for hosting services. Static GitHub pages maybe, but how stable will that be, and it's another link away from the primary content. They knew of this problem for years.

Maybe get it into (perldoc?) perl.org if possible?

I told them 5 years ago already. Didn't happen. So far all my suggestions were declined. And recent maintainerships made it much worse.

This move off search.cpan.org was cooking up for the last decade, explained in the post.

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

#117
post #87
post #54

Finally Google search results will point to the better site. It was always so frustrating to google anything Perl related and get search.cpan.org over metacpan.

One of the only pure usability [1] wins from switching to DDG a few months back is that metacpan was always considered a better better/higher placed result. Of course, that only makes sense... [2] 1: It's nearly impossible to compete with Google when you aren't collecting every bit of data. That said, the reasons to switch remain compelling even months later. 2: https://metacpan.org/release/DDG

It wasn’t always. Kind words were said and `!cpan` was switched early on.

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

#118
post #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 underst…

From what I have been able to gather, MetaCPAN was the planned replacement for search.cpan.org and the reason it took forever to transition was to guarantee a perfect handover and minimal to no issues(linkrot, API problems, etc) upon the shutdown of the search.cpan.org servers.

They spent a good deal of time making a perfect drag and drop replacement and I think it went very well.

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

#119

Earlier quoted context omitted.

If someone is being paid to modernize a perl app, they almost certainly are intended to rewrite it in another language entirely.

No, that’s just bullshit. It’s very easy to write Modern Perl, and most companies with large Perl codebases break their codebases into service based architectures and then rewrite them bit by bit.

This was my thought, as well.

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

#120
post #90
post #86

Earlier quoted context omitted.

You can also get a real quick exposure from the Modern::Perl module[1], which is by the author of the book mentioned in a sibling reply. The basic idea is simple though. Use strict. Use warnings. Use new features and best practices modules (Task::Kensho[2] an help here) when them make sense (e.g. Moose/Moo). Be aware at least what PBP[3] is, and if you feel so inclined, use Perl::Tidy and/or Perl::Critic (even if you…

> 2: https://metacpan.org/pod/Task::Kensho Uhm, I can't see Catalyst listed in the web development section... Has it fallen out of grace ?

In addition to the other comments made here ... Task::Catalyst is right there after Plack and before Template (TT2).

Rather than try to guess at the proper set of modules recommended by a subproject, if there was already a recommendation (ie a Task:: module) we tried to re-use that.

Post reply on HN