The end of an era: Saying goodbye to search.cpan.org
log.perl.org
log.perl.org
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.
Mostly transparently?
Also, experienced something similar with codehaus.org in the java world a few years ago.
> 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.
This is more surprising to see than it ought to be.
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.
Note that knowing perl well is quite a commitment and counter to current fashion in the industry.
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 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 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
Uhm, I can't see Catalyst listed in the web development section... Has it fallen out of grace ?
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.
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.
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.
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.
Like developer communities.
It's very much not the case with consumer software.
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.
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.
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.
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.
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
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.
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.
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.
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?)
By comparison, Google was still in beta at that stage, youtube was still 6 years away, and Mark Zuckerburg was 14.
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.
[1] https://github.com/search?utf8=%E2%9C%93&q=%22%2Fusr%2Fbin%2...
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.
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...
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'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.
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".
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.
I see what you did there... I like it.
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.
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.
> 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.
They spent a good deal of time making a perfect drag and drop replacement and I think it went very well.
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!
And it's nice that there exists a great replacement in metacpan.org
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.
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.
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'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.
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...)
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.
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.
- 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 ?
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
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!
Is this a joke? That's not what CPAN is about. For what CPAN is for, there already is a replacement, MetaCPAN.
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.
This move off search.cpan.org was cooking up for the last decade, explained in the post.