6 ms·
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 hat
by kyoob 8y ago
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.
- ra88it 8y agoIt 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.
- purge 8y agoThe backend API is indeed (modern) Perl and the repository is here: https://github.com/metacpan/metacpan-api https://github.com/metacpan/metacpan-api
- superbaconman 8y agoAs someone who works with perl daily, what's "modern" perl?
- perigrin 8y agoNot the origin but a decent definition can be found in http://modernperlbooks.com/books/modern_perl_2016/index.html http://modernperlbooks.com/books/modern_perl_2016/index.html
- kbenson 8y agoYou 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 https://metacpan.org/pod/Modern::Perl 2: https://metacpan.org/pod/Task::Kensho https://metacpan.org/pod/Task::Kensho 3: http://shop.oreilly.com/product/9780596001735.do http://shop.oreilly.com/product/9780596001735.do 4: https://news.ycombinator.com/item?id=11633961 https://news.ycombinator.com/item?id=11633961
- znpy 8y ago> 2: https://metacpan.org/pod/Task::Kensho https://metacpan.org/pod/Task::Kensho Uhm, I can't see Catalyst listed in the web development section... Has it fallen out of grace ?
- justinator 8y agoWell, TMTOWTDI and all, but also research Mojolicious https://mojolicious.org/ https://mojolicious.org/
- kbenson 8y agoNot 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/ https://mojolicious.org/
- labster 8y agoMy 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.
- kbenson 8y ago> 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.
- abritinthebay 8y agoI 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.
- kbenson 8y ago> 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.
- meirelles 8y agoTo 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!
- johannes1234321 8y agoIt 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.
- mst 8y agoIt 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.
- ajpocus 8y agoDoes 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?
- wpietri 8y agoI 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 http://mcfunley.com/choose-boring-technology
- Xorlev 8y agoAggressively 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.
- justinator 8y agoThat, 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?)
- singingfish 8y agoMetacpanhas been around for at least 5 years. It was always intended as a search.cpan.org replacement.
- isostatic 8y agoHow 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.
- gkya 8y agoHow 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.
- perigrin 8y agoIf 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.
- gkya 8y agoThanks (I don't know much about perl versions really, just did a /2005 in perlhist).
- perigrin 8y agoOdd 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).
- gkya 8y agoI guess you mean "9" in 5.9.2 as the part that tells dev or production, no?
- perigrin 8y agoYes. 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.
- lkrubner 8y agoHow 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?
- kbenson 8y agoGiven 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.
- ahofmann 8y agoThere 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.
- kbenson 8y agoI 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...
- ianbicking 8y agoPyPI was also recently reimplemented from scratch. It's not so odd.
- empath75 8y agoI 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.
- perigrin 8y ago10 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.
- justinator 8y agoI'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.
- empath75 8y agoIf someone is being paid to modernize a perl app, they almost certainly are intended to rewrite it in another language entirely.
- psergeant 8y agoNo, 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.
- justinator 8y agoThis was my thought, as well.
- gitgacutils 8y agoIt'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://twimgs.com/ddj/images/article/2014/0114/Tiobe1.gif http://www.drdobbs.com/jvm/the-rise-and-fall-of-languages-in-2013/240165192 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_major_languages-1-1024x878.png 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".
- hpcjoe 8y agoAmazing 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.
- znpy 8y ago> qw(Scala go F# rust ...) I see what you did there... I like it.
- gitgacutils 8y ago> 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.