Hacker News Reader

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.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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.

More food for thought: https://bitbucket.org/ewanhiggs/csv-game/src/master/README.m...

> 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

    $nested->{foo}{bar}{baz}

If the keys are in variables, it becomes

    $nested->{$x}{$y}{$z}

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

    $nested{$x}{$y}{$z}

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;

or

    ${$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.

https://en.wikipedia.org/wiki/Perl_5_version_history

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.