The end of an era: Saying goodbye to search.cpan.org(log.perl.org)
log.perl.org
The end of an era: Saying goodbye to search.cpan.org
https://log.perl.org/2018/05/goodbye-search-dot-cpan-dot-org.html
124 comments
Same way that PyPI.org (Warehouse) replaced the old pypi.python.org codebase?
Mostly transparently?
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.
Didn't that transition not go very smoothly? I seem to remember having nowhere to download packages stuff at work when they turned the old system off (I think due to the new system not being able to handle the load, but I could be wrong)
There were issues with the CDN and redirects[0] for a couple of hours when they flicked the switch. Still, I think it was a very successful transition.
[0] https://status.python.org/incidents/1y1f44q6srh2
[0] https://status.python.org/incidents/1y1f44q6srh2
I used to be a Perl developer about 15 years ago. I no longer write Perl. Thank you CPAN search team.
I've been working a lot more with Ruby the last while and I've noticed links to rubyforge here and there and everywhere but google as I may I can't find where all that stuff has moved to. I think this may be a good counter-example ...
Also, experienced something similar with codehaus.org in the java world a few years ago.
Also, experienced something similar with codehaus.org in the java world a few years ago.
From the article:
> In recent years maintenance has become a burden. Most of the site is running 2005 era Perl code. Luckily, there is now a viable alternative: MetaCPAN.org. The MetaCPAN team has been getting ready for the transition and is nearly ready to take over. Shortly, a link will be added to all pages on search.cpan.org to inform users of the upcoming change. After about a month, all traffic will be redirected to the equivalent MetaCPAN page.
Existing search.cpan.org links will continue to work after the transition.
> In recent years maintenance has become a burden. Most of the site is running 2005 era Perl code. Luckily, there is now a viable alternative: MetaCPAN.org. The MetaCPAN team has been getting ready for the transition and is nearly ready to take over. Shortly, a link will be added to all pages on search.cpan.org to inform users of the upcoming change. After about a month, all traffic will be redirected to the equivalent MetaCPAN page.
Existing search.cpan.org links will continue to work after the transition.
>Existing search.cpan.org links will continue to work after the transition.
They should get a lot more credit for this. Linkrot sucks, and I'm sure the effort that was required to pull off maintaining those links is going to pay off greatly for many for years to come.
They should get a lot more credit for this. Linkrot sucks, and I'm sure the effort that was required to pull off maintaining those links is going to pay off greatly for many for years to come.
I concur. Rewrite rules for projects like this can get super crazy. Kudos to the devs/admins/community who put in the effort.
They actually have had the existing URLs working via `search.mcpan.org` for several years now, this is really just a matter of dropping the `m`.
I'm not very familiar with the Perl ecosystem, but that would be an entirely different domain; was the server behind it maintained by the the MetaCPAN people, or the cpan.org people?
It has been maintained by MetaCPAN people. Since this transition has been planned, extra work has been put it to make the redirects more comprehensive.
No link rot. Bravo for a display of true competence.
This is more surprising to see than it ought to be.
This is more surprising to see than it ought to be.
This is one of the main things Perl is about. The language and the community takes, in the broadest sense, operational stability very seriously. More serious than any other language community I'm aware of.
this is why you see people who know perl5 well get the shits with other language communities approach to backcompat and tooling. E.g recently I helped take a 20 year old 250kline (of perl, think at least 5-10 mil of Java) to a modern version of perl with changes to around 50 lines of code.
Note that knowing perl well is quite a commitment and counter to current fashion in the industry.
Note that knowing perl well is quite a commitment and counter to current fashion in the industry.
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'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.
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.
Does it necessarily follow that a solo dev, working on a project in their spare time, will accrue massive technical debt? I'm honestly asking, as a solo dev that works on projects in my spare time. If it is the natural progression, how can it be avoided?
I don't think so.
Personally, I'm prone to taking on technical debt when under time pressure or feature pressure. I think of it like my house: if I'm too busy, I get sloppy and leave messes. If I stay busy for too long, the messes stack up.
One complicating factor, though, is the age of the code base is a factor, too. Keeping up with new runtimes, new frameworks, and new ways of doing thing takes time. This is especially a problem with things built in the new hotness, because there the culture is one of rapid iteration. So if we really want side projects to last, I think we have to choose boring technology: http://mcfunley.com/choose-boring-technology
Personally, I'm prone to taking on technical debt when under time pressure or feature pressure. I think of it like my house: if I'm too busy, I get sloppy and leave messes. If I stay busy for too long, the messes stack up.
One complicating factor, though, is the age of the code base is a factor, too. Keeping up with new runtimes, new frameworks, and new ways of doing thing takes time. This is especially a problem with things built in the new hotness, because there the culture is one of rapid iteration. So if we really want side projects to last, I think we have to choose boring technology: http://mcfunley.com/choose-boring-technology
"large project" was a key thing - Graham took on a feature set that regularly exceeded his spare time such that he ended up with the same pressures to hack instead of refactor that cause technical debt in commercial projects.
The trick is to avoid overstretching yourself in terms of what you promise - or to recruit a team. In this case, neither happened, and so the result was unfortunately inevitable.
The trick is to avoid overstretching yourself in terms of what you promise - or to recruit a team. In this case, neither happened, and so the result was unfortunately inevitable.
Aggressively descope your projects. That helps. Try to keep as much of your logic outside of any specific framework. Most of my projects that accrue tech debt aren't necessarily because I cut corners (though that happens too :P) just that times changed and I needed to shift my projects into more modern stacks (i.e. for security updates, or because the tech was no longer maintained, hard to use anymore, hard to push updates to).
Rewriting software is somewhat of an inevitability it seems like, but the more small reusable pieces you have, the easier that is. Think UNIX philosophy: small units that do a small amount of things well that you can generally depend on once they become stable.
It varies depending on your project of course. A lot of the tech debt you take on (fun new tech, getting something out fast) is half the fun.
Rewriting software is somewhat of an inevitability it seems like, but the more small reusable pieces you have, the easier that is. Think UNIX philosophy: small units that do a small amount of things well that you can generally depend on once they become stable.
It varies depending on your project of course. A lot of the tech debt you take on (fun new tech, getting something out fast) is half the fun.
I think so.
This is exactly how my own long-term projects that actually have users have panned out. When everything is left to your own energy and charity yet it doesn't pay the bills, when there's work to be done then the project is lucky to get whatever you can spare.
And it typically needs work in spite of what's going on in your personal life. I was at the beach when my hand-coded forum went down (btw, don't build your own forum). I ended up patching it live on the server, guessed at the problem, and had to clean up my mess weeks later.
If you don't actually have users, then sure, that's something entirely different. I have plenty of projects that never left localhost with no technical debt, too. That's trivial.
This is exactly how my own long-term projects that actually have users have panned out. When everything is left to your own energy and charity yet it doesn't pay the bills, when there's work to be done then the project is lucky to get whatever you can spare.
And it typically needs work in spite of what's going on in your personal life. I was at the beach when my hand-coded forum went down (btw, don't build your own forum). I ended up patching it live on the server, guessed at the problem, and had to clean up my mess weeks later.
If you don't actually have users, then sure, that's something entirely different. I have plenty of projects that never left localhost with no technical debt, too. That's trivial.
mst is one of the kings of technical management of tricky open source infrastructure. The way he does it is to apply the smallest amount possible of savant level hacking, then find the right person to delegate to. And occasionally he does it in mysterious ways ;)
I'm curious why it was closed source. Contractual job requirement, proprietary search engine module, or...?
How great perl is, how long it lasts with minimal effort. Not many active sites from that era that still functioning, let alone ones maintained by 1 person.
By comparison, Google was still in beta at that stage, youtube was still 6 years away, and Mark Zuckerburg was 14.
By comparison, Google was still in beta at that stage, youtube was still 6 years away, and Mark Zuckerburg was 14.
To be fair, almost all non-maintained source codes becomes a problem, no matter the language, apply security fixes, update dependencies, handle all deprecated stuff, etc. isn't fun!
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 maintain as well.
Edit2: I know you’re not a Perl hater; I’m not an advocate; just playing the devil’s advocate.
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 maintain as well.
Edit2: I know you’re not a Perl hater; I’m not an advocate; just playing the devil’s advocate.
The backend API is indeed (modern) Perl and the repository is here: https://github.com/metacpan/metacpan-api
As someone who works with perl daily, what's "modern" perl?
Not the origin but a decent definition can be found in http://modernperlbooks.com/books/modern_perl_2016/index.html
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 your own defined subset of rules) to give yourself an idea of what is considered good practices (and when to throw them our for that elegant line or two, just don't forget to comment it so you don't confuse yourself when you see it months/years later). Basically, if you care about the code you write, you should find yourself gravitating towards writing Modern Perl anyway, and the speed at which it happens is largely determined by your exposure to the Perl community at large.
My own personal set of best practices means almost always using something like Function::Parameters or Kavorka, and possibly Moops.[4]
1: https://metacpan.org/pod/Modern::Perl
2: https://metacpan.org/pod/Task::Kensho
3: http://shop.oreilly.com/product/9780596001735.do
4: https://news.ycombinator.com/item?id=11633961
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 your own defined subset of rules) to give yourself an idea of what is considered good practices (and when to throw them our for that elegant line or two, just don't forget to comment it so you don't confuse yourself when you see it months/years later). Basically, if you care about the code you write, you should find yourself gravitating towards writing Modern Perl anyway, and the speed at which it happens is largely determined by your exposure to the Perl community at large.
My own personal set of best practices means almost always using something like Function::Parameters or Kavorka, and possibly Moops.[4]
1: https://metacpan.org/pod/Modern::Perl
2: https://metacpan.org/pod/Task::Kensho
3: http://shop.oreilly.com/product/9780596001735.do
4: https://news.ycombinator.com/item?id=11633961
> 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 ?
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.
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.
Well, TMTOWTDI and all, but also research Mojolicious
https://mojolicious.org/
https://mojolicious.org/
Not so much out of grace as much as (I think) it's fairly heavy for what it is and somewhat convoluted to configure and use.
Mojolicious and Dancer are the more modern equivalents, and both are frameworks in the vein of Ruby's Sinatra or Rails (probably more in-between). While you can run them as CGI/FastCGI, really nowadays I think most people just run them as standalone pure-Perl web servers (which makes it really easy to access and deal with every part of the request and routing), optionally with a proxying front-end such as Nginx or Apache to speed op static requests or handle SSL (but that's not needed, both are entirely capably of doing SSL encrypted servers in pure-perl with a few configuration params set).
Like the sibling comment, I prefer Mojolicious, and it's simple enough that the landing page for it[1] shows not just one but two fully functional standalone web applications with embedded webservers, one of 5 lines and one of 25 lines (both counts including blank lines). That may not help much with existing Catalyst apps, but I would be hard pressed to recommend Catalyst given how far the state of the art has advanced, but then again I've never really been a Catalyst user, so I may be unaware of a lot of its benefits.
1: https://mojolicious.org/
Mojolicious and Dancer are the more modern equivalents, and both are frameworks in the vein of Ruby's Sinatra or Rails (probably more in-between). While you can run them as CGI/FastCGI, really nowadays I think most people just run them as standalone pure-Perl web servers (which makes it really easy to access and deal with every part of the request and routing), optionally with a proxying front-end such as Nginx or Apache to speed op static requests or handle SSL (but that's not needed, both are entirely capably of doing SSL encrypted servers in pure-perl with a few configuration params set).
Like the sibling comment, I prefer Mojolicious, and it's simple enough that the landing page for it[1] shows not just one but two fully functional standalone web applications with embedded webservers, one of 5 lines and one of 25 lines (both counts including blank lines). That may not help much with existing Catalyst apps, but I would be hard pressed to recommend Catalyst given how far the state of the art has advanced, but then again I've never really been a Catalyst user, so I may be unaware of a lot of its benefits.
1: https://mojolicious.org/
Big monolithic web applications, which catalyst is optimised for have fallen out of favour. Catalyst helped solve many perl tooling problems, and it’s still a totally viable dev target. However as the author of the good catalyst book, I’d probably reach for mojo first in 2018.
The thing I like about catalyst is the same as the thing I like about git. It works well for the smallest use case and it scales well to the largest reasonable case.
The thing I like about catalyst is the same as the thing I like about git. It works well for the smallest use case and it scales well to the largest reasonable case.
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.26, in 2005 it was 5.9.2 (see perlhist(1)), if you have so many new and stable stuff available, maintaining something 9 years old is a burden even if it was perfect.
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.
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.
Because it's common to write you script with the shebang "/usr/bin/env python3" or equivalent [1], and this behaviour can cause syntax errors when going from one system to another.
[1] https://github.com/search?utf8=%E2%9C%93&q=%22%2Fusr%2Fbin%2...
[1] https://github.com/search?utf8=%E2%9C%93&q=%22%2Fusr%2Fbin%2...
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.
You are technically correct, the best kind of correct!
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).
I guess you mean "9" in 5.9.2 as the part that tells dev or production, no?
Yes. Because of a naming … inconsistency … several core developers and major CPAN contributes have moved the 5 into the name of the language. So Perl5 version 9.2 or Perl5 version 28.0-rc1. Because we are often quirky nostalgic humans we usually leave the 5 where it traditionally has been at the start of the version string.
ANSI Common Lisp - since 1994
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.
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.
I'm not disagreeing with you, but the first Perl project I started in 1999 in my dorm room had its latest, major release two days ago. I've never thought of maintaining your own Perl code as impossible. And I'm no wizard.
I've honestly wondered if maintaining someone else's forgotten Perl code, modernizing it, and getting it so that'll it'll run for another x years isn't all that bad of a niche job.
I've honestly wondered if maintaining someone else's forgotten Perl code, modernizing it, and getting it so that'll it'll run for another x years isn't all that bad of a niche job.
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.
10 year old legacy apps that no one has touched in 5 years were written after S.C.O was let go. 10 year old code in any language kinda sucks.
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.
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.
My guess at what it's telling us is that the OSS competitor will always win in the long term. I actually enjoy refactoring old Perl code into Modern Perl, but if I can't contribute, I can't help. Metacpan is has a larger community support because we can help out.
> the OSS competitor will always win in the long term.
That's an interesting point, and I've seen it come up more and more in recent years (or even months). It would be interesting to see a survey of major software technologies over time, with proprietary, commercial and open source all represented and see which ones still exist, are still usable in the current ecosystem, and support new features. e.g. operating systems, web servers, mail servers, database servers, CRM solutions, etc. I imagine if you looked at each period at five year intervals from 1993-2008, it would be very telling.
That's an interesting point, and I've seen it come up more and more in recent years (or even months). It would be interesting to see a survey of major software technologies over time, with proprietary, commercial and open source all represented and see which ones still exist, are still usable in the current ecosystem, and support new features. e.g. operating systems, web servers, mail servers, database servers, CRM solutions, etc. I imagine if you looked at each period at five year intervals from 1993-2008, it would be very telling.
I think it's probably only true for software that primarily serves large users of OSS.
Like developer communities.
It's very much not the case with consumer software.
Like developer communities.
It's very much not the case with consumer software.
> I think it's probably only true for software that primarily serves large users of OSS.
I think I understand what you're trying to say, but I'm not sure that description makes any sense. Prior to the popular OSS version being created, in most cases an OSS version didn't exist so there couldn't be a large set of users of OSS.
Apache has been run on windows for decades (or very close to it) now. Same with Sendmail, and MySQL These are people that chose to run open source software on a proprietary operating system (windows 98 or windows 2000), so I'm not sure large sets of OSS users had much to do with it. I think it's more that the software was robust, it worked, and it was free.
I think what your point is getting close to though is that it's probably true for software that has a more technical audience. Setting up server software requires some technical fluency, even today (if much less than in prior decades), and those people are more likely to both have heard of competitors, to be able to assess how they might perform in comparison, and to be able to actually install and troubleshoot them given the generally more complex documentation.
What I think we've seen over the last few decades though is that those technically minded people have come to become users of OSS. That is, I think your cause and effect was backwards, as those people are now users of OSS because there's good, solid OSS software that makes sense for them to choose, and once they're using it they are OSS users.
I think I understand what you're trying to say, but I'm not sure that description makes any sense. Prior to the popular OSS version being created, in most cases an OSS version didn't exist so there couldn't be a large set of users of OSS.
Apache has been run on windows for decades (or very close to it) now. Same with Sendmail, and MySQL These are people that chose to run open source software on a proprietary operating system (windows 98 or windows 2000), so I'm not sure large sets of OSS users had much to do with it. I think it's more that the software was robust, it worked, and it was free.
I think what your point is getting close to though is that it's probably true for software that has a more technical audience. Setting up server software requires some technical fluency, even today (if much less than in prior decades), and those people are more likely to both have heard of competitors, to be able to assess how they might perform in comparison, and to be able to actually install and troubleshoot them given the generally more complex documentation.
What I think we've seen over the last few decades though is that those technically minded people have come to become users of OSS. That is, I think your cause and effect was backwards, as those people are now users of OSS because there's good, solid OSS software that makes sense for them to choose, and once they're using it they are OSS users.
> it's probably true for software that has a more technical audience
Not just technical - technical and already use OSS. But yes, this is broadly my point. However...
> That is, I think your cause and effect was backwards, as those people are now users of OSS because there's good, solid OSS software that makes sense for them to choose
While this is partially true (obviously it has to exist to be used), I'm talking about the original proposition: that OSS always wins.
That's plainly not true when you're dealing with users who don't generally have exposure to OSS. Even polished OSS that serves these audiences (LibreOffice, etc) perform extremely poorly.
I think you get my point in the first part but you're narrowing your focus to why it works on that audience - when my point is that that technical audience isn't the general audience.
Not just technical - technical and already use OSS. But yes, this is broadly my point. However...
> That is, I think your cause and effect was backwards, as those people are now users of OSS because there's good, solid OSS software that makes sense for them to choose
While this is partially true (obviously it has to exist to be used), I'm talking about the original proposition: that OSS always wins.
That's plainly not true when you're dealing with users who don't generally have exposure to OSS. Even polished OSS that serves these audiences (LibreOffice, etc) perform extremely poorly.
I think you get my point in the first part but you're narrowing your focus to why it works on that audience - when my point is that that technical audience isn't the general audience.
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?)
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.
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.
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.
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...
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...
PyPI was also recently reimplemented from scratch. It's not so odd.
It's definitely an end of an era.
Some other telling factors.
The level of activity/projects in perl compared to python.
http://twimgs.com/ddj/images/article/2014/0114/Tiobe1.gif
http://www.drdobbs.com/jvm/the-rise-and-fall-of-languages-in...
Or the fact that perl isn't even relevant enough to be part of a comparison of major script-like languages.
https://stackoverflow.blog/wp-content/uploads/2017/09/growth...
But the most telling part is the lack of perl vs python flamewars. Remember those? Even the most ardent perl fan has conceded that python won.
In the immortal words of TS Eliot, "this is the way perl ends, not with a bang, but with a whimper".
Some other telling factors.
The level of activity/projects in perl compared to python.
http://twimgs.com/ddj/images/article/2014/0114/Tiobe1.gif
http://www.drdobbs.com/jvm/the-rise-and-fall-of-languages-in...
Or the fact that perl isn't even relevant enough to be part of a comparison of major script-like languages.
https://stackoverflow.blog/wp-content/uploads/2017/09/growth...
But the most telling part is the lack of perl vs python flamewars. Remember those? Even the most ardent perl fan has conceded that python won.
In the immortal words of TS Eliot, "this is the way perl ends, not with a bang, but with a whimper".
Amazing how, a decade or more after the python-perl skirmishes, some still ... still ... cannot give up their attacks on perl, using the mask of accounts created in the last day.
Perl is still alive, well, and growing. It's not the currently cool language d'jour like qw(Scala go F# rust ...). But people are shipping code with it, using it successfully for what it does best.
Haters gonna hate, and one should generally avoid feeding the several hour old trolls. Their trolling notwithstanding, rumors of perl's demise have been greatly exaggerated.
Perl is still alive, well, and growing. It's not the currently cool language d'jour like qw(Scala go F# rust ...). But people are shipping code with it, using it successfully for what it does best.
Haters gonna hate, and one should generally avoid feeding the several hour old trolls. Their trolling notwithstanding, rumors of perl's demise have been greatly exaggerated.
> Amazing how, a decade or more after the python-perl skirmishes, some still ... still ... cannot give up their attacks on perl, using the mask of accounts created in the last day.
I'm a fan of perl. I'm old school. I like C, perl, etc. I wasn't attacking perl. Just pointing out REALITY.
> Haters gonna hate, and one should generally avoid feeding the several hour old trolls. Their trolling notwithstanding, rumors of perl's demise have been greatly exaggerated.
I'm a troll because I pointed out facts?
Listen, nobody wants perl to succeed more than me. Stop calling people trolls just because you are upset about what has happened to perl.
I'm a fan of perl. I'm old school. I like C, perl, etc. I wasn't attacking perl. Just pointing out REALITY.
> Haters gonna hate, and one should generally avoid feeding the several hour old trolls. Their trolling notwithstanding, rumors of perl's demise have been greatly exaggerated.
I'm a troll because I pointed out facts?
Listen, nobody wants perl to succeed more than me. Stop calling people trolls just because you are upset about what has happened to perl.
I think the troll accusation might have been a bit overboard, but it's clear you're making some odd leaps in your assertions.
First, this submission is about the end of one person't handling of cpan search, not the end of CPAN, or the end of Perl. It's the change of the guard, from a lone person to a group. That doesn't exactly scream the end of something or insignificance.
Second, the comment you responded to was trying to make a point about the maintenance of old Perl. You didn't address that at all, and instead used it to make an alternate point entirely.
Really, it sort of came across like hijacking a thread to grind and axe. The problem is less the argument, and more the presentation. If you had instead presented an opinion in a bit softer manner, and asked how people thought, you might have gotten some useful responses and good discussion. Instead you made an assertion about the end of the subject of discussion, and called it defeated. It's not hard to see how some might interpreted that as an attack on the subject of their livelihood, given the general audience you could expect. At best it was tone-deaf.
First, this submission is about the end of one person't handling of cpan search, not the end of CPAN, or the end of Perl. It's the change of the guard, from a lone person to a group. That doesn't exactly scream the end of something or insignificance.
Second, the comment you responded to was trying to make a point about the maintenance of old Perl. You didn't address that at all, and instead used it to make an alternate point entirely.
Really, it sort of came across like hijacking a thread to grind and axe. The problem is less the argument, and more the presentation. If you had instead presented an opinion in a bit softer manner, and asked how people thought, you might have gotten some useful responses and good discussion. Instead you made an assertion about the end of the subject of discussion, and called it defeated. It's not hard to see how some might interpreted that as an attack on the subject of their livelihood, given the general audience you could expect. At best it was tone-deaf.
> qw(Scala go F# rust ...)
I see what you did there... I like it.
I see what you did there... I like it.
> Luckily, there is now a viable
> alternative: MetaCPAN.org[...]
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.
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.
They spent a good deal of time making a perfect drag and drop replacement and I think it went very well.
Sad you're being downvoted with what is -- as far as I know -- an entirely accurate description, and a valid point. It was weird that search.cpan.org remained closed-source for so long.
Many 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!
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!
It's paradoxical that Perl still runs so much of the Internet, but rarely gets any credit.
Thanks Graham. Perl was the first language I worked with professionally. It got me my start into software development all those years ago. Cpan was my first look at what dependency management might look like.
Graham Barr did the world a huge service by creating and running search.cpan.org. I used it for many years, across many projects. Thank you Graham!
And it's nice that there exists a great replacement in metacpan.org
And it's nice that there exists a great replacement in metacpan.org
This was the granddaddy package manager. Before gem or npm or maven or pip. It was the gold standard for sharing open source libraries and was the best reason for using Perl for a long time.
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
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.
Sorry to see search.cpan.org go, I don't write much perl nowadays so only just discovered metacpan, which seems like a big step forward. It is appropriate that there would be more than one way to do it.
Still, I pored over search.cpan.org for many long hours as a kid building summer projects. The ability to browse the package source was invaluable to me on a dial up link. Here's to all those that worked on it.
Still, I pored over search.cpan.org for many long hours as a kid building summer projects. The ability to browse the package source was invaluable to me on a dial up link. Here's to all those that worked on it.
TIL it was originally hosted at WashU, my alma mater.
I guess it was probably in the same server room as wuarchive, which at its peak in the 90s was rumored to represent 10% of the traffic on the internet. Was cool to look through the glass into the server room in the engineering school, and see the lights blinking like crazy on the RAID array attached to wuarchive's server.
I guess it was probably in the same server room as wuarchive, which at its peak in the 90s was rumored to represent 10% of the traffic on the internet. Was cool to look through the glass into the server room in the engineering school, and see the lights blinking like crazy on the RAID array attached to wuarchive's server.
Countless hours saved. Countless discoveries made. Goodbye search.cpan.org.. It was a fun run.
Wow.
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.
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.
Since 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...)
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...)
This doesn't sound like a reason to hate search.cpan.org.
To me, it sounds like your contractor was awfully lazy or underinformed. They didn't do the basic level of due diligence to determine if they had the most recent version of software -- nor were they even aware of the module installers. I don't use Python or Node.js all that much, but at least I'm aware of pip and npm.
To me, it sounds like your contractor was awfully lazy or underinformed. They didn't do the basic level of due diligence to determine if they had the most recent version of software -- nor were they even aware of the module installers. I don't use Python or Node.js all that much, but at least I'm aware of pip and npm.
[deleted]
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.
My experience was always the complete opposite, but I've avoided cpan.org in lieu of metacpan for years now because metacpan has a better experience overall. It likely changed over the years as the majority of Perl programmers switched to metacpan, which seems to go back around 7 years at least. According to alexa,com there's been a large shift in the last year or so, and metacpan.org is serving something like 3-4 times the amount of traffic. Additionally, each page is displaying much more info (such as dependencies, cpantesters platform testing statistics, etc).
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.
Because the metacpan search is written in java and does not use a fast search engine, like xapian, which does have nice perl5 bindings.
Also Elasticsearch uses 10x more RAM.
2005 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.
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.
Also to note that 2005 is the year "Perl Best Practices" (the book) was published. That was a big turning point (at least for me) in how to write much more maintainable Perl code.
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 ?
- 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 ?
I've written a blog post about that: https://www.perl.com/article/an-open-letter-to-the-perl-comm...
The modules implemented so far: http://modules.perl6.org/t/CPAN5
I'll also be giving a keynote on this subject at The Perl Conference 2018: https://perlconference.us/tpc-2018-slc/session/the-state-of-...
If you want to keep up to date on happenings in the Perl 6 world, please checkout the Perl 6 Weekly: https://p6weekly.wordpress.com
The modules implemented so far: http://modules.perl6.org/t/CPAN5
I'll also be giving a keynote on this subject at The Perl Conference 2018: https://perlconference.us/tpc-2018-slc/session/the-state-of-...
If you want to keep up to date on happenings in the Perl 6 world, please checkout the Perl 6 Weekly: https://p6weekly.wordpress.com
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.
There was an interesting thread on this topic a few months ago: https://news.ycombinator.com/item?id=16211864
I originally thought they meant it was going to be retired on the May 25 instead of June. I was like wut? How can GDPR do this?
cpan.org is great! it will be missed!
a couple days ago searching for some tool, i wanted to check some source at npmjs and to my surprise npmjs does not have a "download any-module.tar.gz" and neither has an option to "view the source" code like old cpan does.
i went to #nodejs to ask for help and guys there told me to install "npm" to download the source from npmjs module i wanted to see. NOOOO... i dont want to install npm, i just want to see how it was done. Cant i just click "download source" at the npm page ? NO. Cant i just click "view source" at the npm page ? NO. Just install npm and install the module so you can see the code... COME ON....
cpan.org so old and still so up-to-date!
perl so old and still so up-to-date!
a couple days ago searching for some tool, i wanted to check some source at npmjs and to my surprise npmjs does not have a "download any-module.tar.gz" and neither has an option to "view the source" code like old cpan does.
i went to #nodejs to ask for help and guys there told me to install "npm" to download the source from npmjs module i wanted to see. NOOOO... i dont want to install npm, i just want to see how it was done. Cant i just click "download source" at the npm page ? NO. Cant i just click "view source" at the npm page ? NO. Just install npm and install the module so you can see the code... COME ON....
cpan.org so old and still so up-to-date!
perl so old and still so up-to-date!
Metacpan is great, why continue with a double effort that needs a rewrite. It has served the community well for many years.
I misread the headline. I was really worried I wouldn't be able to search C-SPAN archives anymore. I'm glad I can still find old clips of bonehead senators trying to grandstand at hearings.
Sad news. Hopefully a replacement will fill its place and provide comprehensive public access to our government broadcasting network's archives.
> Hopefully a replacement will fill its place and provide comprehensive public access to our government broadcasting network's archives.
Is this a joke? That's not what CPAN is about. For what CPAN is for, there already is a replacement, MetaCPAN.
Is this a joke? That's not what CPAN is about. For what CPAN is for, there already is a replacement, MetaCPAN.
Dude half read the headline and nothing else. He saw CSPAN.
For people under 40: "Perl" refers to a script interpreter that used to be popular in the 90's.
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.
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.
I think that understanding the MetaCPAN team's concerns and working on an alternative delivery platform would be more appreciated than… moaning to a crowd who have very little agency or stake in the matter.
[deleted]
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.