Hacker News new | ask | show | jobs
by AzzieElbab 1743 days ago
It is not about efficiency , it is about legacy. You can count number of Perl scripts out there and conclude that Perl is still the most popular scripting/devops tool in the world
5 comments

In PHP's case it's about WordPress which still being deployed at a very high rate. While the blogging thing isn't that much in focus anymore, WordPress + Divi + WooCommerce is an extremely common stack for setting up eCommerce sites.

An yes, then there's Drupal, Laravel, Symfony, and many others, and they're going strong too. Heck, even Joomla is actively developed even though it's probably small enough today to be considered legacy.

cPanel could probably included, it's nearly on all web hosts.
cPanel is Perl, not PHP.
Yes, majority of websites (legacy on PHP 5.6 and modern site in PHP 7+) use CPanel. Even thought that cPanel is written in Perl.

Most newbie coders would start out coding their own blogs in PHP/Nodejs or Python on shared hosting, some web host use web framework as well.

Probably true. Another thing I’ve missed are all those admin and status pages for iot and networking equipment
And facebook...
Facebook has done impressive things with PHP, but they are one single entity. WordPress is an entire ecosystem with millions of users, and while Facebook changing their underlying stuff wouldn't be noticed by most, I can assure you there would be a large amount of people who noticed if WordPress decided to switch to ASP.NET or something.
Kind of true, there are loads of companies that started out as a 1 or 2 person gig with a crappy wordpress site as their MVP, then they take on a full time php developer to make some changes and before you know it they are a few years in and are rebuilding their site in Laravel or Symfony.
Literally my story right now.
Haha yes! I did Symfony/Laravel contracting for years and all the companies I worked for started like this.
I worked on a bunch of projects where PHP was still used for landing/home page and absolutely nothing else
>>You can count number of Perl scripts out there and conclude that Perl is still the most popular scripting/devops tool in the world

Perl is still heavily used. I wrote more than 2K lines just last week, lots of it is throwaway. But hey not many languages make it easy for you to write thousands of lines of throwaway code in hours.

It's still the most useful language in the backend/unix world. This comes from me, who actually writes lots of Python code. But I wouldn't use Python where I use Perl. It would just make me slow and it wouldn't get the job done just as well as Perl.

It's not used as frequently for web dev, or other places where Java is used. But it's very good at what it does. Glue language for the Unix world.

> Perl is still heavily used. I wrote more than 2K lines just last week, lots of it is throwaway.

Agreed. For any one-off (or occasional) task that in any way involves juggling text (which in Unix CLI world is nearly all of it), perl is still the fastest way to get done.

Back in '92 (roughly when I started using perl), its regex support was revolutionary. Today, all languages have decent string handling and regex support. And yet, none is quite so naturally well integrated as in perl. So here 30 years later, if I need to pick apart and recombine text, give me perl.

would you consider those 2k perl loc legacy/maintenance work or something new?
Why would it be called legacy, I wrote that just last week. This is active development.

Besides merely being an old technology doesn't mean legacy. SQL is fairly old.

I wrote a bunch of scala code last week to fix problems in a service that we are actively working to replace. I consider this a "legacy" work, nothing to do with technology used
It's clear that legacy has a pretty strong influence, here, with Wordpress and other standard tools inflating PHP's numbers and Shopify doing the same for Ruby.

But, I'm pretty sure there's plenty of new projects being started nowadays in PHP, Ruby, Java, etc, because they're the most effective tool for the job.

It's just that this is not news. News is yet-another-standard-tool-written-in-rust.

Not always true. Is also about the best tool for the job.

Ex. I had to implement a task that would need to check if an image is similar to other image (not related to porn/csam). I implemented it with just a few line of PHP and no 100+ package dependencies. How? I run a linux CLI app from inside PHP, super easy.

but, but , you can do it with node too, - yes, but guess int he past in a node project, soem dev instead of calling ffmpeg directly he npm installed some shit package that called ffmpeg. The package was basic and it did not include or options needed , some other dev would have installed other package to get a new ffmpeg feature, /

I removed all those packages and done it directly.

My point is that we need to use the best tool for the job, if there is a CLI app or Java program/library that solves your problem a developer should present teh client the truth "I can solve your problem using this in 1 day or I can rewrite it in CoolLang and CollFramework and CoolPacakgeManager and CoolTranspilter with 100+ shit dependencies in 1 month. I am afraid many developers are choosing the last option to pad their CV and pump their ego.

I would say is also the ecosystem, PHP has a bit ecosystem and it can always use all the Linux applications (once in a project I integrated PHP with node program puppeteer) so there is no limitation, I miss more features in JS then I miss them in PHP.

Or, maybe developers who choose other languages are also competent professionals who make language/framework choices for good reasons. I have no considered opinion about PHP but one reason I have never used it for a web application backend is because I do a lot of coding that PHP is not well-suited for (high-performance, data intensive) and it is easier to write the web server in the same language I use for everything else.

Also, in general passing untrusted input to shell commands is probably a bad idea. FFmpeg has had many CVEs over the years and taking an upload from a user and piping it to a CLI command is asking for trouble. There are considerations beyond just doing the easiest thing that could possibly work.

>Also, in general passing untrusted input to shell commands is probably a bad idea.

This is why you escape the shell command arguments, but if you blindly npm install a shitty wrapper you probably hit the issue with security issues. Sure review of the dependency would be great but I did not seen many devs doing it, if they would have reviewed the ffmpeg wrapper would have noticed the simplicity and implemented themselves and on top of that learned some new stuff.

>Or, maybe developers who choose other languages are also competent professionals

I did not say that all of node developers are beginners, I am saying that many developers are not using the right tool for the job but use the cool tool for the job and some developers just blindly npm install shit because this is the only thing they know.

And I can confess I was guilty of this, on a project I propose to use Qt4 over Adobe Air because I was fan Qt and hated Adobe , turned out in the end I was forced to use Adobe Air and I loved it, for what we were doing it was the best tool for the job.