Hacker News new | past | comments | ask | show | jobs | submit login
Perl 7 is going to be Perl 5.32, mostly (perl.com)
617 points by datanut 8 months ago | hide | past | favorite | 562 comments

I've been a perl zealot since 2005. I didn't even know "python" existed until around 2008 when I found a script file with a ".py" file ending in a fresh ubuntu install. I started going to perl conferences sometime after 2010 when someone on irc informed be about them. I learned so much in those conferences, mainly about the alternatives to cgi and the modern OOP "framework" named "moose". I thought I was in heaven.

I landed my first devops position around the 2010 era as well and being the only one on the team that really knew how to "program", I spammed out tons of perl scripts and web apps. A few years later one of the newer employees on the customer support team started spouting off about "python" and how it was so easy to learn. He was always blabbing about terms I'd never heard of like "generators", "list comprehensions", "decorators", etc. I looked them up and learned they were just abstract constructs with fancy names that are supported in most any language. So I just figured he was some idiot that didn't really know anything. Otherwise, why would you be blabbing about abstract constructs? He quickly landed a job at google and I left and started freelancing only picking up perl jobs. Because perl was "dying" and this being after 2012, there were several companies with large perl bases that couldn't find local employees so were forced to allow remote workers.

This is where stuff started going wrong. I went through many jobs/gigs my first couple of years. I quickly noticed that companies that had large perl code bases were all founded pre-2005. This meant it was crap perl, in most cases not even using CPAN but having home grown ORM's and web frameworks and a scrict hate of javascript. So it mostly sucked and was slow going. In one case I was literally fired after a couple of months from this one company that specialized in phone billing accounting software (all perl powered) because I was "too slow". The owner told me he should have never hired someone with less than fifteen years experience with perl and bid me farewell. I almost busted out laughing as for the entire two months I was only doing javascript front end work since the other perl guys there hate javascript. Even the owner of the company had no clue how his own software worked. This was a theme that repeated it self else where as well.

Fast forward a few more years and I had landed a good remote job, still in perl but offered more freedom in the dev cycle. I got good with react and vue.js as it greatly speed up the dev time for all the heavy interactive apps I was tasked with. But I continued to struggle against others in the perl community. I can understand how a 50 year old perl dev (the typical age) would hate javascript and instead put as much code in the back end using all kinds of horrid html templates and never ending form post/refresh/repopulate cycles... I can see the "why should I learn javascript if i know perl" ideology, but what blew me away is a constant "why should I learn SQL if I know perl" ideology. Yes I'm serious. In so many other cases devs were fine with just doing "select *" on tons of tables and stuffing all that in a hash/dictionary of column name matching keys. Databases were big, scripts and page load times would grow to minutes or even hours. Sometimes exhausting the machine's ram and crashing everything. Everyone was fine with it, management just acted like it's how things work. Meanwhile as a co-worker, I'm left digging through pages of perl code that could have just been a single SQL query trying to figure out why some numbers are wrong in an invoice report. It was a continual issue.

Another issue is just the bit rot of cpan. The ORM and drivers for both postgresql and sqlite don't even support most of the features added in those systems since 2014. So even though postgresql is the most advanced DB out there, you are stuck with no ability to use any of the fancy native array or json types or even the "natural" join syntax (and many other things), neither good support for foreign keys in sqlite either.

I've thrown my hands up and jumped ship. It's sad too. I liked many in the community and like Larry Wall as well and have had dinner with him on several occasions. But I can't keep my sanity and stay with perl. I can read perl fine, it is not the notorious "write only" language that many troll it to be. But the issue is the community and those using perl daily are fine with being stuck in 1995. Larry Wall stopped adding features to perl in 2002 (?) and moved to perl 6 which.... well how do you even describe that? The point is, perl has been the same since 2002, mean while python has had continual development and features added every year since then. I'm just done.

I loved Perl back in at the turn of the millennia. My first data science equivalent projects were in Perl.

To this day I can not find anything quicker to prototype in. Python is slow in comparison. Perl is great for quickly hacking something together for R&D purposes. Also, if you need to write something custom, Perl runs so much faster than Python and R.

I, like many people, stopped using Perl beyond a quick script in 2010. Not out of a lack of love. Perl was great. I wonder if your experience comes from being around the laggards, not so much Perl devs itself. When I was working in Perl no one around me was afraid of Javascript. Javascript and Perl are both C based. They aren't that different.

Your story is eye opening. It tells me what it would have been like if I had stuck around. I imagine working with the few who didn't want to learn new skills must have been more painful than you're letting on.

I wrote a lot of popular web apps in Perl, some that appeared in NY Times and Time mag. I quit around 2010 and went over to php which is easier. Wrote a great app and built a successful software biz around it. I think 2010 may have been when Perl 6 felt hopeless and there was no clear leadership or direction in the community.

Mod_perl was the sh*t back in the late 90s for super high performance web apps on Apache. Then Perl stalled and everything else didn’t.

Perl could have been where Python is today if they didn’t take 20 years to waffle about a release that was supposed to do everything and ended up doing nothing because everyone left.

What's also forgotten is the Perl community's endless procrastination in adopting a meta-object protocol (MOP) and the too-late arrival of Miyagawa's brilliant contribution - PSGI/Plack. These 2 factors, I believe, led to Perl being overtaken by Rails, Django and the various PHP frameworks.

Perl’s lunch was eaten more by Ruby IMO. The bifurcation happened as the Perl programmers that wanted a more traditional OOP system picked up Ruby and the folks writing Bash++ oftentimes went to Python. These days it seems like Ruby is where Perl was in 2010.

    These days it seems like Ruby is where Perl was in 2010
It's more "mature" than "abandoned" IMO. I think it's in a solid place. A lot of Rubyists have moved on but so far, that's OK with me.

Unlike OP's experience with Perl, most legacy Ruby and/or Rails codebases are not too disasterous.

That's probably because Rails hits the sweet spot. It's just complex enough to support a medium-sized website well. Most innovations since Rails have targeted high-load websites.

mod_perl was dropped with the release of apache 2.4 in 2012 (that's a major release, apache is not semver). If I remember well, it was kicked out of the apache repo.

mod_python was also abandoned around the same time. It simply stopped being developed and stopped working (it's crashing on python 2.7).

Basically applications stop running inside apache memory with mod_xxx for good reasons (it's unstable and crashing both apache and the app). Languages moved to a FastCGI interface or to have a standalone web server.

Do you mean faster to write, or faster to run, or the combination of both?

Both. Perl is around 20x slower than C for common tasks, while Python is around 133x slower than C for common tasks like looping, depending on what you're doing of course.

Perl is the ultimate mockup language in that you can crank out code very fast and get good bug free results. It lets you write in the way you think where other programming languages force you to write a specific way. Ofc you can get good at Python, so good at it you might get as fast as Perl. And Python is easier to read. The advantage of Perl, writing like you think, makes it difficult for anyone but you (or someone else who thinks like you) to read and maintain your code. The ugly code stereotype comes into play from this.

Perl isn't like Python. It's great if you want to write a one off script for doing quick analytics or a one off script that checks something on a server. It's fantastic for that. Python, you'd need to google around for a library, hope you find one, grab it, write a 100 lined file, and then finally be done, where Perl was a quick one-liner to do the same thing. Ofc the Perl is going to look like garbage and not be maintainable and the Python is going to look golden and be maintainable. They both fit a different need and different use case.

I don't think your performance numbers are very accurate. I've done a bit of Perl and a lot of Python and they're fairly comparable in most cases. Python is lightning fast for a lot of scripting tasks and I generally use very few libraries for day to day tasks because the Python stdlib is so good.

Unless you're doing something really simple with Perl command line switches that operate over an entire file, I'd bet Perl and Python solutions will be in the neighborhood of the same number of loc even with all the magic in Perl as Python has a lot of modern conveniences. It's easy to build a complex datastructure in Python with nested dictionaries with sets/lists/other dictionaries... whatever. In Perl it's more complex.

No, his estimates look pretty accurate to me. I've also done a fair bit of both Perl and Python (including working with the internals in C).

Perl is significantly faster than Python for many types of common string manipulation tasks. They're both fast, sure, but Perl has some key optimizations.

For maybe some regex tasks sure, but there are also plenty of Python operations that are significantly faster than Perl, not to even mention all the data science stuff. I might have misunderstood the comment as evaluating the language on one thing doesn't capture a broad/general spectrum of usefulness.

Every language in this category will have bindings to domain specific high performance modules. This is part of why performance doesn't matter all that much - we can always push hot operations into another language.

Perl generally outperforms python in core language features.

The benchmarks shown elsewhere here tend to disagree with that. I think at one point that was more true than it is now. Overall though they seem to be comparable enough to where it probably doesn't matter.

Also, the bindings have to exist which they don't with Perl for a lot of scientific uses (PDL is not a substitute for Numpy/SciPy/Pandas).

Don't get me wrong. I own at least 12 Perl books and have reviewed some of the latest Perl 6 (Raku) books and really really like Raku. There's not much wrong with Perl in my book (certainly not what most people claim). I've reached for it a few times at work and found it to be fairly pleasant to use. My biggest complaints about building complex data structures in Perl (yes it's much easier than C, but still complicated if you're coming from Python) and having to remember when something is "$" that in my mind should be "@" have all been fixed by Raku.

I just wanted to point out that your views about it being much faster across the board don't seem to be correct.

Any data to back up this claim? My experience in dealing with large numbers of files, huge data sets, is that Perl generally roars, while python lags. I converted a python code to Perl associated with some recent work, and got a good ~2.5x overall improvement. It varied a bit as a function of the input, but generally Perl is superior in performance. Some areas Python is better, but not many.

No, the numbers are pretty accurate. In most of the cases I've run into, Perl is faster than Python for its operations. Some trivial examples[1] showed up on HN a few weeks ago, about how this person "optimized" python, by eventually replacing python with C.

As for the nested complex data structures, Perl's been doing that forever (e.g. since 5.x started). And its trivial to use.

That's one of the nicer aspects of Perl. Things you think should work, often, just do. And work the way you want them to. It's not perfect. It is very, very good though.

[1] https://scalability.org/2020/05/on-optimizing-scripting-lang...

> I don't think your performance numbers are very accurate.

Food for thought.


So Python is faster than Perl on 6/10 benchmarks? This seems to support my argument that they are generally fairly comparable and definitely not that Perl is waaay faster.

> Ofc the Perl is going to look like garbage and not be maintainable

Please stop perpetuating this myth. It really depends how you write it. Perl isn't going to do the tidying up for you, you'll have to properly structure the code yourself. If you still write Perl code like it’s 1991 then maybe itcs not maintainable. I work on a largeish Perl code base and I can assure you it's quite maintainable, moreso than most Js that people install via npm as we speak.

> If you still write Perl code like it’s 1991 then maybe itcs not maintainable.

This is probably one of the issues with Perl. You can still write Python code like it's 1991 and it will still be readable and maintainable.

no you cant, cuz 2.x python wont work in 3.x ;)

Fair enough, but note that the discussion topic is "writing xyz code like it's 1991", which doesn't exclude using a modern compiler.

Don't forget about PyPy, which may well be faster than Perl (I haven't compared them) or Cython if you're stuck with CPython.

That's a good point.

I tried googling around and couldn't find any speed comparisons between the languages, just talk between the two like eg https://news.ycombinator.com/item?id=8626131

So, I guess I'll address this directly:

The tasks Perl is designed to do are different than the kinds of tasks PyPy is designed to do, so it is a bit of apples an oranges comparison.

PyPy starts to get its speed benefit when a task takes 1) longer than 3 seconds to run and 2) Is directly written in Python, not using libraries written in C.

Perl is designed to parse large files, do string parsing, and one off scripts. It being fast is nice, but it's not designed to be running large math heavy processing scripts to begin with. If a Perl script takes longer than a second to run, not including IO limitations and network limitations, it may not be the ideal tool for the job.

So while PyPy gets comparable to Perl speeds, Perl being fast is almost moot, because it's not designed to be used that way to begin with.

Both I would guess.

Perl in serial is already faster to run than Python, and as soon as you start using threads Perl blows Python straight out of the water. The only reason that stuff like tensorflow or numpy is not as dog slow as the rest of python is that they are bindings to c(++) or fortran libs.

Writing faster is debateable, but Perl has tons of niceties like embedded regex syntax, string interpolation, one-line if/unless that make Perl both more concise and less boilerplatey, which arguably also makes it faster to write.

There is also "faster to maintain". Perls compatibility means that there is almost none of the churn e.g. Python has with regard to syntax and semantics changes. Perl code from almost 3 decades ago usually works quite fine, whereas Python code breaks in every minor version upgrade and needs a complete rewrite for major versions

I've been writing Python for a good while now and I haven't seen too many issues between minor versions.

As for major versions...well...there's only been one significant change in this area (2 to 3) so I feel like maybe you're hyperbolizing a little :-)

Python 3 was released in 2008, Python 2.7 had some kind of release last year but my memory is that up to about 2013 there was still a serious question of 2.7 vs 3 when you started a new project ("I know we should use 3, but then we can't have x-lib!").

So it happened once but it took up about 25% of the last 20 years.

A little. But there were changes from e.g. 2.5 to 2.7 and in the earlier 3.x versions that broke stuff. That never happened with Perl code here.

>Perl in serial is already faster to run than Python

Not it isn't.

>The only reason that stuff like tensorflow or numpy is not as dog slow as the rest of python is that they are bindings to c(++) or fortran libs.

So if I make a foo.py file and run the code, it runs faster. "but it's really c(++) or fortran!" doesn't matter in the slightest.

I feel you. I'm currently at a startup that, somewhat by accident, ended up writing their backend in PHP.

Modern PHP is actually fine; it's largely avoided the issues perl has; adoption of the latest versions is quite high, and it's...fine. Not the best, not the worst, broadly comparable to other languages, and a far, far, far cry from what most people may think of when they hear "PHP". My last job used Node, the one before that used Python; I have personal preferences, but at the end of the day they're just tools, it's all fine. The "PHP: a fractal of bad design" blog post actually made a big impact on the community, and shocking number of the issues listed there have been solved, with rapid active progress ongoing. (Yes, I know, it still has issues, and people still hate it. No need to comment to let me know.)

And yet...

...there's a big chunk of the PHP community that just really isn't on board with any of this. Every time the core devs release a new language feature, vocal critics complain about how the language is becoming more "enterprisey" or "like Java". Even on the core dev team, when they vote about fixing some crazy broken feature of the language from the bad old days, a vocal minority is always against it. The language (thankfully) has not stayed still since 2002, but people are trying.

And of course, when we advertise to hire devs, if we say we're looking for "PHP devs", we end up flooded with applications from people who basically know how to install and configure plugins for PHP based CMSes, or from "senior devs" who have been hacking together procedural PHP scripts for 20+ years and have zero knowledge of software engineering principles, unit testing, etc. We've ended up hiring python devs to work on a php code base, not because no php devs are out there, but just because the community is so....weird. There are good engineers who happen to sometimes use PHP, but they rarely (if ever) identify as "PHP devs".

I dislike the JS ecosystem and it's constant churn and cult of the new, but sometimes you run across the reverse problem too.

I heard the "PHP is becoming like Java" argument in 2005 when PHP 5 came out. I'm surprised to hear it's still a thing.

Funny enough I heard the same thing about JavaScript about 5 years ago when ES6 came out.

> I'm surprised to hear it's still a thing.

Ha, if anything I think it's intensified. A current focus is on adding support for annotations (aka attributes from C#), which will be strictly opt-in and replace an ugly pattern currently widely used in PHP land of using docblocks to store them and then parsing them out at run time. "Hey, people keep storing these things in comments, lots of other languages have them as a real feature, let's do the same and make things saner and more efficient."

Simple right? But no, it's actually been quite controversial, and by no means just due to bikeshedding about syntax. Here's a selection of quotes (all highly upvoted) from a recent announcement on the PHP subreddit announcing that the feature has been accepted for PHP 8.0 and linking to a detailed document explaining the use case in painful detail:

"What problem is this trying to solve? I don’t think I’m a fan." "Not sure if I'm a fan. [...] IMO it got way out of hand in Java." "How about no? What does it solve that you can not already program with PHP. If other languages are any indication, its one of those changes that WILL get misused from here to high end." "yeah no thx"

Haha no. Php 5 has proper class definitions. Php 7 adds a spaceship operator, use declarations (yay Perl language features), return type declarations etc. Js was still prototype based the last time I've checked.

It was self inflicted damage.

PHP 5 felt like two distinct languages - PHP 4 and Java parts. PHP 4 was ok for its tasks, Java parts bolted on top, very unnatural, no continuation. In essence community was subverted. Other prominent examples - pulse audio and systemd. Compare it with Perls "bless" - looks so elegant and natural.

Some people do not buy that change, stick to origins and it makes sense. There was a conference talk "most programmers don't change their habits, wait until they die". It takes many years to burn and bury those who remember. It is said Moses wandered with his people for 40 years (until no those who were slaves left).

If Java was bolted on top of Ruby today I would not stay. At least because Java is better than Java bolted on Ruby.

You have valid point - stuck in the middle there is no way but forward, burn the past. They have point - someone destroyed the language they liked and you is one of them. No one shames bash scripts for lack of engineering principles, unit testing etc. Please do not disrespect them, it is not their fault.

Yeah a programming language can have such a positive momentum, but the community is also a thing. I think the currently popular programming languages have really healthy communities, go for linting, clean code and modern solutions.

I always avoided PHP but on one job I worked with it after the company was bought. So I had to maintain a billing script written in PHP to be called from the command line. It was running on a huge FreeBSD server that would fail booting oftentimes and in the script you had to change the start and end date each month manually. Of course there was no version control although I was told there was a second copy of that server in case this one failed completely. I wrote the guy (the then CTO) a few times emails with questions but he never responded. Eventually I ported the code to Go with unit tests. I get the point that there is PHP 7 with modern frameworks but those are useless without adopting modern coding and deployment practices.

My experience has been the opposite. I work in a PHP shop and with each new version update, a handful of us are excited about the new changes that get made to the language. Our DevOps team has been on top of keeping our servers running the latest production-ready versions of PHP. So many of the refinements are a welcome change. I'm eager for stronger type hinting and other features that are still coming down the pipe.

No, that's our experience too. We're excited by the changes, eager for each new release, and enjoy being able to write solid code without the language getting in the way (much). When 8.0 drops we'll probably have cake.

...the issue is the community, and (especially) the pool of applicants we get. It may be different where you are, but around here you advertise for a "senior backend dev", and you get a bunch of people with solid experience in, mostly, Python showing up, with maybe a sprinkling of .NET and Java. (Two of the biggest IT employers in town use Python, which skews things a bit, I know.) But you advertise for a "senior PHP dev", and you get all sorts, but (so far) no one we'd consider hiring. (Let me put it this way: The next time one of the "PHP devs" we shortlist turns out to have ever written a functioning unit test will be the first time. And these are people with years of experience, applying for a senior role...)

> it is not the notorious "write only" language that many troll it to be

I dispute that.

I have worked with many languages, and Perl has always been one of the hardest to remember due to non-standard symbol abuse and a few strange semantics.

There is a reason it has that reputation.

Even writing it isn’t easy. I can describe the Python syntax after years of not using it. Perl? No way I remember it.

Understood. I stated that to say my problems with perl is not the language itself. To say it is the "community" is not right either. But basically "what is left of the community" is the issue. Languages like python, ruby, perl, etc are only good (if you want to freelance and make money at least) at being a "skin" around a database. That also entails a knowledge of frontend frameworks and workflows as well. Yet the words "database", "javascript", or "webpack" are very rarely mentioned at any of the perl conferences in the last 5 years! In the case of webpack, that's probably never been mentioned.

Well, I've given talks on databases (Postgres), javascript (vue) and modern devops (k8s etc) at various Perl conferences in the last years, so I cannot agree.

In fact, I'm giving a small talk on Docker today at the Perl Conference in the Cloud, and also a lightning talk about a ~50 line tool to provide an async web server to post to Matrix. https://tpc20cic.sched.com/

Yes, there are a few people entrenched in old ways (and sometimes it pays off to not always use the newest tech), but there are also a lof of Perl devs doing current stuff.

> I have worked with many languages, and Perl has always been one of the hardest to remember due to non-standard symbol abuse and a few strange semantics.

For example?

I mean, the combinations of $%@ are really astoundingly bad. $ alone has so many different meanings and operations depending on context. You won't find that sort of thing in any other language. Not even PHP which for some bizarre reason brought $ along for the ride.

Here's a fun exercise, write a dictionary of arrays. Now write a dictionary of 2d arrays.

In any other language, that's hardly a challenge to both read and write such a structure. Not so with perl.

> Here's a fun exercise, write a dictionary of arrays.

Umm … ok:

my %dict = ( foo => [ 1, 2, 3 ], bar => [ 4, 5, 6 ], );

> Now write a dictionary of 2d arrays.

my %dict2d = ( foo => [ [1, 2, 3], [4, 5, 6] ], bar => [], );

It’s pretty much identical to JS. Not sure how that’s supposed to exemplify how hard it is to write Perl.

I'm not the original comment author, neither am I fluent in Perl. But I suspect they meant nested hashes and not a hash whose values are arrays of arrays. As you point out, the latter is trivial.

To be clear, even a nested hash is all well as long as the depth and the keys are literals (as in your example). It is when keys are dynamic that things get unruly. And god forbid if the _depth_ of nesting is dynamic. All of these are trivial to implement in Python, Ruby, JS, PHP, ...

    %nested = (foo => { bar => { baz => "quux" } });
Access the leaf with

If the keys are in variables, it becomes

For dynamic depth, do you have a specific use case in mind? If I have a tree, I’m probably going to search it rather than using a hardcoded path.

This is why we use strict! The extra arrow is unneeded, as you're working on the actual hash, not a reference to the hash. This is a compiler error with use strict though, so it's not something you would generally be bitten with when writing real code, just internet comments. :)

Whoops, good catch! I had references on the brain. For completeness, that makes it either

or after initializing with curly brackets rather than parentheses to construct a new reference to an anonymous hash

    $nested = { … };
and then use the arrow to dereference as in the grandparent.

I think the point is not that Perl's rules don't make sense -- it's that they're much less obvious than those in many competing languages. In Python, lists are `l = [1, 2, 3]` and dicts are `d = {"key": val}`. Both structures can be nested without any change to the semantics.

> $ alone has so many different meanings and operations depending on context.

Used as a sigil, $ always tags a scalar, a single value.

    $foo = 3;
A reference to something else is a single value.

    $bar = [qw/ apple orange banana /];
The special variable $$ is the pid of the current process, borrowed from the shell. Special variables with punctuation names have length at most one. The leading $ is the scalar sigil, and the latter is its name.

Dereferencing a reference to scalar is rarely used and looks like either

    $$baz = $quux;

    ${$baz} = $quux;
In a regex, $ broadly means end of line, but the exact meaning is context sensitive: possibly end of buffer, just before a newline at the end of a buffer, or end of logical line within a buffer. Where it matters, the anchors \z and \Z have less flexible meanings.

Of those, the kinda fuzzy one is $ inside a regex. The rest follow consistent, simple rules. I’m not sure what you mean by different operations on $. Am I skipping a difficult case you have in mind?

I think shells did $ for vars first, then Perl added @ and % for arrays and hashes (and then $ was refs)

$string was in BASIC. I'm sure it's even older, though (the oldest BASIC I've used is GWBASIC).

I thought BASIC had $ at the end, not at the start? It has been a long time since those days, though.

> I mean, the combinations of $%@ are really astoundingly bad. $ alone has so many different meanings and operations depending on context. You won't find that sort of thing in any other language.

I kind of felt lost first getting started with Scala where I felt like there was symbol overload.

A classic (hope I didn't get it wrong):

    print "[", +( join '', map { "-> $_"  } @$_ ), "]" for @{$ref}

The concatenation operator is . in Perl and ~ in Raku. You could write a normal, braced foreach loop with another one inside and not use $_.

> print "[", +( join '', map { "-> $_" } @$_ ), "]" for @{$ref}

Because computers are so slow, memory is so limited and disk space is so expensive the programmer absolutely had to write it in a single line in the most convoluted way possible? Yeah, that's definitely a language fault.

This is pretty idiomatic Perl, and I've seen similar constructs countless times at work. You could indent the map body but it normally wouldn't be done for such a short expression. There is not much room for maneuver there if you don't want intermediate variables.

And this is a quick sample, there is much, much hairier stuff to be found in real code. "Knowing the language well" is seen as a virtue for many.

The problem is that it takes a lot of skill to write elegant Perl. The easy way is the one that produces write-only crap.

The problem with any language like this is that you have to work with others, and if others produce write only code that's your problem, too.

> perl has been the same since 2002

if you ignore perl 6 then you might as well ignore python 3. And even still, python 2 is dead. There are only a handful of languages as well maintained as Perl 5.


Perl maintains strict backwards compatibility. I can run code that was written decades ago. I really am curious what features you think Perl 5 lacks.

> Another issue is just the bit rot of cpan.

Sure. But NPM exists. There is unmaintained JS code that was created only 6 months ago. Github is littered with orphaned garbage. I could probably find a dozen or so packages within my company's node_modules folder. Perl is less used today so of course the packages are outdated. But in terms of purely giving a crap... no one gives a crap about NPM. No one. It's largely abandonware on the day it's created. I never really found that sentiment to be the case with CPAN. You had to make an effort to get a package out there. The care people put into packages like DBI was incredible, compared to anything I've seen on NPM.

I don't use Perl much these days. But the hate it gets on HN is insane. It's had a lot of what people consider "modern" features as far back as the 1990s. I really haven't seen a single thing Python, Ruby, or PHP have done that much better.

I haven't seen that much hate for Perl on HN. I personally used it for quite a while and liked it a lot. But I think it's reasonable to consider it a legacy language these days, next to Fortran, Ada and TCL.

Are these languages still used in some niches? Certainly, TCL is still big for scripting ASIC/FPGA design tools last I checked. Similarly Perl projects will still be used and maintained for a long time, it may well outlive us all.

But it's very hard to defend using Perl on a new project these days. I know I wouldn't. I have very little love for Python but I'd go with it instead of Perl almost every single time now. There was a time where CPAN was the killer feature of Perl. Now Python caught up while, as the parent points out, CPAN is slowly rotting due to unmaintained packages. NPM being a mountain of trash is entirely irrelevant frankly. And it's not like in its heydays every single CPAN package was a marvel of software engineering either.

>The care people put into packages like DBI was incredible, compared to anything I've seen on NPM.

See, even you use the past tense. There's no argument that DBI is great. That's not the point. Languages survive not because they're good or bad, but because they have community and corporate support. That's why PHP holds up pretty well while Perl slowly falls into irrelevance. We can lament it, we can try to fight it, but can't deny it.

Tcl is (last I knew) still remarkably big on “the edges” of networks: f5/a10 devices (iRules scripting[0]), used to be (is it still?) used for Cisco iOS scripting[1], was used as the glue language for Tealeaf session/network capture[2] (when it was deployed as on-premises installation ), and control language for Argonne National Lab cluster control[3]...

[0] https://devcentral.f5.com/s/articles/irules-concepts-tcl-the...

[1] https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/co...

[2] https://help.goacoustic.com/hc/en-us/articles/360043736414-P...

[3] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf

Also heavily used in banking and trading systems (Fidessa).

Also heavily used in software testing, including DejaGnu for Linux binutils.

Also heavily used in health care information management (Infor Cloverleaf).

Chip design, internet routing, compiler testing, finance, health care.

A legacy language that's only used anymore when basic infrastructure really, really has to work.

> I really haven't seen a single thing Python, Ruby, or PHP have done that much better.

explicit function signatures for one!

Perl has had those since 5.20, although they're optional.

> Perl maintains strict backwards compatibility. I can run code that was written decades ago.

I used to spout that off too, but I now think it is just a myth. When the leader/creator of the language abandons it and it sits there stagnate for years, what other "feature" can you advertise? I know, "strict compatibility"! I saw it as a feature as well and even used it as an excuse to not learn python.

But even worse it has tainted an entire generation of small business perl dev shops. They seem to think that they can't move to another language because every couple of years back compatibility in language X breaks and at the same time spout off how their perl CGI scripts from 1998 still work fine ("fine" because it hasn't been hacked yet). Ironically doing this all from their windows laptop that has broken compatibility through many release cycles.

Breaking compatibility and refactoring is a sign of health, not death! But now these old school dev shops have large customer bases on old perl who's customers are not used to paying for any kind "upgrade" (and now they never will be). Contrast that with every now and then on /r/django someone will post a question like "my development firm is wanting to charge me $3k to upgrade from django 1.2 to 2.0 before they will add any new features to my web shop. Is that a good deal?". Its just a fact of life now. Software needs to be upgraded. The only reason that perl apps aren't at the top of all security and sql injection attacks is because there are so few of them (combined with the fact that so much of "perl apps" are custom code from the ground up). Never upgrading your stuff is not a "feature".

It's the same with python 2.7 as well. That is because it is dead, it now has "strict compatibility"!

> I really am curious what features you think Perl 5 lacks.

That's a good question. Really, perl can do anything that python can. So what gives? I think the biggest thing that I struggle with just goes back to the "community". I'm trying to stay brief as not to out myself or my last company, but in most cases I was given requirements for a new project and I was off on my own. That's fine. But sometimes I'd be given requirements for a new project and then get micromanaged. As in literally told how to organize the entire project down to little bits like "when a user registers a new account, a function will return a random string 6 characters long and be sent via email to the user and this password will be stored in clear text". That is not the exact case, the real case belongs on codinghorror.com.

But the point I make is given requirements that break normal sane patterns, in python I could go to a mailing list or /r/python and post my issue and expect plenty of answers that I could then show my boss that he is not right. That does not exist in the perl world. I'm sure some perl guys will try to chime in and disagree but it is true. I have asked several question on /r/perl to get advice on really stupid architectural requirements but got 0 responses. The same goes for the perl mailing lists and irc. Its all dead. Many times I've posted to python lists pretending to be making a flask app or something just to get some advice on some webdev best practices, etc, not easy questions but just looking for a discussion. It's embarrassing on the perl side.

> Breaking compatibility and refactoring is a sign of health, not death!

That is entirely dependent on what type of project it is, and what it's used for. Software that is not getting new features added and expected to work as it was and maybe get the occasional bug fix has no need for refactoring, and refactoring is almost definitely going to be detrimental before it possibly yields benefits.

A simple example of this is core Unix utilities, firmware, etc. When the scope is kept small, and the engineering is done well, those just work, and are expected to keep working. People aren't clamoring to refactor cp and mv. It is harder to keep these constraints sane as the code and project increases in size though.

Now, the ability to somewhat safely refactor is a sign of health, because it means there's high understanding of the scope of the code/project, and well known ways to test. That's a far cry from actually doing so, and I think you would be hard pressed to find a project that was undergoing a major refactor and breaking compatibility that I would look at and say "oh, they must be so healthy, because that's what healthy projects do, break backwards compatibility and refactor." The only reason to actually take on those tasks is because you have problems you think can't be fixes without them, which is not an indicator of healthiness.

> The only reason that perl apps aren't at the top of all security and sql injection attacks is because there are so few of them (combined with the fact that so much of "perl apps" are custom code from the ground up). Never upgrading your stuff is not a "feature".

Just because your experience is web apps doesn't mean that's all there is. Do user facing applications that process user input need a lot of updates to make sure they stay in-line with security needs? Yes. Is all software user facing? Does all software need to support something as complex as a browser? No. Different classes of software have different classes of requirements. Does "it will still run on a new interpreter 20 years later" sound interesting to someone doing web development? Probably not. Does it sound interesting to people running system software, that often pay hundreds of dollars per system just so they can run an OS that back-patches security problems so they have a stable running environment with minimal change for 5+ years at a time? Hell yes it does.

But that's okay, you want current, modern Perl web apps? Use Mojolicious. It has a well defined deprecation policy, and you're forced to update your code if you stay up to date with it and be secure, just as you would expect from any Modern web app that takes things seriously (because some problems well be architectural, and may require user changes to fully accommodate).

> But the point I make is given requirements that break normal sane patterns, in python I could go to a mailing list or /r/python and post my issue and expect plenty of answers that I could then show my boss that he is not right. That does not exist in the perl world.

I'm not really sure what this has to do with Perl or Python. This is security, systems, and web best practices, and the language is irrelevant to the example. You shouldn't need to go to /r/python to tell your boss that storing a password in plain text and with bad requirements for users is bad practice. Sure, it might work, but I think it's more indicative of cargo-cult behavior, and spreading it. If I'm building a Perl app, or a Haskell app, or Rust app, I should be able to pop into /r/python or anywhere else I expect someone might be around with experience, ask about best practices, and get a response that is not couched in "we just do X in flak/django whatever". If someone isn't explaining why storing passwords in plain text is bad, then they aren't really giving a good answer.

> The same goes for the perl mailing lists and irc. Its all dead.

That's now my experience. I don't bother going to IRC often, but I get helped whenever I do. IRC still seems to be the preferred medium for Perl devs to congregate and communicate. Not much else I can say about this, you didn't really provide much info other than it didn't help you and there's nobody there to help you, and my experience is different.

There are a lot of modules and historical code stuck in old paradigms, but those are useful in their own way for backwards compatibility. There's also newer Perl modules that see heavy use, like Type::Tiny, Mojolicious, etc. We do a lot of internal web-apps with Mojolicious at work, and our larger ones make heavy uses of websockets, async code, and in some cases Vue.js.

> The ORM and drivers for both postgresql and sqlite don't even support most of the features added in those systems since 2014.

The popular ORMs for Perl (DBIx::Class, etc) are fairly DB agnostic, so work with Postgres, MySQL, MSSQL, Oracle, etc. You aren't likely to see specific features for one DB in them because of that. What you gain is a consistent and advanced interface for interacting with databases which is mostly the same regardless of the back-end for that project.

There are newer, specialized modules such as Pg or Mojo::Pg to give you specific Postgres capabilities or to enable a more asynchronous model if that's what you're looking for.

Sounds like you had some bad experiences, and that sucks. Nobody will blame you for "jumping ship", but I would suggest you not think of it necessarily like that. You learn and code what you have to for work, and you learn and you code what you feel like or you think gives the most benefit personally. Those naturally change over time for a lot of people, and sometimes they are the same sets of items, and sometimes they aren't. If you ever want to play around with Perl again, even just for fun, it's there for you. It's not going anywhere. Perl doesn't have to be the language you write to make a living, or even the first one you reach for for certain projects, but it might still be a good option for some things, and there's no reason to discount it entirely if you still know how to use it and can find a use case for it.

For example, even if I stop using Perl primarily for development, I'm pretty sure it's going to be the tool I reach for when I need to quickly process some data for the foreseeable future. Just the fact I can pull in anything from CPAN to supplement a one-liner (or a one liner I've copied into a file and formatted to turn into a small script) makes it invaluable over just awk and sed.

As a 53-year-old Perl developer (my CPAN handle is MICHAEL, I'm that old), I freakin love Vue.

I haven't done paid work with Perl since the 90's. Now I'm glad I haven't. I use it for my private work because it does what I want it to do, but on the few occasions I've coded for pay since leaving the industry, I've used Python.

I did object oriented programming in Perl from 96 to 2010. We used Perl to create scalable and maintainable enterprise applications. Perl was a pleasure to code in. It is unfortunate the whole Perl6 effort ended up killing Perl. Although I have moved on to other languages, I still haven’t found an enjoyable language as Perl.

Perhaps then, now is the time to have a look at the Raku Programming Language. It is said to be optimized for fun (as in -Ofun). https://raku.org

> A few years later one of the newer employees on the customer support team started spouting off about "python" and how it was so easy to learn. He was always blabbing about terms I'd never heard of like "generators", "list comprehensions", "decorators", etc. I looked them up and learned they were just abstract constructs with fancy names that are supported in most any language. So I just figured he was some idiot that didn't really know anything. Otherwise, why would you be blabbing about abstract constructs?

> I can understand how a 50 year old perl dev (the typical age) would hate javascript and instead put as much code in the back end using all kinds of horrid html templates and never ending form post/refresh/repopulate cycles... I can see the "why should I learn javascript if i know perl" ideology, but what blew me away is a constant "why should I learn SQL if I know perl" ideology. Yes I'm serious.

You don't see how this is the same thing?

Not to speak for the OP, but I'm pretty sure that was the point -- he was making fun of himself, especially when he noted that the guy quickly moved on to Google and he himself later started working in Javascript!

> You don't see how this is the same thing?

No.. but feel free to explain.

With my friend that left for google, I was annoyed at him somehow thinking python was advanced just because he was using stuff you could do in any language only he thought more highly of it because of the names. He saw the light of having a clean syntax, I did not, but now I do.

If you look at the history of python, it is an "engineered" language. It was based off of ABC which was a product of a large team of engineers in the early 1980's. Also some of Modula-3 as well. ABC was based off of ALGOL 68 and Pascal. The point is, a lot of money flowed into the design of these languages and python borrowed largely off of that base.

I used to know perl's history quite well, but I'm fuzzy on that now (and stopped caring). I know Larry was quite skilled at whipping up compilers and parsers from scratch, and he was heavily involved in linguistics, but I feel he sort of just did his own thing. The reason to make perl6 in the first place was to make a "proper" language. All of the lexer and parser code in perl5 are purely custom and intertwined. There's no way to change the parser or add an AST without just starting from scratch. That is what perl6 tried to do. But with python, these steps were from the beginning in proper "layers" and that helped the language to evolve with the times better as well as just having a cleaner VM source code which was easier to work on (the trade off being it was slower than perl in many cases).

The end result is python is "syntax with training wheels", you can't deviate too far before it fails to compile. While perl will compile just about anything as long as your semi-colons aren't missing. For me that made python harder to learn. You couldn't just write anything and expect it to work. For me, I looked at the python docs a lot more than perl docs when learning it. There's no reason why you can't do while y = t.pop: ... in python other than it won't let you. That was something that made me put it off for a long time as it felt it was just full of more rules than syntax. I see the light now though. But the point of my rant here is not that python is beautiful code (which I've always found as an annoying "advantage"), but that the perl community it self if just out of touch with what the current market wants (and needs). And that was the point about the 50 year old perl dev I was making. You can certainly code like it is 1995, but it is not what most people want to pay for (and it certainly is not something we need more of).

> All of the lexer and parser code in perl5 are purely custom and intertwined.

I had given myself a torture by taking a look at perl5/toke.c [1]. Among dozens of lexical analyzers I've ever seen, it is the only tokenizer that uses a probablistic estimator to determine the extent of the current token (grep for the comment "this is terrifying, and it works"). Perl 5 is my go-to language for counterexamples in programming language grammers and syntaxes.

[1] https://github.com/Perl/perl5/blob/blead/toke.c

Oh and I forgot to also say when comparing the languages, you have to also look at the authors too. Guido from the get go was more of a "software engineer" type whereas Larry seemed to be more involved in sysadmin and/or systems programming. I think the languages show that as well.

Pythons "there is only way" is too stiff for me. It may sound nice but in reality does not work, on top of my head - package managers, slots, itertools vs array comprehension, discouraged lambda, and whole python 2 or 3.

A sample of Google Python code I've tried to fix recently [1]. A ton of nothingness. You can produce it in any language.

You are too harsh on Perl design. I thought ruby was popular because it is great language. Nope. Cool kids moved to server side JavaScript. And tried to hide prototype oriented origins, they've added class friends privates now and a ton of other questionable features.

It is all about version 5 dead. I've red Perl 6 Apocalypses, I'd ship. Too bad there was no smooth transition path.

[1] https://github.com/GoogleCloudPlatform/gsutil/blob/master/gs...

You can describe "Perl 6" as the dead name of the Raku Programming Language (https://raku.org using the #rakulang tag on social media). :-)

Thanks for sharing your experience.

I worked some years with Perl, and while it was fun most of the time, it had a lot of frustrating things that made it difficult to have consistent builds and dependency management. The "There's more than one way to do it" mantra is very damaging when all you want is a productive language to produce something, vs having fun implementing or tinkering with libraries in CPAN. There's a lot of research, including taking a look at the code to really know what the library does, to assemble programs in Perl.

Once you get over the initial conceptual barrier and remember how the sigils are used, and get used to the bless object system, it is fun to develop in it, on an intellectual level. But rather annoying on an "enterprise" level.

In the end, I find it very difficult to justify using Perl over almost any other language. Even PHP would be better for dev teams, due to the higher focus on productivity frameworks, even if the language holds no distinctive advantage over any other. I felt Perl is not really a professional language, but the product of a whimsical creator and community (which, by the way, is very welcoming and open).

Python? That doesn't make sense. Anyone who appreciates Perl would surely choose Ruby over Python.

If what you appreciated in Perl was how pragmatic and "batteries included" it was, then Python is pretty clearly the right choice these days. It's got all the packages you want and get stuff done. I don't like Python's syntax, I think it's filled to the brim with false good ideas, but it's so widely supported that there's not much competition these days.

Although I suppose the way things are headed in a few years that might become... JavaScript, of all things. The theory that the world truly ended in 2012 becomes more appealing every day.

As someone who has worked arguably a lot with Perl, Ruby and Python, I too choose Python.

Ruby is just as dead. Only thing it had going for it was Rails.

In Startup Land Rails is still thriving. Check out jobs on Angel.co and HN Who's Hiring.

Is there even a good alternative to Rails?

As far as I know, it's still the best option there is for quickly building a MVP on the web if one isn't building a SPA.

Is Rails quicker and easier than, say, Django? Sure. Is it quicker and easier by enough to make it worth having another language in your stack? Not really, IME.

Laravel[1] is pretty close, and PHP has some big advantages over Ruby for performance and deployment.

If you had told me 5 years ago that I'd be recommending PHP as an alternative vs. RoR I wouldn't have believed you, but the PHP world has improved in ways that I wouldn't have thought possible.

[1] https://laravel.com/

Laravel may be based on the idea of Rails but in terms of programmer happiness it doesn't come close. A typical file of idiomatic PHP code reads like stodgy old Java and contains about 60% blank lines and doc comments as recommended by PSRs. Rails, by contrast, is elegantly concise and has fantastic metaprogramming.

I think you mean in San Francisco Startup Land...the other startup lands are less wedded to Ruby these days

London stats actually ;).

Ruby is doing well as a configuration format. Look at Vagrant and Homewbrew, for example.

Also, there is Crystal, for compiling something very similar to Ruby, to native.

And that Ruby syntax slapped on Erlang

I have disliked perl since I first started using it because it clear it's a hack with hack upon hack of fixes to try to wallpaper over how bad it is.

For example, IIRC it's pretty clear it used to be all variables were global. The solution was a manual command to push a variable onto the stack. That's a horrible solution as it requires perfection everywhere.

Another is all the special meaning but global variables like $_, $. $/ $, $\ $" $; $: $# etc etc.

Any one with any engineering experience learns quick that features like that are an anti-pattern. They're super fragile. Some lines of code down stream are expecting one of those variables to have a certain value. A simple edit somewhere can break it all.

The only languages worse are sh and dos batch files.

This is one if the reasons that the Perl 6 project started (now known as the Raku Programming Language). Raku only has three of these special (lexical) variables left:

  $_    the topic
  $/    result of the last match
  $!    the last exception caught
An overview: https://docs.raku.org/language/5to6-perlvar

Perl was my first real language, too, but I haven't used it in years. Others complain about the sigils and referencing rules but I learned them early, when I was young, so I guess I didn't know any better.

I even had a job where we created a featureful website with just perl, DBI, and no framework except a simple module written by a programmer who left the company before I was hired. I look back to that job fondly, because everything seemed much simpler. Only bad thing about it was the paycheck. :)

A remarkably self-aware comment. Thank you for this.

Thank you for sharing this story, it's really eye-opening

Try go, you might like it. I did.

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird.

And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call

Basically the things I learned in perl were the least transferrable concepts of any programming language I've ever worked with. You learn Haskell, or Forth, or Lisp and you learn insights and patterns that you can use in any language. You learn perl, and you've learned nothing but Larry Wall.

I think you should revisit perl.

My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages.

I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other.

Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse.

It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that.

Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages.

I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.

Do you have a good link to learn about grammars in perl?

Start https://perldoc.perl.org/perlre.html#Extended-Patterns . I was trying to find an article from many years ago, but either my google skills fail me, or it is dead. Perl's regular expressions haven't been regular expressions for a long time. Beyond that, the ergonomics of perl make them much more useful for things like flow control than in other languages. It's similar to how you can do type matching in Java, but it's ugly, versus a language like Haskell where using type matching simplifies the code.

Perl 6 (as lizmat pointed out), has more powerful rules. I don't know a ton about them.

Perl does not have grammars (at least, not built-in). Raku (formerly known as Perl 6) does: https://docs.raku.org/language/grammar_tutorial

> Perl does not have grammars (at least, not built-in).

That's not true since v5.10 (2007). Here's a sample that matches a subset of LaTeX markup:

  $matcher = qr{
          (?<File>     (?&Element)* )
          (?<Element>  \s* (?&Command)
                    |  \s* (?&Literal)
          (?<Command>  \\ \s* (?&Literal) \s* (?&Options)? \s* (?&Args)? )
          (?<Options>  \[ \s* (?:(?&Option) (?:\s*,\s* (?&Option) )*)? \s* \])
          (?<Args>     \{ \s* (?&Element)* \s* \}  )
          (?<Option>   \s* [^][\$&%#_{}~^\s,]+     )
          (?<Literal>  \s* [^][\$&%#_{}~^\s]+      )
It's nowhere near as advanced as Raku grammars (not much is), but it's there, and it's built-in.

it looks to me like HOP is mostly teaching traditional LISP concepts. I could write those same functions in Javascript, and they'd be more readable

With which JavaScript version? At the time HOP was written I remember JavaScript still doing all it's for loops in C-style and there was certainly no arrow syntax to make anonymous JS functions manageable.

There were also no functional methods available, as related by the restriction to C-style for loops. (Array Iteration methods didn't appear in the spec until 2009, so I don't see how you could have map or select or anything else functional).

Perl definitely has a lot of non-patterned arcana. For instance,

$| This variable, if nonzero, will flush the output buffer after every write() or print() function. Normally, it is set to 0.

In other languages, you do something like os.stdout.buffered(true) or sys.stdout = io::buffer(sys.stdout) or something like that where you're combining composable pieces: the standard std variable, a standard way of opening files with or without a buffer, etc. Perl instead has an obscure global variable that you have to look up/memorize, and it doesn't even have a sensible name like $STDOUT_BUFFERING, so readers who come across $| in a file have to look it up/recall from rote memorization, or hope it has a good comment above it.

Sure, it's got lots of historical baggage, but there are more sensible alternatives to $| - like STDOUT->autoflush(1) - it's not like you have to use the obscure versions of every feature.

That certainly doesn't solve the problem of other people showboating their knowledge of obscure Perl sigils by using those ridiculous line-noise abbreviations in code you're trying to use and understand, so you have to look up each bit of obscure punctuation in its particular context in order to understand the code.

If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool.

Having two totally but pointlessly different syntaxes for the same thing doesn't absolve you from having to learn both syntaxes, because you'll still encounter other people's code that uses both of them -- it just gives you twice as much syntax to learn.

If there's a "sensible alternative", then why does there have to be a "senseless alternative" in the first place?

You have to bare in mind Perls roots are as an awk-like language for the command line. In those instances weird line noise syntax was the idiom and as Perl grew it moved away from that but without breaking compatibility by default.

This leads to serious Perl projects relying on the numerous headers (as described in the very article we are discussing) to ensure everyone applies a more modern coding style.

So you can absolutely stop people from using $|

The point of Perl 7 is to have sane defaults.

Because perl improved over time, but they didn't want to break people's existing code needlessly.

No-one ever deliberately invents 'senseless' things, we just discover better ways over time. Sure, if we could somehow magically always invent the best way first of all, that would be great. But we can't, so we make the best of what we have, and improve when we can. But there's no need to punish the existing users of older, 'worse' things.

The concept of giving functions names spelled out with letters that form words that describe their meaning was invented a long time before Perl figured out that doing that was better than overloading a limited set of ASCII punctuation with random abstract unrelated concepts.

You are going to end up perpetually unhappy if you always assume that people designed things the way they did just because of stupidity / incompetence. Perhaps instead you should take a while to think about the reasons why they might have chosen their design. Even if you can't immediately think of a good reason, doesn't mean there wasn't one.

For this particular case, I'm not sure what drove the selection, but I would guess (since the decision would have been made many decades ago!) it was probably based around perl trying to operate similarly to other command line tools of that era, like awk, sed, (or even ed?), so that people could switch to perl and have a familiar environment? But I don't know, nor have I researched it. In any case, perhaps give the designers the benefit of the doubt before assuming their incompetence?

Yes, that is how Perl evolved. It's called "whipupitude" in The Land of Perl. Larry's initial goal was to create a better sed/awk for Unix.

...and how many of them were designed to be sprinkled liberally in the command line?

Python has a REPL but you couldn’t dump a Python one liner in your Bash pipeline.

Maybe a LISP might qualify but then you’re back to a language family that is unreadable to many and unknown to most (and I say this as someone who loves LISP)

When talking about the original design of Perl you can’t put it in the same category as Python, Pascal and the C-family of languages. Perl was born from an entirely different problem to solve and that’s why some of it’s historic features seem so alien to people outside of the Perl community.

Whatever happened to the neophyte raising him/herself up to level of the master? Programming seems to be the only profession in which the beginner is excused learning the language thoroughly and, worse, that he/she expects the language to be dumbed down to make it easier to learn. Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"? If you want to grok Perl learn Perl ... thoroughly.

> Programming seems to be the only profession in which the neophyte is excused learning the language thoroughly and, worse, that he/she expects the language to be dumbed down to make it easier to learn. Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"?

Yes. Yes I can[1]

[1]: https://how-to-play-electric-guitar.net/tab-symbols.html

The problem isn't merely that notation is easy/hard, but that people will not only pass judgement about a language (or any other idea), they will also work actively to convince others to agree with them, and oh yeah, that programmers are people too.

> programmers are people too

Are we really?

> Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"?

You mean like string instrument tab coloured by finger instead of sheet music? Yes, exactly like that.

Language is a tool for programmer.

Restrict scale to pentatonic even for professionals (remove physical keys, holes etc). They would absolutely mess up otherwise.

But you would still have to master notation if you were to become an accomplished jazz musician, for example.

Sure. The context is "dumbed down to make it easier to learn" not dumbed down and forced on everyone. If you want to go full Brian Eno, you can. (https://public-media.si-cdn.com/filer/2b/e0/2be067d0-c428-40...)

> "Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"?"

Yes, of course I can: https://en.wikipedia.org/wiki/Simplified_music_notation and from the linked website "is designed for learners in general".

> "worse, that he/she expects the language to be dumbed down to make it easier to learn."

And why should "simplify" have the connotation "dumbed down, for dumb people"? Everyone benefits from simpler things with fewer warts and fewer hazards.

Perl is an old accordion.

If what you're saying is true, then why aren't similar criticisms raised against Ruby? Most of the same obscure variables are also present in Ruby.

"If hard-to-read-and-remember syntax exists, people WILL use it"

This statement doesn't appear to hold up under scrutiny.

I suspect that Ruby has almost no usage. I've only ever heard of using it in a handful of startups from the valley and it's only Ruby on Rails.

Wouldn't be surprised if Perl had a hundred or a thousand times more developers, it used to be popular in the 90 and 2000s. They are still alive today and commenting about it, even though they're probably working professionally in something else.

> If what you're saying is true, then why aren't similar criticisms raised against Ruby? Most of the same obscure variables are also present in Ruby.

Not with the sigil names, are they?

Indeed, there are a lot of them actually https://ruby.fandom.com/wiki/Special_variable

Your boilerplate whataboutism confirms my point.

>This statement doesn't appear to hold up under scrutiny.

What scrutiny? I don't see any scrutiny. You just said that, without scrutinizing.

> If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool.

Just like every human language that ever existed. And last time I checked, programming languages aren't used or written by AI's or aliens.

Some things are unavoidable though. Perl hijacking a user space variable to do internal sort management? Bizarre to my mind, and utterly confounding the first time one accidentally runs into it.

[0] https://stackoverflow.com/questions/26127617/what-exactly-ar...

I take it you've never done much shell scripting? This part of perl's baggage comes from its roots as a "better" shell/awk/sed. I don't like it any more than you do, but I must say, I wish people would reserve some of the vitriol they have for perl for the shell. Because I gotta tell you Rabbi, perl is a hell of a lot better than shell scripts. And that's even if you compare perl4 (1991-1994 or so?) to the very latest bash or zsh.


BTW if $| is really at risk of clashing with a variable you defined... something else is wrong. :)

Compare that with the shell, where names like IFS can do unimaginable things if you don't know about them and set them by mistake. (Or maliciously; it's imported directly from the environment, and stuff like this is why shell scripts can basically never be given untrusted input, whereas perl, with the 'taint' option, can.)

Reflecting on all this it's pretty sad that newbies in 2020 are encouraged to learn bash, and continue creating arcane, unreadable, booby-trap-laden scripts in it, all the while looking down their nose at perl.

That's not so much Perl hijacking a user space variable as Perl having some single character globals that have special behavior. Really, you usually learn about those early (sorting is common), and if you're using strict like you should be, if you define them and use them they will work as expected until you use a custom sort, in which case you'll track down the error.

In Perl, you learn pretty early that single character non-alphanumeric variables ($|, $_, @_ $@) are special and if you encounter them and don't know them, look them up. You also learn that $1 through $9 and $a and $b have special uses, so don't use those without knowing what you're doing either.

> utterly confounding the first time one accidentally runs into it.

Yeah, but every language has some of those. Who remembers "Unexpected T_PAAMAYIM_NEKUDOTAYIM" in PHP? Or giant template error messages in C++? Or just plain segfaults? All paradigms and the languages within them have their own trade-offs and gotchas, and part of learning the language is learning those.

Developers spend most of their time reading other peoples code, so yes, one does have to learn the less sensible alternatives, if you choose this tool. It's called historical baggage for a reason.

With any luck Perl 7 with phase out the archaic linenoise features. This is overdue IMO.

I'm no fan of Perl, but you can use $OUTPUT_AUTOFLUSH instead if you "use English;". So this isn't really a Perl language thing; it's a style thing. Other languages can be made to look really bad with poor style. The question then becomes what is culturally accepted, and what is not.

`use English;` as a directive feels like the programming equivalent of someone on TV saying "ye ye ye can you say that in English!?"

Only, it's the programmer saying it this time, not the layman. Perl is a 10x engineer.

The problem is that nobody ever tells you these things, the documentation doesn’t cover them and as a result everyone still uses the terrible original syntax.

What do you mean the documentation doesn’t cover them?


One can also:

    use IO::Handle;


TIMTOWTDIBSCINABTE (pronounced "tim toady bicarbonate").

"There’s more than one way to do it, but sometimes consistency is not a bad thing either."


(for those unfamiliar: https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...)

$| is related to pipes. Much of the sigils are like this.

It suddenly makes sense and isn't so bad.

The $ is a sigil, so it appears before variables like $var, so it's just saying | it out. When typed at the beginning of a one liner it becomes quite obvious what you want. This is clearly not a feature for a large project, but a quick UNIX style one off awk-like script.

In Perl `$` is strictly a scalar variable though this can be a reference to an array, hash or object as they are stored as references. Not to be confused with `$` in PHP which simply denotes a variable of any kind. In Bash `$` denotes the value of a variable.

Perl was my first encounter with regular expressions. To this day, no language I've used does it better and cleaner. This includes Python, Boost/C++, Java, JavaScript, LISP, Go and Rust.

Favorite syntactic sugar feature: the /x modifier which makes the regex ignore spaces and comments, meaning you can break your regex into multiple lines and comment them.

Have you ever read O'Reilly's "Mastering Regular Expressions" by Friedl? He does a deep dive into the weird guts of regex modifiers.

I was obsessed with that book one summer and wrote a bunch of parsers after learning incremental techniques (/o I think), and then 8 months later I could no longer remember how anything that I wrote worked. Lol me.

Friedl's masterpiece was my introduction to server-side programming in 2000. I'd been doing front-end for a few years with Dreamweaver and I was looking-up it's find & replace features in "Dreamweaver Bible 8" where regexes were mentioned as the ultimate weapon. "Mastering Regular Expressions" was referenced in a footnote and fortunately my local library had a copy. My mind was blown. Regex symbols were just so powerful and the examples were mainly written in Perl which added even more power to them. The book was part of O'Reilly's Perl bookshelf so in addition to Friedl's book I bought the other Perl classics - "Programming Perl", "Perl Cookbook", "Mastering Algorithms with Perl" and "Learning Perl". With CPAN downloaded to my local disk I felt like a hitch-hiker setting out on a journey around the world needing nothing more than Perl in my backpack. Those were the days. Now I have to download 200Mb of node_modules before I can get started.

Recently I found some old floppy drives at the back of a drawer. I manager to find an usb disk drive, inserted the floppy, what do I find? Sure enough, Perl code I've written back in 2000! Indeed, those were the days :)

If it was back-end website code it probably used Lincoln Stein's CGI.pm module which was used everywhere though it was a bit of a beast with frequent security updates. I later progressed to CGI::Application for an app which ran a business for 12 years before I converted it to Rails. I always thought Mojolicious was a great Perl web framework but unfortunately it landed just as Rails was picking-up steam.

FWIW, this is the default in Raku regular expressions.

Oh, thank you, didn't know that!

Raku is Perl programming language so that makes sense.

If you're interested in improved regular expressions, I wuold suggest you have a look at Raku's regular expressions and grammars (formerly known as Perl 6): https://docs.raku.org/language/regexes

Agreed. Regex is a “part of the language” not a bolt on library like you have in Python. It’s one of those cases where you don’t even know how crap regex is in another language if you’ve never used Perl.

I mentioned Boost's Regex in C++ (boost is essentially a different language), but I didn't bother to mention my experiments with regex in C, for example:


I mean, you can do it, it just lacks elegance. And TBH, I still prefer C for lots of things.

You should check out janet-lang.org. It's got built in peg parsing.

Awk and Ruby aren't on your list, any experience with those that you could compare/contrast with Perl?

Awk is very similar in syntax, but doesn't provide the sophistication of match vs subst, and doesn't support suffix modifiers.

I only used Ruby briefly over 20 years ago so I can't comment.

I do recommend Haskell. (But do not go into regexes first!)

But even though it has a similar powerful set of operations for regular expressions, people mostly don't use it, because there are better ways to deal with text.

Funny you should mention Haskell as it was used to bootstrap one of the early versions of Perl 6 if I remember.

You would like Crystal, it has similar regexes

> You learn perl, and you've learned nothing but Larry Wall.

Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose.

Today I can run Perl code written two decades ago, but with the latest interpreter. I don't think any other interpreted language can do that, can they? (Bourne shell?)

Not a Microsoft fan, but simple C / Windows API code from 25 years ago would likely compile and run on Windows 10 unchanged.

My limited experience with Swift suggests that even 25 hours ago could be a tall order...

Moreover, a Windows .exe compiled 25 years ago will also likely just run.

25 years ago is 1995, and around the release of Windows 95, the first 32-bit version of Windows.

A .exe compiled 25 years ago would probably be a 16-bit executable, and Windows stopped supporting Win16 code in Windows 7. WINE theoretically supports it, but 16-bit userspace code and a 64-bit kernel do not mix well.

> the first 32-bit version of Windows.

Windows NT was released in July, 1993. Almost exactly two years before Windows 95.

In 1997 I joined a company where I was doing Win32 coding, on a Windows NT code base that dated back to 1995. The code base also had parts targeting Windows CE client devices. (The company was an extremely early adopter of that platform; they might have done some of the development before CE was officially released in 1996. Anyway, that's another 32 bit Windows from almost 25 years ago, and less of a hack than 95.)

I don't think that's true. The 32-bit versions of Windows still run 16-bit binaries.

Just run a 20 year old binary and worked fine; I'ld lie if I said it didn't impressed me

Eh, simple C code with X11/Motif will compile fine under Unix too.

TCL, but 7.x code may have flaws.

JavaScript probably can, or at least mostly. That's where a lot of its problems come from, historical baggage.

JavaScript didn't exist 25 years ago.

(The first version was released in September 1995, but wasn't JavaScript until Dec 4, 1995.)

> Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird.

Have you even seen what Javascript is calling OOP? Or the weirdness around "this" keyword? They finally have a "class" keyword, but it's just syntax sugar on top of the weird prototype hashes they have always used.

Lots of languages have weird OOP systems. C++, in particular, if you really want to dive into that. Maybe Java and Ruby are somewhat sane. But I'd prefer not to use either of those, myself.

OOP will rot your teeth.

The Moose library is a pretty advanced OO library that was inspired by Common Lisp's CLOS & Smalltalk I think. Most Perl developers I know use a large amount of libraries as the language itself is lacking in many areas. A lot of people are fine with that, but I prefer kitchen-sink languages which are fairly opinionated.

At least one of the inspirations of Moose, was the object system of Perl 6 at the time (now Raku https://raku.org using the #rakulang tag on social media). To create a Point class that has an x and a y attribute, you'd write:

    class Point {
        has $.x;
        has $.y;
Object instantiation is then done with:

    Point.new(x => 42, y => 666);

Forgot about the inspiration from P6 (Raku). Thanks for mentioning Liz!

I'm sorry, Moose is a pig. Its startup time is atrocious. Its run time overhead is non-trivial. People who use Moose in my experience just showboat that they can do OO. Does it help? Maybe. But what it surely does is it makes a program run and startup significantly slower.

Things have moved on. Moose is a bit of kitchen sink. These days you would generally choose Moo first unless you really needed the meta object features. Or to get incremental Moo(se) features you’d use Role::Tiny, Class::Method::Modifiers And Type::Tiny

> And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call

That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.

I speak as someone who has programmed in Perl for over 20 years and at one point was the top poster on Perlmonks.

The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age poorly. And many Perl programmers are deeply confused about the difference between these lines:

    my $bar = foo();
    my ($baz) = foo();
I firmly believe that context is one of the worst ideas in Perl. There is a good reason why it was not borrowed by other languages. It is far better to expand arrays like Ruby does with * instead.

This is why Raku doesn't have contexts in that sense. All a subroutine or method can ever return, is a single object. Such an object can be a List or an Array, but it is still a single value.

Whether context is good or bad, a success or a mistake, there's no denying it is either one of the most or the most important idea in Perl.

That you can not really know how it works and still get by in Perl without problems 95% is a testament to Perl trying to make life easier for the programmer, as well as one of the things that contributes most to people not understanding Perl or viewing it as inconsistent and confusing.

That said, I don't really think you can remove it from Perl without making it a drastically different language. Context pervades almost everything, and is how many idiomatic statements actually function (e.g. assigning a hash to another hash is really just list context read from a hash and list context write to a hash).

> Perlmonks.

Perlmonks, in my view, is one of the main reasons Perl community went nowhere. The answer to a question should not be, excuse my french, an exercise in who can swing their dick in the most intricate and convoluted way while accidentally answering the question in the most obfuscated way possible.

Return a reference to a hash. You are done.

Perl’s core object system isn’t really an object system, it’s a toolkit for building object systems. Of course this leads to too many ways to do it, so if starting fresh just use Moo

I think that criticism that by learning perl one doesn't get any transferable concepts is bit unfair. Though I no longer program in perl, some of the things I learnt using perl has been useful later too. To list here are some of the "concepts" that I learnt using perl: regexes, some aspects of *nix system programming (fork, zombies, signal handling etc.), modular code organisation (writing/using perl modules), code documentation (aka PODs) imbibing importance of documenting the code. True learning some other language (say Java) would make familiar with other concepts (say OOP) but perl has its fair share of concepts that one can pick by programming using it.

On the subject of transferrable knowledge, Perl was the first language I learned, and I was always a little bit confused about why every language I learned since then didn't have pronouns, until finally magrittr came along in R and made perfect sense to me, since "." in magrittr/dplyr feels a lot like "$_" (or "@_") in Perl.

Ok, so I wrote tons of Perl and am to this day a fan, but I don’t think one can call a blessed hash (or scalar for the fancy folks) an object _system_.

It is flexible and fun and I do miss it.

True story: years of passing functions to other functions and map/greps made the switch to FP Scala (another language I fear will die) a lot easier!

> I don’t think one can call a blessed hash (or scalar for the fancy folks) an object _system_.

Perl first, then JavaScript.

Did you know JavaScript classes are blessed hashes?

They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").

Old JavaScript made the blessing crude and obvious.

Modern JavaScript lets you hide it in a "class" decleration. Which you can also do in Perl if you want (though you'll need to choose a module for this, and people generally prefer a different approach to dressing up objects in Perl.)

There's still a blessed hash under the hood which you can see and kind of have to be aware of... in both languages.

Perl and JavaScript both give you a minimally specified set of tools you can use to build your own more advanced object system.

IMO, that's why both languages have been able to be extended and adapt so much.

If you look at tools like Moo and Moose in Perl and the different coding paradigms that evolved in JS before the "class" keyword was standardized, this is pretty clearly evident.

JS has had the advantage of a standards committee pushing new language features aggressively. Perl has moved more slowly, keeping a majority of functionality in libraries.

> Did you know JavaScript classes are blessed hashes?

> They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").

omg, I totally forgot that (I left day-to-day JS use a good decade ago, sorry!).

Traditional JavaScript has a notoriously poor object system yes. If those are the only two languages you know then I guess Perl's object system doesn't seem so bad, but that shouldn't be a defense of either language.

I've heard Python's object system isn't that different under the hood.

You even have the same boilerplate of the first argument to a class member function being the object itself.

Yes. I was thinking mainly of Perl's symbol table which I believe is also how OO is implemented in Python.

My understanding was that Perl's OO system was directly inspired by Python's. I can't find a source on that though.

Other way round I think.

Nope. http://www.perl.com/pub/a/2007/12/06/soto-11.html

> I don’t really know much about Python. I only stole its object system for Perl 5. I have since repented.

Very similar story here; I barely write any Perl nowadays but am still very fond of it.

I especially like the sigils - they serve in a way as a primitive type system and actually convey useful information when reading code. I suspect people who complain about them are the same who dislike strong typing.

Interestingly, like you, nowadays I am very fond of Scala.

I also quite enjoyed perl. There are a lot of us that cut their teeth on perl and know it well, even if we are currently working in other languages. We also tend to de-emphasize it on our resumes for obvious reasons. But if I had a contract opportunity to spend months or years on a large perl codebase, refactoring it or porting it to something else, I'd probably snap it up in a heartbeat.

This seems to be a common experience - people say it felt powerful and modern in the 90s, because it was. For those who started programming in the 00s and 10s it looks clunky and weird compared to the other options.

That doesn't add up because today's most popular languages - JS, Java, Python, PHP and Ruby - were also released in the 90s.

Perl 5.0 was released towards the end of 1994.

Python 1.2 was released in 1995.

The first public release of Java as 1.0 was in 1996.

JavaScript appeared in 1995 as well, but the first ECMAScript standard didn't appear until 1997.

First release of PHP was in 1995, same with Ruby.

Perl pre-dates the initial release of all those languages and was already up to its fifth major version by that time.

To be honest Perl 5 isn't really like Perl 4. They are quite different languages - Perl 4 didn't have objects, and Perl 5 places heavy emphasis on them.

Up to you to decide when you think it started, but I'd say the current language we think of as "Perl" started with the release of Perl 5.

Most Perl 4 runs under Perl 5, and most Perl 5 written in the early years did not place heavy emphasis on objects. When I started in Perl, it was common to write code in such a way that it would run under either because it might have to.

Today, objects are used heavily. And furthermore the way we write those classes has changed a lot since Moose and friends became popular. As a result most Perl code bases written in the last dozen years look less like early Perl 5 than early Perl 5 looked like Perl 4.

Perl 4 and Perl 5 are more of a continuum than different languages.

And even in that case it predates all the other languages except Python by almost a year (Python 1.0 came out in January 1994).

PHP has object since v3 ('97).

Wasn't it then limited to stdClass ?

It does add up because Perl was released in 80's and became popular in the 90s, when the other newer languages you listed were designed and released. In the early-mid 90's, "CGI"/"CGI scripts" was synonymous with Perl - it was the backend tech

Perl was released in 1987. The languages released in the 90s all stole Perl/Awk's good idea (have an associative array/hash map/dict type as a builtin data type) but had much nicer syntax.

I stuck with Perl even when Ruby came along and offered to be the next best thing because Ruby didn't have a use strict equivalent. Having to declare variables before use is a good thing.

Perl5 was released in October 1994. That's the version which competes with Python, Ruby and PHP because it introduced OOP.

There's a subtle difference between being released in the 90s and maturing in the 90s.

PHP was a reimplementation of Perl by someone who didn't understand why Perl did things the way they did and so ended up creating a vastly inferior language. Other than maintaining some legacy projects, I've not touched PHP in over a decade and I'm glad to avoid it. Perl is a tool I still return to for some tasks (one was a bizarre management request for a spreadsheet of all the Java classes in a large project which took fifteen minutes to create a Perl script to generate and ten of that fifteen minutes was looking at documentation for Perl modules I hadn't used in a long time).

Yes and No. PHP (Perl for Home Pages) main starting point for popularity was that it was easy to make into an Apache module that could be used on shared hosting. Perl's Apache module was a single interpreter for the whole server. Great for business sites and such, not good when you have multiple unrelated users using the same server. PHP was just something that you could turn on and uses on your shared hosting.

According to Wikipedia PHP stands for "Personal Home Page".

Yes, the memory isolation model of mod_php was the crucial factor in beating the competition. With mod_perl you had to write your Perl modules to a specification so that globals were not accessible by other hosts. That was too much of a risk for shared hosting providers. The situation is muddied, however, in that a lot of shared hosts only allow PHP as a cgi which, in theory, puts it on a level playing-field with Perl. However, in practice, Perl only has one PHP-alike templating framework - HTML::Mason - and that requires mod_perl to perform decently. So PHP's other advantage is that its templating engine is simply faster.

As far as i know Java and PHP became popular later in the 90s / early 2000s. Javascript was browser only until 2010, Ruby only became popular after Rails came out mid-2000s. There is a decade gap there.

> Javascript was browser only until 2010

Depending on how you look at it you are at least a decade too late: we Java folks had the Rhino Javascript engine back in the late 1990ies, and it had an interpreted mode since 1998: https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine)

I think it is even mentioned in the Javascript in a Nutshell book by David Flanagan (I haven't read it since then but I studied that book as I wrote a map rendering system in Javascript back in school in 2005.)

True, I played with Rhino, Jack / JSGI early on, and did a couple projects with Aptana Jaxer around 2009. It was not really an option most developers would even consider, though.

Node came out in 2009, and writing server-side JS was still a fringe practice for a couple more years, so 2010 is me being generous to avoid comments on the exact timeline ;) It really picked up mainstream adoption around 2011-2012.

Was Rhino ever anything other than a minefield that you were essentially pigeonholed into using for compatibility reasons or something similar? I have used it before but only because we had specific technical requirements that demanded we run Javascript on a server-side JVM implementation.

"Server-side JavaScript" was a feature of Netscape web servers in 1996.

At the end of the 90s Javascript was used to write a part of Dreamweaver and I mean the app itself, not the Javascript/HTML interface. So the language as always existed independently of browser implementations.

Perl pretty much felt clunky and weird as soon as I discovered Scheme in 1996 or so.

I was on one of several CAD teams at Intel in the 90's and huge parts of pre and post-silicon Itanium simulation flows for timing, layout and verification were written in Perl. (Not even Perl 5.6 so we hit the 2GB file limit often!) ... Not the tools themselves, but the control flows and asset managers. The other processors still used Tcl on HPUX/Solaris/AIX so Perl on Linux was like nice warm sheets by comparison.

> The other processors still used Tcl on HPUX/Solaris/AIX so Perl on Linux was like nice warm sheets by comparison.

I would agree, but I don't think you meant it the same way I would: I prefer nice cold sheets when I sleep, and I much prefer Tcl to Perl!

Perl was a great fun scripting language back in the day of CGI and "webmaster@".

It died a noble, honorable death. RIP.

It's not even close to dead.

While you can FIND Perl jobs, it is effectively dead for most of the hiring market. It will never truly disappear. COBOL is not dead either. Is it really something that we think of when we talk about modern software engineering? Not really.

How much production software is started from scratch every day using the language?

I started my career in Perl and I still have fond memories of working with it up to late 2000's, but by that time the writing was solidly on the wall.

Dead in this context means "niche".

True. If you search Indeed.co.uk there are more jobs which mention Perl than Golang.

I hear Perl has weak typing with implicit type conversion. The only other language I know that has a powerful implicit type conversion system is C++. How does implicit type conversion work in Perl?

Conversion is done based on operator, and Perl has different operators for string and numeric operations. For example, == and eq are different operators, with the former doing numeric equivalence comparison, and the latter doing string equivalence comparison. The implicit conversion done to operands in each case is well defined and obvious.

Edit: Whoops, had operators reversed because I explained them after the fact. Fixed!

There is also a concept of "context" in Perl.

An operation may be evaluated in list or scalar context. For example, if you evaluate an array in list context, you get the members of the array, however, in scalar context, you get the number of elements in the array.

This idea is generalized to discuss different evaluation contexts for scalars. You might hear people discussing how a value behaves in boolean or string context. It's also common to talk about casting as "-ification", for example casting something to boolean context is "boolification".

By default, undefined values convert to empty string and 0. However, this can be made to generate a warning or even a fatal exception by setting the appropriate pragmas.

Generally in Modern Perl-style programming, strict and warnings are enabled, so implicit type conversion is not used as much these days. Warnings or errors are emitted.

I've found this greatly increases reliability.

An example is that I enabled those on the W3C checkers and a serious latent bug was discovered and fixed, even on code I wasn't familiar with.

United States District Court filing system for court cases is written in perl. Horrible language filled with one liners that only makes sense in the mind of the now retired and gone programmers. Sadly, I do not know why we cannot pursue other technologies. Perl is a trap... buyers will be stuck for 30 years. Like a mortgage, but without equity or returns.

You might want to go ahead and inform those investors who bought Amazon or Booking.com stock in the early 2000s that their orders of magnitudes of returns were really no such thing.

They last line of the article summarizes it well:

> Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year.

Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.

I wrote a quick perl script earlier today to push crt.sh results for a bunch of domains into slack.

Took about 30 minutes, far less time than messing about with why pip has broken on my desktop yet again:

  Traceback (most recent call last):
  File "/usr/local/bin/pip", line 11, in <module>
  File "/usr/local/lib/python3.5/dist-packages/pip/_internal/cli/main.py", line 73, in main
    command = create_command(cmd_name, isolated=("--isolated" in cmd_args))
  File "/usr/local/lib/python3.5/dist-packages/pip/_internal/commands/__init__.py", line 96, in create_command
    module = importlib.import_module(module_path)
  File "/usr/lib/python3.5/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 986, in _gcd_import
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 665, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/usr/local/lib/python3.5/dist-packages/pip/_internal/commands/search.py", line 18, in <module>

I understand no one wants to deal with unexpected issues, especially when you're trying to get something done. Why not use virtual environments? You keep packages out of your system's python, and if you run into issues like above you can just recreate it:

  b5n:~/venv_dir$ python3 -m venv im_a_venv
  b5n:~/venv_dir$ . im_a_venv/bin/activate
  (im_a_venv)b5n:~/venv_dir$ pip install requests
  (im_a_venv)b5n:~/venv_dir$ pip freeze > requirements.txt
  (im_a_venv)b5n:~/venv_dir$ deactivate

  b5n:~/venv_dir$ python3 -m venv another_venv
  b5n:~/venv_dir$ . another_venv/bin/activate
  (another_venv)b@b5n:~/venv_dir$ pip install -r requirements.txt

The reason I use linux and perl (or sometimes bash) - it just works, I get the least number of surprises. Dependencies in perl are handled by my OS same as everything else, I don't need to maintain multiple package managers, I just bash out the script and move on

I don't write software as an end goal, I write software to accomplish my end goal.

While experienced python devs will say, yeah that'd how you should do it. The problem is that python by default isn't using virtualenvs. Consider rust or is where you need to specify global installs.

I spent 15 seconds trying to figure out how that 'Perl code' runs...

> Are there actually people that are still deploying new things in Perl?

My personal experience: at one of my previous jobs we've had the need to find a support ticket system (preferably free) that was flexible enough to handle a few hundred email accounts with different signatures, headers, reply templates, queues, filters, and more for each individual account. At the time the "winner" was OTRS [0] [1], a system in Perl that is super flexible and had a free version (more recently renamed to community edition since it detached a bit from their enterprise version).

It served us well enough that I have deployed it again on my current job when a similar but smaller need arose (both jobs in tourism industry). It's a pretty big and complex thing but does it's job well once configured correctly which does take a bit of work.

> The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.

That can possibly be the case here since it is "old" (changelog lists the first public beta at 2002) but has had pretty much continuous development until this day. Any company trying to develop something like this these days would probably choose something else but I guess they're a Perl shop now.

[0] - https://github.com/OTRS/otrs

[1] - https://otrs.com/

I actually worked for OTRS for some years. It is quite a remarkable company as it is creating an open source line of business software with a nice team of people and is making a sustainable business out of it. There are not much other software companies that managed to do this.

Yes, you can call them open core now. But still many companies are using the community edition and are served well by it.

I worked closely with the technical founder and he started the pre-decessor of OTRS in the 90s while working at SUSE, and yeah of course it was in Perl!

I must say that working on the quite significant OTRS code base, with proper code conventions, 'modern' perl5 is not so bad. But when using third party libraries sometimes you'd see arcane language usage and there seems lots of magic involved...

Also, the technical founder started https://zammad.org -- the same idea but started in 2012 or so. So now it's Ruby!

Modern perl5 is ok. But the ecosystem is slowly deteriorating.

What I'm hoping for is that Perl 7 will enforce those "proper code conventions" and mitigate that deterioration. Making a lot of common pragmas the default is a good start there.

Nice, thanks for the link and for your contributions to OTRS, it has improved workflows tremendously on both companies I've set it up on. I've messed around on some of the source and template files for some dirty hacks over the years and did get the impression of it being very well structured and with pretty clear separation of concerns even though I'm not a Perl coder.

Yes... We have some high revenue, important contract type systems written a long time ago and maintained by the same subject matter experts who simply move the codebases (old and new) to newer systems and stacks. As you can tell, the SMEs have no interest in learning other things and so any new initiatives that require them to implement it is subject to their preferences.

Many places don’t support antifragility. Having an old system that nobody wants to rewrite may not be a reflection on the engineers.

You’re an expert, and a rewrite is going to expose you to a lot of scrutiny. You are going to break things, when maybe you haven’t broken things in a long time and people like it that way.

So when some day arrives where a new fad is hot and it’s hard to impossible to find Perl programmers, the will create a new team to rewrite it badly because now they have no other choice. And of course the new folks are going to screw up, but that’s just expected.

> and it’s hard to impossible to find Perl programmers

Which I'm finding harder to understand as I learn more languages. Yeah, every language has its differences and idiosyncrasies, but as long as you have access to docs (if not third-party resources like expert blogs or Stack Overflow) it's pretty straightforward to figure those out and be reasonably productive relatively soon.

That is: a senior programmer should have enough background knowledge to be able to be productive on any language ("polyglot" shouldn't be a big deal), and a junior programmer won't typically have enough experience in any particular language to be definitively a "$LANGUAGE programmer". In either case, whether or not a programmer already knows the language before being hired is kind of a moot point.

My current dayjob was the first time I had written any non-trivial amounts of Python, Javascript, or C# in a professional capacity in my whole career. Being productive on them wasn't terribly hard - it's just different syntax around a lot of the same concepts (and sure, there were also some new concepts - took a good while for me to wrap my head around async/await, for example, coming from a background of message passing between threads or processes or actors - but those can be learned).

Usually the choice of programming language is far less significant as a barrier to one's understanding of a codebase than, say, the actual problem domain. Writing software for, say, a warehouse tends to necessitate knowing an awful lot about how warehouses work; whether or not you happen to know a given programming language is entirely secondary to whether or not you know the difference between a picker and a packer, or between a replenishment and a cycle count. Similar deal in medicine, or education, or manufacturing, or sales, or finance, or what have you.

A former boss was fond of saying "Software is done when nobody is willing to work on it anymore."

New people make idiomatic mistakes, and if the language isn't cool they expect more money. Recruiting people is harder, so you tend to get stuck with the people you have, and managers tend to bristle at that. Eventually a new language full of people who look like cogs is going to win out. I hate that this is true, but it is.

I maintained a Python test harness for a while. No prior experience with Python. I mostly stayed out of trouble, in part because I set low expectations, tried nothing fancy. But it wasn't what I wanted to be doing, and not what I wanted the team to be doing. When I left they finally canned the entire thing.

> Python, Javascript, or C#

Those are all pretty basic Algol-family languages (at least if we're talking vaguely modern Javascript). If you were thrown in to J or Forth or Erlang you might have a different experience.

Funny enough, Erlang is my preferred language (or at least one of them).

I don't know if I'd necessarily call the JS in question "modern", though. It's running on RhinoScript, which needless to say ain't exactly the latest hotness. Still, the platform in question does happen to support/encourage AMD modules (with some special comments for certain components), so I guess it could be worse.

There's no need to rewrite a system that works and that you're not gonna change. While programming languages go out of fashion there will always be people who are capable of writing them. The median age of a cobol programmer has not changed in 20 years because more people keep learning the language.

Demand in this case, will likely create its own supply.

Wisdom is in not in spending years and millions rewriting billions of lines of cobol code into a new language and then rewriting that other language into another newer language and so on … what's the problem in maintaining what's already working?!!

I tend to replace my car when it starts to show signs of future problems, not when I'm up to my eyeballs in repairs.

We shouldn't really be treating software differently. The liability for a mission critical system that works but cannot be repaired climbs over time.

Just because it works doesn't mean it isn't broken.

That analogy doesn't really work - software doesn't get worn out from interaction with users. If software is working and in use, then it's age doesn't matter.

Evolution/flux is not the natural state of all software. I've seen plenty of business/enterprise software which has continued to provide business value for decades without structural or architectural changes.

Lots of security patches and infrastructure are held hostage by breaking changes to APIs. Eventually you have to upgrade, and the longer you have put it off the more painful it will be.

And as we've seen with old video games, there are lots of timing problems that you simply never encounter on the original hardware but are impossible to ignore on recent vintage hardware.

There are plenty of silly reasons to rewrite a piece of code, but language preference has to be one of the worst.

Now that I think about it, that's actually a decent hiring test:

Tell the candidate part of their job will be maintaining a small Perl codebase. If they can't deal with that without throwing a fit, I have no interest in working with them.

It's a sharp tool, if you're not careful someone might get hurt. But professionals deal with sharp tools all the time, especially when it's the best tool for the job.

the will create a new team to rewrite it badly because now they have no other choice

Given Perl’s legendary code-opacity and maintenance challenges, this kind of seems inevitable. After all, if you could at least read and decipher the old code, maybe you could reproduce it!

Lots of new things. Perl is an immensely powerful language. If you know how to write code well, it will be fully comprehensible by even casual programmers.

Many orgs ship perl based tools as current, up-to-date products. Mellanox OFED is one I was using earlier today.

My own github[1] has a plethora of perl projects.

[1] https://github.com/joelandman

IMDB was written in Perl, notoriously. Seeing that the layout has not changed in ages, I can only assume it's still Perl.

I'd imagine a bigger rewrite effort would have led to a more slick iteration on the UI, and it seems the legacy HTML templates are still baked in.

DuckDuckGo's also written in Perl, and doesn't seem to have any trouble maintaining a reasonably-modern-looking UI.

And their interview process is apparently, contribute a useful feature to the code base. Which, IMO, is brilliant.

Booking.com is also (notoriously) completely written in Perl.

Hmm ... don't conflate the presentation UI with the underlying language. I wrote my companies website (2 jobs ago) in Mojolicious (perl web framework), with a responsive UI, based in part upon bootstrap. Very modern (for the time) UI. All backed by a very fast implementation.

IMDB seems plenty fast to me. UI isn't great, but that's more of a presentation layer design thing than a language thing.

I am not actually talking about the quality of the UI - I am just pointing out that the UI seems to have been the same for years now, and I would think a rewrite from Perl would have changed that. Yes, you can totally swap out the backend, but IMDB codebase is old. HTML and the sprinkled JS (if you look at page source) is probably baked in deep.

Nearly everything at Fastmail is in Perl. Cyrus, which is the mail storage engine, is in C (and open-source), but everything else is Perl.

The primary use case of Perl is systems automation. Personally I prefer Node.js but most Linux distributions come with a Perl interpreter already installed and not Node. If you are working in an enterprise environment and for security reasons are not allowed to install software, which is common, you can still perform automation with Perl scripts.

Yes. You’ll be surprised. Some of the biggest tech companies still use Perl in their critical components in production, and some of the initiatives are in recent years.

I think the US Courts still use Perl for Pacer (https://www.pacer.gov/psco/cgi-bin/links.pl) and it seems to be used by the US Cours as well: https://ecf.azd.uscourts.gov/cgi-bin/ShowIndex.pl

> Are there actually people that are still deploying new things in Perl?

Anecdote: I found this Perl image-hosting package a couple years ago as a self-hosted alternative to sites like Imgur, and I think it's great: https://framagit.org/fiat-tux/hat-softwares/lutim/tree/maste...

> Are there actually people that are still deploying new things in Perl?

See https://news.ycombinator.com/item?id=23593835

IIRC Craigslist was written in Perl but that's the only high traffic site that comes to mind.

The Amazon retail site is written in perl (at least the presentation layer still is, you can find mason references still in the HTML source if you go looking, don't know how much else behind it is in perl).

https://metacpan.org/pod/Mason (if you're not familiar with Mason)

Actually, that's Mason 2. Amazon use(s|d) the OG Mason - https://metacpan.org/release/HTML-Mason

Duck Duck Go and Booking.com were/are Perl backends.

The fashion retailer Net-A-Porter has been a Perl shop since 2000. Haven't checked if that's still the case. They used to employ quite a few leading lights in the UK Perl community a few years ago.

I think they still write everything in Perl, and they employ Larry Wall (or they did several years ago, last I heard)

I know some fantasy sports site was, maybe CBS? I had a UX designer colleague who had worked on that.

A surprisingly large number of fantasy sports sites are.

Perl is everywhere, it's just not widely publicised because of the stigma attached to the language.

duckduckgo, as far as I recall.

imdb.com is perl.

Most of the ad network backend sites are perl, including a lot of Yahoo.

I used to work for a company that used Perl as their primary language.

The codebase was millions of lines long, modules (pm files) with like 1000 methods and 10,000 lines, a total mess and it had 0 unit tests too. Almost beyond salvageable. Left a bit of a sour taste.

They're trying to migrate to AWS but AWS don't even natively support Perl in their libraries. There's a few third party libraries in CPAN but nothing as comprehensive as what's available with official libraries for other languages.

Nothing against the language but I don't know why you wouldn't use literally anything else nowadays. Python or PHP, JavaScript or even Ruby if you're looking for a dynamically typed language. AWS don't even support Perl.

Perl used to have one of the most extensive module libraries. One of the things I miss about Perl was it’s more sensible module namespace convention (Eg Net::... for networking related) vs the more hip but confusing and hard to discover naming of node modules.

Yes, the hierarchical namespace for modules was super nice. Migrating to a flattened package structure of npm was a disappointment. I ended up encoding the same type of structure in internal npm package names, e.g. "@myorg/net-aws-.." and "@myorg/file-..."

Keep in mind TDD wasn't really invented yet, so it's understandable.

Also, CPAN had better libraries than pip did all the way up until I last used Perl in 2015. Ofc, it depends on what you're doing. My point is, there was a reason to use Perl once upon a time ago.

The alternatives back then were PHP, C, C++ (the old bad kind), BASIC, assembly, FORTRAN, and others like Smalltalk. Seeing this, it's understandable why Java took the world by storm the same way Perl did.

I don't know about TDD specifically but we have the Perl community to thank for setting the bar for rigorous testing back in the ealry 2000s with the numerous Test:: modules on CPAN.

Perl and CPAN definitely do not get enough flowers for their contribution to TDD.

Last Perl shop I worked at was newer than the company you described but well on its way toward being like this.

Since Perl code is often very compact, it probably needs a higher comment to code ratio than most other languages, but you don't see that either.

Your opinion on Perl is based on one code base you worked at on one job?

Honestly that's more than most I think. I've written tens of thousands of lines of perl professionally and I generally share the same opinion.

I've been writing (Modern) Perl for about 3.5 years and I disagree that Perl necessarily tends to unreadable code. I really don't think that's true at all.

To quote myself from a recent discussion:

I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ all the time], code linters, and so on) I think how you use a language plays a huge part in code maintainability.

For instance, I've heard PHP get shit on pretty badly all around the web, but I've worked at PHP shops that had nice, clean codebases, and my current Perl codebase is, in many ways, nicely structured. That's not to say there aren't some hairy codepaths that could use refactoring, but I really think that kind of thing, again, can happen in almost any language.

I think a useful concept is that a project will have a "discipline budget", just like the "language strangeness budget". Yes, if you're careful with your self-restraint and code reviews, you can write good, clean, maintainable code in a language that doesn't give you a lot of support for that. But if you do that then you're expending your limited supply of discipline, and will have less to spend on other aspects of the project like not scaling prematurely, not using cool-but-unnecessary tech...

Very interesting thought! I think I'll steal it.

Strongly agreed. It’s much more about the team, the conventions used, the organization of the codebase, and the coding culture of the team, than it is about a specific language.

True, but the cultures that grow up around a specific language tend to encourage certain conventions, standards of organization, and team coding cultures.

Under that standard it’s true, but it’s also true for virtually any language and is therefore not a good defense of whether or not a language lends itself to unreadable code.

There are a couple of points in there:

1. You can use virtually any language to write clean code

Not sure if I agree with this, though it may well be true. I just know there are some things like Brainfuck where it's designed to be impossible. I realize that language is created specifically for the purpose of making a coder say "WTF", but perhaps there are other languages that are not designed to be so that are really nearly impossible to write good code in.

2. Perl lends itself to unreadable code

If you stick to Modern Perl you still might end up with things like `wantarray` in your code so I guess this is kind of true. You need to be judicious in your use of code.

Some languages lend themselves more easily to writing clean code, like I feel about Go or if you hate the Go type system, Ruby. Even in Ruby I feel like metaprogramming is ripe for misuse.

It's a tough thing to talk about. I don't feel like I wholeheartedly disagree with your sentiment which seems to be "some languages lend themselves to bad code" and subsequently that Perl lends itself to bad code but there is plenty of ambiguity in these thoughts.

In my 30 years (yes) working with Perl (4->5.32), I have never, once, used wantarray. Perl does not lend itself to bad code. Bad coders, people whom cannot use or articulate good practice in coding or documentation, lend themselves to write bad code, in any language.

I used it for automation of my calculations in grad school. For data analysis. For monitoring.

In my subsequent day jobs, I used it to develop shipping products. No one really should care what language something is written in, if it does the job well.

Most recently (a few weeks ago), I used it as the driver for creating and submitted 10's of thousands of jobs for COVID19 research the team I am working with[1][2].

For the above project, I had to forward port 12 year old C++ code to make use of modern C++ based boost libraries. Took a bit of time to fix this. But the perl code, ran perfectly, and quickly[3].

Anyone trying to portray things otherwise, likely has a longstanding axe they like to grind. Language advocacy can be done without attempting to tear down other languages. Though those who argue against perl often bring up the same, old, tired, and incorrect points.

I'll keep using perl thank you. And Julia. And C. Each has their domain of applicability. Most people know and understand this.

[1] https://community.hpe.com/t5/advantage-ex/how-my-supercomput...

[2] https://community.hpe.com/t5/advantage-ex/the-story-of-how-i...

[3] https://scalability.org/2020/04/fun-and-topical-hpc-project-...

Yeah, I've got a Perl codebase that's conservatively tens of thousands of lines, and it's honestly a struggle to write anything in it that isn't a big ball of mud. There's about 50 different ways to do anything in the language, the syntax is infuriatingly obtuse, and you can't rely on any documentation because it will recommend doing things that experts don't recommend doing.

The system is from like 2013 and still going, but I really wish I could rewrite it in a language I can actually train people on in a reasonable amount of time. It took the one junior I have about 6 months to get to the point where he could read the syntax without tearing his hair out. It's not really built to create maintainable structures.

The libraries and stuff are full of opinionated little "gotchas." As an example, the Test::Simple module will throw errors if you use a number to title a test which is infuriating when you're writing a test which tests all the numbers in the space of acceptable or possible inputs.

Perl's syntax is really confusing.

Especially for example how variables have symbols for different types ($ for scalars, % for hashes, @ for arrays). And if you want to for example pass an array to a function you have to send it manually referenced with like method(\@myArray) which then inside the method is contained in a $scalar.

Compared to Python for example where you'd literally just pass the array to the method like method(array).

For many years Perl subroutines didn't even have method signatures so you had to unroll @ on the first line of every sub. I think even today it may still be considered experimental. Jeez!

The reason for the @_ is that it is a simple way to get both pass by value and pass by reference semantics.

The values in @_ are aliased to the values in the subroutine call.

Most of the time, you want pass by value semantics, so you unpack the array and copy the values into function variables. If you want to modify an argument, it's typically passed in as a reference, and you can mess with it that way.

However, there are times when it would be horribly inefficient to make those copies, or when you need to do some magic (generally best avoided in 99.999% of your code), that this makes possible.

Also, since Perl functions are always variadic, it means that it's easy to work with a variable list of arguments in a function. For example, if you are expecting a list of key value pairs for your function, you can simply write:

  my %args = @_
Making signatures default will be a big improvement, but the power of the simple abstraction @_ provides should not be underestimated. It's actually an elegant solution to a complex problem.

Yeah it's pretty archaic. Shortest hand way of doing it is like this:

  sub method {
    my ($self, $a, $b, $c) = @_;
$self being a reference to the current module (ala Javascript's 'this')

$self is only for OOP so not needed in a regular subroutine.

> Compared to Python for example where you'd literally just pass the array to the method like method(array).

How does one tell Python to pass the contents of said array as distinct parameters to the function, instead of as a lone array parameter?

In Perl, that's the difference between foo(@bar) and foo(\@bar) or foo(1, 2, 3) vs foo([1, 2, 3]).

> How does one tell Python to pass the contents of said array as distinct parameters to the function, instead of as a lone array parameter?

With an asterisk: method(*array)

Right, which I sorta kinda get why coming from C - a *something is the thing pointed to by that something.

How is that more understandable than @ vs \@ without knowing the language? My guess is it isn't.

Python is "relatively" consistent about * and being used to expand or contract arrays and dicts, respectively.

   a, *, b = [1,2,3,4]
   def foo(*args):
all do "what you'd expect" from the single concept that "* is sort of pattern-matchy for an array".

But the more important bit is just that you don't have to prefix variables with @ and $. Python is optimized for writing code that acts on variables, while perl is optimized for code that acts on strings. While strings are certainly a common data type, most code isn't modifying strings directly. So optimizing for that case doesn't make a lot of sense.

As someone who learned python first - the idea that `myfn(@xs)` would call `myfn(1,2,3)` is... unnerving. Implicitly splicing in arguments makes me wonder what other kind of syntactic oddities are going over my head in my code.

a = [1]

def f(b):



I can say the same thing about a legacy Java codebase that I had to work with at a big "enterprise" software company a few years ago. The code was so convoluted, with some files over 12k lines long. You can write spaghetti code in any language.

How much and what kind of experience do you think someone should have with a language before beginning to form an opinion?

They mention aws library support as another major concern too.

> There's a few third party libraries in CPAN but nothing as comprehensive as what's available with official libraries for other languages.

That is true. This alone might be a good reason to look elsewhere for new projects.

However, for existing Perl codebases, PAWS is comprehensive and popular library, and is generated from the official botocore: https://github.com/pplu/aws-sdk-perl

> There's a few third party libraries in CPAN but nothing as comprehensive

There's 194,000 modules, which is probably the most of any language:


> Nothing against the language but I don't know why you wouldn't use literally anything else nowadays.

Gee, let me see:

- Perl's Mojolicious web framework is probably the most powerful today.


- Perl has moderate static typing with use strict;

- Perl allows forward references, unlike Javascript or Python.

The question is why would I use anything but Perl?

It is alive and kicking in the bioinformatics community!

I still think Perl is a much better tool for what some bash and python scripts are doing. Maybe Perl7 will remove some stigma and allow for people to use the tool instead of it being instantly dismissed.

Yep, I know of one company still actively using Perl for a large part of its infrastructure. It has its use cases.

One that is definitely still using Perl in a very big way is https://www.ariba.com/

Ariba isn't a household name, but it has deep and widespread connections to thousands of the largest companies in the world.

Are they named after a very large tropical rainforest?


Nope :)

are the use cases all really really fancy regexes?

Last year I had to perform date arithmetic in C shell scripts on a locked down server (no way to install or compile programs and obsolete or missing utilities).

I considered Perl, since it was the only scripting language interpreter, but the good enough (on paper) date handling libraries I found on CPAN turned out to require a far newer Perl 5 version that was available.

I'm afraid that the best-case Perl solution would have been more difficult to write than the roundabout but reliable and easy to understand final solution (Oracle SQL functions executed through the command-line SQL*Plus client).

I'm working through the Llama book, seems like a fun alternative to Python.

Perl is used extensively in the enterprise solutions we deliver for our client.

I write new things in Perl all the time. Deploying highly functional backend services using Mojolicious, a framework which is VERY actively developed.

My full-time job is working a codebase where the back-end is entirely written in perl. Codebase was started around 2014. This was probably a bad decision, the founder was a perl guy.

Perl is not bad but no new codebases should ever be written in it imo. It's to easy to shoot yourself in the foot unless you know perl REALLY well. Moose is ok but a far-cry from any modern OOP system.

Yes, I manage a set of tools and libraries written in perl that are pretty large and service the whole company. That said we're re-writing them all to Python so more people can contribute... Saddens me a little I like Perl, but I'll get over it.

yes, definitely. If you are manipulating text, Perl is great.

A lot of Debian's packaging tools are written in Perl.

Yes. The entire backend to my startup is Perl 5 (Mojolicious) + postgresql (albeit the postgresql part is obviously more important).

I do.

Efficient, cheap and stable. Ported to about everywhere.

What do you mean by efficient and cheap? It doesn't fare well in https://benchmarksgame-team.pages.debian.net/benchmarksgame/... at least.

There’s something fishy about that report. It says it is presenting the fastest programs, but when I click through to “all perl programs”, there are faster (often by 1-2 orders of magnitude) programs / runs:


For instance, the page you linked has “pidigits” at the top, and says node is faster, 2.58s vs 3.61.

2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.

The perl page lists a 1.24 second run for “pidigits 2”.

The reported numbers in the language comparisons don’t seem to be averages.

All the pidigits programs list the same output, so presumably, they’re running with the same ‘N’.

Between the variance and inexplicable stats being applied to the results, I’m not sure what to conclude from these numbers.

> There’s something fishy about that report.

No, there really isn't.

> 2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.

Notice column N — 2,000 6,000 10,000.

That's a command line argument passed to each program, controlling how many digits of pi are generated — the workload.

So, 2.58s for 10,000 digits and 1.04s for 6,000.

(And as it says, there can be a cold caches effect on the first measurements.)

Nodejs is very fast, because it uses an an engine that has had multiple millions of dollars thrown at it to make it fast. Most interpreted languages don't fare well against it.

Perl fares somewhat favorably against Python, Ruby and PHP though. Those are what I would consider equivalent languages to compare against to get a general idea of its speed.

>multiple millions of dollars

I can pretty much assure you the accumulated dollars invested over the years in making JS fast is likely to be closer to multiple billions combined.

You don't hear about it, but Perl has had many millions thrown at it too.

JS is probably closer to billions.

Not just orders of magnitude more money, but more importantly the large number of incredibly talented people working full time on JavaScript, in many different companies and research institutions, collaborating together. JavaScript benefits from an overwhelming network effect and critical mass of tools and developers, that Perl just can't touch, and never will.

Unfortunately it does not change bad parts.

Depends on what you mean by "fare well". Even in those benchmarks, Perl seems to have a lower memory footprint than Node.js in most of the results.

It's also worth noting that three of the examples (pidigits, reverse-complement, fasta) don't seem to do any multiprocessing in Perl whereas they do in Node.js. At least for reverse-complement and fasta, it should be possible to rewrite those to use multithreading (like the Node.js versions do).

> should be possible to rewrite those

Until someone does…

What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python.

Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?

On my 4-core i7 Macbook Pro:

    time ./startup_time.pl  0.016s
    time ./startup_time.py  0.295s
Parsing a 20Mb log file with a regex:

    time ./parse_log.pl  0.683s
    time ./parse_log.py  1.534s
For which metric are you claiming Perl is slower than Python?

Lets see the code? Regex has always been a Perl selling point, and you're just benchmarking the Python Regex library (written in C) against Perl's regex library. That's not a fantastic basis for a comparison.

Perl 5:

    #!/usr/bin/env perl
    use 5.026;

    open my $fh, '<', 'logs1.txt';
    while (<$fh>) {
      say if /\b\w{15}\b/;
    close $fh;
Python 3.8

    #!/usr/bin/env python

    import re

    with open('logs1.txt', 'r') as fh:
        for line in fh:
            if re.search(r'\b\w{15}\b', line): print(line,   end='')
Why isn't it a fair comparison? The startup time is generic and string parsing is a major feature of, say, web development. I didn't say Perl5 numerics match Python's but even there Python relies on external libs.

It doesn't account for anywhere near the whole difference, but in a tight loop like that Python's going to be spending a good chunk of its time re-compiling the regex from the raw string literal every iteration. Hoist the regex definition out of the loop like so and it'll probably run about 30% faster:

  #!/usr/bin/env python3

  import re

  with open('logs1.txt', 'r') as fh:
      regex = re.compile(r'\b\w{15}\b')
      for line in fh:
          if regex.search(line): print(line, end='')
Perl almost certainly does this by default for regex literals, and that's a fair advantage for the "kitchen sink" style of language design versus orthogonal features (regex library, raw strings) that Python uses.

With pre-compiled regex the Python version comes down to 1.483s on my machine which is still considerably slower than Perl. I wrote versions of these using substring `index` instead of a regex and Perl was still the clear winner:

    time ./index.pl  0.258s
    time ./index.py  0.609s
If you factor-in that Python startup time is 0.279s slower than Perl the processing differential comes down to 0.072s.

I'd be curious on your take of my code below, I have python and perl as dead even if you don't print and ignore pythons startup time.

Well, the two ifs you hedge to qualify Python's parity are pretty damning in themselves, no? Let's stop beating about the bush - if you want to perform a common text-processing job like parsing a log file Perl is hands down faster than Python.

Python caches patterns, you almost never need to re.compile unless you’re a library or have a specific use case involving lots of unique patterns.

The issue here is that pythons regex engine has overhead, and with lots of sequential calls with small strings like that the overhead adds up.

If you batch lines together in chunks you’ll see a huge improvement in speed, but the point is that it’s not “Python vs Perl” it’s “pythons regex engine vs Perl’s regex engine”. Which is about a contrived Perl-biased benchmark if ever there was one.

Running a different test the slowest part of the python script is the startup time, otherwise they're identical:

    [admin@localhost ~]$ time ./test.py
    real 0m0.295s
    user 0m0.158s
    sys 0m0.138s

    [admin@localhost ~]$ time ./test.pl
    real 0m0.164s
    user 0m0.158s
    sys 0m0.006s

    #!/usr/bin/env perl
    use 5.16.3;

    open my $fh, '<', 'logs1.txt';
    while (<$fh>) {
    if (/\b\w{15}\b/) {}
    close $fh;

    #!/usr/bin/env python

    import re
    regex = re.compile(r'\b\w{15}\b')

    with open('logs1.txt', 'r') as fh:
     for line in fh:
      if regex.search(line):

The python code should run much faster if you don't print..

Edit: perl is still faster, to be clear

That's like saying they're both as fast if you amputate one of Perl's legs.

I took some similar benchmarks recently: https://code.ivysaur.me/interpreter-binary-perf

Perl5 won the dec2bin benchmark.

The other thing I learned was that PHP's binary/decimal functions are two orders of magnitude slower, despite its core interpreter performance being best-in-class.

On the other hand PHP has a PCRE jit option which manages to beat even Perl's regex implementation.

Yes but you can use that jit also with perl5. https://metacpan.org/pod/re::engine::PCRE2

It has even less backcompat problems than the native regex.

> it's even slower than Python.

It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes.

> Are you saying the language doesn't change much or that it doesn't crash?

Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.

- Efficient: from prototype to deployment, it's a matter of days. The choice of styles let people use paradigms they are familiar with, meaning they do things quickly.

- Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage.

- Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.

The reason that code written 20 years ago still runs fine is that they rolled back 20 years of changes!

This is a pointless attack. The modules available on CPAN usually have a strong emphasis on backwards compatibility.

> Also, perl is incredibly inefficient: it's even slower than Python.

That's debatable for single-threaded workloads (they're typically pretty comparable in my observation), and highly unlikely for multi-threaded workloads (Python has a global interpreter lock whereas Perl does not AFAICT; you can work around that in Python, but it typically involves spawning entirely separate processes, thus introducing IPC overhead that wouldn't be present in a Perl equivalent).

Looking at some comparative benchmarks (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), Perl seems to be faster in a slight majority of cases, and in nearly all cases has a lower memory overhead. Not that benchmarks really matter anyway, given that they're usually a poor indicator of real-world performance, but still.

I believe MoveGB is running a perl backend.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact