11 ms·

Why did Perl never maintain its popularity?

thesuperbigfrog 3y ago
>> Why did Perl never maintain its popularity? It is usually installed by default on most Unix and Linux systems. It also rides along with most MinGW-based toolkits like Git for Windows. If you do software development, there is a good chance you might have Perl installed and not even know it. Some people like to make fun of it despite its wide-spread use and utility. Most of them probably know little to nothing about Perl and have not written or maintained any Perl code. There is a good chance that they are using Perl code without knowing it.
- cutler 3y ago
  Amazon.co.uk was built in Perl and Booking.com is still a Perl shop.
  - thesuperbigfrog 3y ago
    >> Amazon.co.uk was built in Perl Yes. All of the Amazon retail web sites used Perl Mason running on Apache mod_perl: https://metacpan.org/pod/Mason https://metacpan.org/pod/Mason http://www.masonhq.com/htmlmason http://www.masonhq.com/htmlmason
gpvos 3y ago
Because PHP (heavily inspired by Perl, but not as well thought out) came with all the glue to directly use it to generate web pages. Then came Ruby (also inspired by Perl, but with a more mainstream syntax, and nicer in some ways), and Ruby on Rails conquered that space even more. Also, Python came along which is indeed a bit more suitable for larger projects needing structure. Meanwhile, Perl was being badmouthed by people who couldn't handle its flexibility and thought it was unreadable and unmaintainable. But that wasn't the main issue, after all PHP was worse in those two respects, yet it flourished.
- adolfoabegg 3y ago
  Yes, this was my case, I started with Perl and then I moved to PHP.
- midoridensha 3y ago
  I think the other problem was that Perl 6 came out and was totally incompatible with previous versions. Python did something similar with 2->3 and it caused huge problems.
  - gpvos 3y ago
    That was later though. Interest in Perl was already declining a bit then. And the problem was more that the design and implementation of Perl 6 (now Raku) took extremely long, and attention to Perl 5 suffered from that, as Perlistas thought Perl 6 would be the Next Great Thing.
  - ZuLuuuuuu 3y ago
    Perl 5 -> 6 was much more comprehensive than Python 2 -> 3. Perl 6 is almost a completely new language.
    - lloeki 3y ago
      Not "almost", it is a completely new language with a passing ressemblance and IIRC was by and large advertised as such from the get go; the name "Perl" was kept as it was a spiritual successor, which they realised made it confusing so they changed it to Raku. Perl 5 and 6/Raku have as much in common than Perl 5 and Ruby have.
      - chromatic 3y ago
        IIRC was by and large advertised as such from the get go It was not. For many years it was advertised as the next version of Perl (with the intent being perhaps a Perl 5.10 release and then no more major releases with the 5 version number), then years later a "sister language", and then finally now (but not retroactively) a "completely new language in the Perl family".
doctor_eval 3y ago
IIRC, early Perl was missing little things like named function arguments. So a lot of perl code was really inscrutable. I think “scrutability” is a huge driver of adoption… it’s why HTML and JavaScript became popular - and I reckon it’s why Perl burned out. It’s certainly the reason I never adopted it. Well, that and CPAN…
- housecarpenter 3y ago
  > early Perl was missing little things like named function arguments It's still missing those :) (To be clear for people unfamiliar with Perl, it probably will never have them, because it doesn't need them. In Perl, all functions effectively have a single parameter of array type. The standard convention is to assign each array entry to a variable at the start of your function definition, and the names of those variables then effectively act as parameter names. But that's just a convention and you can do something else if you want.)
  - cygx 3y ago
    Nowadays, sub signatures can be enabled via use feature 'signatures' which is implied by use v5.36
  - elcaro 3y ago
    I know cygx already replied, but to be clear, function signatures have been available in Perl since 2015. They were added (as experimental) in 5.20, and are now enabled by default with `use v5.36` or later. All new features must now go through an experimental phase after the smartmatch debacle. Signatures stayed in experimental status a little longer than most new features due to an unfortunate change with respect the order of function signatures and function prototypes. Provided you weren't using prototypes (which you almost never need) then they've been largely stable since 2015. Most distro's under current support ship with at least Perl 5.24, so you can use them almost anywhere.
- cutler 3y ago
  "Unrolling @_" is still a Perl ritual.
gorgoiler 3y ago
For me, Perl’s tight syntax let you get a lot of stuff done but lacked the consistency of simpler, more verbose languages better suited to multiplayer teams.
xupybd 3y ago
One possible factor is the cost of backwards compatibility.
lmm 3y ago
It was always easy to write unmaintainable code in. As time went by other languages caught up with the things Perl did well (dependency management with a large base of libraries available, automated tests that you could have confidence in because they ran by default as part of installing any package, lightweight syntax that makes easy things easy, easy to make available in a shared hosting environment), whereas Perl's biggest problem was inconsistency which was essentially impossible to fix (except with a big rewrite of the whole language, which they did try, but...).
- autoexec 3y ago
  > As time went by other languages caught up with the things Perl did well except regex handling which is still somehow way more awkward in other languages.
pravus 3y ago
From my perspective (over a decade of Perl programming now doing Go): * It has no concurrency primitives that are anywhere close to other popular languages * Tooling is good and works but is archaic, slow, and cumbersome * The community hasn't positioned itself to be anything other than lightweight backend services and small webapps (smaller than rails) * The community isn't really all that inviting or fun to be around Basically Perl offers me nothing that Go doesn't. I'm just as fast in Go as Perl and it's much easier to get stuff done. It's sad because it has some really good features that I miss but I just rewrote a final project from Perl to Go and am never looking back.
- mst 3y ago
  > It has no concurrency primitives that are anywhere close to other popular languages I can switch between writing async/await based $other_language and use Mojo::Base -signatures, -async_await; for my p3rl.org/Mojolicious code and keep all the same concurrency based patterns just fine. Trivial example of the sort of code I can write given that 'use' line: async sub url_body ($self, $url) { my $tx = await $self->ua->get($url); return $tx->res->body; } It's fair enough if you prefer go's lightweight threading plus channels CSP model but async/await is IMO a perfectly reasonable approach. (the -async_await feature flag is powered by p3rl.org/Future::AsyncAwait which works fine with p3rl.org/Future and p3rl.org/Future::Utils as well as p3rl.org/Mojo::Promise in a single process - and since p3rl.org/Mojo::IOLoop and p3rl.org/IO::Async will share an event loop I often find myself using things based on both since it's all await-able) p3rl.org/App::cpanminus plus p3rl.org/Carton (or my p3rl.org/App::plx) doesn't tend to be archaic or cumbersome to me (classic CPAN.pm, sure, but since cpanminus and plx are both distributed as p3rl.org/App::FatPacker bundled script s via github you can bootstrap them without ever loading CPAN.pm) - I generally find it less of an aggravation to deal with than most other languages' approaches (go's isn't bad at all, but e.g. virtualenv is very much not my cup of tea). As for slow, the main thing that makes installation from CPAN slower is that our tooling tends to run tests by default - I'm aware that these days "verifying your dependencies actually work at install time" has gone out of fashion in favour of faster installs, but if you're happy with that trade-off pretty much everything has a 'notest' flag available.
krylon 3y ago
I got the impression back then that Ruby on Rails ate a lot of Perl's use cases. And the Perl 6 thing probably didn't help either. And it might have acquired a bad reputation due to the fact you can easily write really terrible code in it.
wazoox 3y ago
I've made a presentation about it in 2013[1]. Back in 2000, when Perl was riding high and 13 year old, Larry Wall announced "Perl 6". However Perl6 (now Raku) was hugely ambitious and not production-ready until 2015 ... So for the best part of the naughties, people said things such as "don't bother learning Perl 5, Perl6 is coming"... Then the 2010s came and people got on the RoR and PHP and Python trains in the meanwhile instead. https://www.slideshare.net/eflorac/perl-presentation-2013-paris-hackers-meetup https://www.slideshare.net/eflorac/perl-presentation-2013-pa...
- deleted 3y ago
  [deleted]
- cygx 3y ago
  Back in 2000, when Perl was riding high and 13 year old, Larry Wall announced "Perl 6". Rinding high is something of an overstatement: The Big Thing at the time was Java, and PHP was already chewing away at Perl's market share. Some people thought the writing was an the wall, hence the mug-throwing incident that launched the Perl6 effort...

>> Why did Perl never maintain its popularity? It is usually installed by default on most Unix and Linux systems. It also rides along with most MinGW-based toolkits like Git for Windows. If you do software development, there is a good chance you might have Perl installed and not even know it. Some people like to make fun of it despite its wide-spread use and utility. Most of them probably know little to nothing about Perl and have not written or maintained any Perl code. There is a good chance that they are using Perl code without knowing it.

cutler 3y ago
Amazon.co.uk was built in Perl and Booking.com is still a Perl shop.
- thesuperbigfrog 3y ago
  >> Amazon.co.uk was built in Perl Yes. All of the Amazon retail web sites used Perl Mason running on Apache mod_perl: https://metacpan.org/pod/Mason https://metacpan.org/pod/Mason http://www.masonhq.com/htmlmason http://www.masonhq.com/htmlmason

gpvos 3y ago

Because PHP (heavily inspired by Perl, but not as well thought out) came with all the glue to directly use it to generate web pages. Then came Ruby (also inspired by Perl, but with a more mainstream syntax, and nicer in some ways), and Ruby on Rails conquered that space even more. Also, Python came along which is indeed a bit more suitable for larger projects needing structure. Meanwhile, Perl was being badmouthed by people who couldn't handle its flexibility and thought it was unreadable and unmaintainable. But that wasn't the main issue, after all PHP was worse in those two respects, yet it flourished.

adolfoabegg 3y ago
Yes, this was my case, I started with Perl and then I moved to PHP.
midoridensha 3y ago
I think the other problem was that Perl 6 came out and was totally incompatible with previous versions. Python did something similar with 2->3 and it caused huge problems.
- gpvos 3y ago
  That was later though. Interest in Perl was already declining a bit then. And the problem was more that the design and implementation of Perl 6 (now Raku) took extremely long, and attention to Perl 5 suffered from that, as Perlistas thought Perl 6 would be the Next Great Thing.
- ZuLuuuuuu 3y ago
  Perl 5 -> 6 was much more comprehensive than Python 2 -> 3. Perl 6 is almost a completely new language.
  - lloeki 3y ago
    Not "almost", it is a completely new language with a passing ressemblance and IIRC was by and large advertised as such from the get go; the name "Perl" was kept as it was a spiritual successor, which they realised made it confusing so they changed it to Raku. Perl 5 and 6/Raku have as much in common than Perl 5 and Ruby have.
    - chromatic 3y ago
      IIRC was by and large advertised as such from the get go It was not. For many years it was advertised as the next version of Perl (with the intent being perhaps a Perl 5.10 release and then no more major releases with the 5 version number), then years later a "sister language", and then finally now (but not retroactively) a "completely new language in the Perl family".

doctor_eval 3y ago

IIRC, early Perl was missing little things like named function arguments. So a lot of perl code was really inscrutable. I think “scrutability” is a huge driver of adoption… it’s why HTML and JavaScript became popular - and I reckon it’s why Perl burned out. It’s certainly the reason I never adopted it. Well, that and CPAN…

housecarpenter 3y ago
> early Perl was missing little things like named function arguments It's still missing those :) (To be clear for people unfamiliar with Perl, it probably will never have them, because it doesn't need them. In Perl, all functions effectively have a single parameter of array type. The standard convention is to assign each array entry to a variable at the start of your function definition, and the names of those variables then effectively act as parameter names. But that's just a convention and you can do something else if you want.)
- cygx 3y ago
  Nowadays, sub signatures can be enabled via use feature 'signatures' which is implied by use v5.36
- elcaro 3y ago
  I know cygx already replied, but to be clear, function signatures have been available in Perl since 2015. They were added (as experimental) in 5.20, and are now enabled by default with `use v5.36` or later. All new features must now go through an experimental phase after the smartmatch debacle. Signatures stayed in experimental status a little longer than most new features due to an unfortunate change with respect the order of function signatures and function prototypes. Provided you weren't using prototypes (which you almost never need) then they've been largely stable since 2015. Most distro's under current support ship with at least Perl 5.24, so you can use them almost anywhere.
cutler 3y ago
"Unrolling @_" is still a Perl ritual.

gorgoiler 3y ago

For me, Perl’s tight syntax let you get a lot of stuff done but lacked the consistency of simpler, more verbose languages better suited to multiplayer teams.

xupybd 3y ago

One possible factor is the cost of backwards compatibility.

lmm 3y ago

It was always easy to write unmaintainable code in. As time went by other languages caught up with the things Perl did well (dependency management with a large base of libraries available, automated tests that you could have confidence in because they ran by default as part of installing any package, lightweight syntax that makes easy things easy, easy to make available in a shared hosting environment), whereas Perl's biggest problem was inconsistency which was essentially impossible to fix (except with a big rewrite of the whole language, which they did try, but...).

autoexec 3y ago
> As time went by other languages caught up with the things Perl did well except regex handling which is still somehow way more awkward in other languages.

pravus 3y ago

From my perspective (over a decade of Perl programming now doing Go): * It has no concurrency primitives that are anywhere close to other popular languages * Tooling is good and works but is archaic, slow, and cumbersome * The community hasn't positioned itself to be anything other than lightweight backend services and small webapps (smaller than rails) * The community isn't really all that inviting or fun to be around Basically Perl offers me nothing that Go doesn't. I'm just as fast in Go as Perl and it's much easier to get stuff done. It's sad because it has some really good features that I miss but I just rewrote a final project from Perl to Go and am never looking back.

mst 3y ago
> It has no concurrency primitives that are anywhere close to other popular languages I can switch between writing async/await based $other_language and use Mojo::Base -signatures, -async_await; for my p3rl.org/Mojolicious code and keep all the same concurrency based patterns just fine. Trivial example of the sort of code I can write given that 'use' line: async sub url_body ($self, $url) { my $tx = await $self->ua->get($url); return $tx->res->body; } It's fair enough if you prefer go's lightweight threading plus channels CSP model but async/await is IMO a perfectly reasonable approach. (the -async_await feature flag is powered by p3rl.org/Future::AsyncAwait which works fine with p3rl.org/Future and p3rl.org/Future::Utils as well as p3rl.org/Mojo::Promise in a single process - and since p3rl.org/Mojo::IOLoop and p3rl.org/IO::Async will share an event loop I often find myself using things based on both since it's all await-able) p3rl.org/App::cpanminus plus p3rl.org/Carton (or my p3rl.org/App::plx) doesn't tend to be archaic or cumbersome to me (classic CPAN.pm, sure, but since cpanminus and plx are both distributed as p3rl.org/App::FatPacker bundled script s via github you can bootstrap them without ever loading CPAN.pm) - I generally find it less of an aggravation to deal with than most other languages' approaches (go's isn't bad at all, but e.g. virtualenv is very much not my cup of tea). As for slow, the main thing that makes installation from CPAN slower is that our tooling tends to run tests by default - I'm aware that these days "verifying your dependencies actually work at install time" has gone out of fashion in favour of faster installs, but if you're happy with that trade-off pretty much everything has a 'notest' flag available.

krylon 3y ago

I got the impression back then that Ruby on Rails ate a lot of Perl's use cases. And the Perl 6 thing probably didn't help either. And it might have acquired a bad reputation due to the fact you can easily write really terrible code in it.

wazoox 3y ago

I've made a presentation about it in 2013[1]. Back in 2000, when Perl was riding high and 13 year old, Larry Wall announced "Perl 6". However Perl6 (now Raku) was hugely ambitious and not production-ready until 2015 ... So for the best part of the naughties, people said things such as "don't bother learning Perl 5, Perl6 is coming"... Then the 2010s came and people got on the RoR and PHP and Python trains in the meanwhile instead. https://www.slideshare.net/eflorac/perl-presentation-2013-paris-hackers-meetup https://www.slideshare.net/eflorac/perl-presentation-2013-pa...

deleted 3y ago
[deleted]
cygx 3y ago
Back in 2000, when Perl was riding high and 13 year old, Larry Wall announced "Perl 6". Rinding high is something of an overstatement: The Big Thing at the time was Java, and PHP was already chewing away at Perl's market share. Some people thought the writing was an the wall, hence the mug-throwing incident that launched the Perl6 effort...