Bashing Perl is now a meme, but I can never get over what could have been… Python 3000 and Perl 6 had the community all abuzz. CPAN was the amazing Wild West where people were sharing amazing libraries in such a simple way compared to how every other language was still using the likes of Source Forge and possibly even Fresh Meat (GitHub didn’t exist yet).
Don’t fall into the meme trap of hating on Perl. Although it’s only now used in a handful of companies run by OGs and possibly by devops, I urge you to take a look and spend a month using it - really using it. .. because it really is a beautiful language and it really makes Stream-of-Conscious programming the norm
Bashing Perl is a meme precisely because of the mentality of the creators of Perl (who set the culture). This "Forward to Learning Perl" epitomizes the mentality: Imagery of wizards, alchemy, breaking all the stuffy rules that quashed creative thought, etc. He even says "bowing down at the Temple of Orthogonality" like orthogonality a bad thing!
It hearkens back to the days when motor cars were curiosities that required frequent tinkering and had no safety requirements. The sky was the limit, but your car could blow up.
Perl was rightly bashed because it was the poster child of cowboy coding, which flies in the face of good engineering practices: Understandability, predictability, reproducibility, measurability, safety. This allows you to use a product with confidence. I had the misfortune of inheriting some cowboy code, and to this day I call a pox upon the writer. His lack of discipline caused YEARS of misery and maintenance costs; far outweighing any temporary benefit he provided.
Newer programmers might not have lived during the bad old days of cowboy coding, but I did. Nothing was documented. Nothing really worked because there was no edge case support. The mentality was "If it was hard to write, it should be hard to understand" and "If you're not happy with it, feel free to modify the code" (their impenetrable code). Basically, pass-the-buck for your own lack of discipline, and then blame the user.
Personally, I'm glad we've moved on towards becoming a serious engineering discipline, complete with UX being a thing.
People often forget how bad things were in 2000s. A "serious engineering discipline" usually meant Java and "writing a unit test and five lines of docstring for every get/set method". I'd go for wizards and alchemy any day.
Even today many of the "serious engineers" of the time still roam the industry and show up for interviews every now and then, completely unable to write code. Some even capture younger souls into this trap, a sad picture.
I'm glad you found a corner of this industry with "serious engineering." It's still the wild west in web development. Today the creators of frameworks chase engagement metrics rather than wizardry, but the end result is the same.
> Perl was rightly bashed because it was the poster child of cowboy coding, which flies in the face of good engineering practices: Understandability, predictability, reproducibility, measurability, safety.
That’s the meme, but it’s simply not true.
I’m going to use Python as a basis of comparison because that’s the language which, from my perspective at least, seemed to replace Perl.
> understandability
A lot has been said about sigils but ultimately a language is only as familiar as a developers exposure to it. Python appeared easier to understand for the newbie because it favoured words over expressions but now that Python has matured it’s become just as incomprehensible too.
> predictability
I’ll be the first to admin that there are a couple of really massive footguns in Perl which are remnants of its evolution as a shell tool. But there’s other aspects to the language which are really clever. For example the way Perl does type comparison is much more predictable then Python.
On the whole, I think those languages are about equal.
> reproducibility
CPAN was also light years ahead anything also available at the time. And still is in many regards. For example, Python environments is a mess. Perl is one of the most portable languages out there. Want to change the state of the runtime? Just add a line to the top of your source. Simple.
Python and JavaScript are a completely pain in the arse in comparison.
PHP is another example of a language that gets this right. Few people on here (myself included) will have much love for 2010’s PHP but it just goes to show that a lot of the languages “real programmers” praise do actually suck at a lot of the basic principles.
> measurability
Not really sure what this is intended to refer to. Maybe APMs? Either way, a lot of diagnostics like that came into vogue after Perl’s decline so this isn’t really the fault of the language but more just 3rd party tool writers putting their focus elsewhere.
That all said, don’t be fooled into thinking such tooling doesn’t exist for Perl.
> safety
Perl basically invented unit tests amongst the scripting languages. It also has stricter run modes to differentiate between one time scripts and important business code.
Saying Perl lacks safety demonstrates a lack of experience with the language.
——-
I’ve written production Perl, PHP, JavaScript, TypeScript, Python, C++, Go, Bash, Visual Basic and even Pascal. De-mangled other people’s spaghetti code in all of those languages too. Probably a few languages I’ve forgotten about too. Perl is one of those languages people love to hate but is, in my opinion, one of the most misunderstood.
[edit] I should have added a comment about Perl’s backwards compatibility. Few other languages even come close to the longevity of Perl 5. And that commitment extends down throughout Perl’s ecosystem. With JavaScript I’m constantly scared the next npm update will break the project.
>> safety
>
>Perl basically invented unit tests amongst the scripting languages. It also has stricter run modes to differentiate between one time scripts and important business code.
Don't forget Tainted Mode! It's 2024 and I still have never seen it adopted in any other language. It's essentially SELinux-lite for variables :)
IMHO Perl lost to Python because of 3 reasons: 1) Google at the time chose Python and it was the new cool startup everyone wanted to work at, 2) Pandas and Numpy weren't matched in the market (I'd even argue this is still true in 2024), and 3) Perl 6 was way too ambitious and scared people off (even though Perl 5 was never going to go away overnight (and still hasn't))
Back compat is an important thing. A few years ago we took a 250kline from perl 5.8.9 to perl 5.16 in one hit. Out of the entire application under 50 lines of application code needed to be changed (excepting the big bump in cpan module versions). Currently I'm slowly finalising the move from 5.16 to whatever debian stable is currently shipping 5.34 maybe? The biggest pain point is some type safety in the elastic search cpan module. Other than that I've had to slightly refactor some hacky but effective cache invalidation startup code due to a weird `perl -e` bug I found but can't characterise sufficiently precisely to report. The only reason that the perl latest upgrade wasn't done incrementally was because of a super weird unicode bug between perl and the oracle client library which is now out of scope for us.
But I agree perl can have bad management problems because of different people's capabilities, and different people's approach to showing their individuality.
You forgot safe mode and tainting, which while imperfect and has some sharp edges, is a first class construct that when correctly wielded outright prevents classes of attacks like shell or SQL injections or XSS.
Some have been reinventing it in a piggybacked way, and so, partially/poorly (comparatively), e.g Rails's safe/unsafe strings in ActionView.
Some of the arguments about Perl and bad engineering practice are not entirely without merit. Neglecting 'use strict;' or 'use warnings;' in your script typically makes this more apparent. The language itself however does not attempt to constrain developers in the same way modern languages do, instead the burden of responsible engineering is placed on the developer. The result is people that deal with badly engineered Perl typically become sour to the language itself.
I reserved my criticisms of Perl for things like signal handling and it's implementation OOP(to name a few), but overall it's a good language.
I'm bashing Perl because I'm using it daily today. I have the moral right.
People waxing poetic about their time using Perl back in the late 1990s/early 2000s don't have a vote because they clung onto good bits and have long forgotten the ugly.
> it really makes Stream-of-Conscious programming the norm
Are you sure it's a Good Thing? Really sure? What if you have teammates? What if you have a life? What if you need to revise your stream of consciousness after a year? Still sure?
I'm currently writing perl with a team, and I find that so long as you write in a way that looks good, there's no issue with other people reading the code either.
Last year I finished over a decade on very large Perl project, collaborating within a team. When I joined that project it was already over a decade old a most of the code was much like what you are probably imagining. When I left the project, all the parts we had touched were much like any other high quality modern codebase, and we could almost as readily maintain the decade-old parts (that we had worked on) as the week-old parts.
Having worked in many languages over many decades, I've learned that a high quality codebase is built by high quality developers, largely independent of the languages they use. You can build an unmaintainable mess in any language as easily as you can build a high quality codebase in Perl. I would concede that you can more easily build an unmaintainable mess in Perl than in many languages but that's up to you; you can do most things more easily in Perl than in many languages ;)
The advantage of bad perl is that it pretty much is immediately obvious on first sight that it's bad perl. Compare with python, it takes thought and time to identify bad python because it's so syntacticly bland.
With python, write enough of it and you'll be able to spot bad python code just fine. If I don't have Perl muscle memory exercised enough, the same problem telling good and bad Perl code exists too, but it's the other way around — it's all bad until proved otherwise.
I have written Perl solo, and then migrated that Perl into a team setting, and the mindset shift needed is HUGE. I agree with you.
The happy medium is to write your program twice: Write it solo in Perl for rapid thought-to-code, figuring out architectural issues along the way. Then, write it again in Python for scalable collaboration using the revised architecture. This gives you a working solution for the problem FAST and adheres to "Do it, then do it right".
Unfortunately, this doesn't scale to systems. I do hope LLM-driven transmogrification becomes a real thing.
I’ve never done Perl but would writing solo in Perl and then rewriting it again in Perl with a team be an option?
I have an affection for both Forth and Lisp, two languages that have also been called highly productive but write only.
I think a working early version- even if its a spreadsheet- is 10x of a supposedly 80% done version of something else. The latter of which I must now return to unfortunately…
Perl has a weird way of letting you go from thought to code, and disappearing in between, unlike any other language I've ever used. You really can go from idea to functioning system as fast as you type without a lot of pre-planning. It's hard to describe, and the style has fallen out of fashion for more formal, easier to share between humans languages like Java or python, which feel like they introduce an inherent friction in that transition layer as a tradeoff for scalable teams and readability.
I miss it, but understand why it fell out of favor. It's the closest I've ever gotten to singing whalesong with a machine.
I love this subthread; I've tried to explain this for years and I've concluded it's simply impossible to convey to someone who never experienced it. It's sad, and really frustrating, to just hear the same clueless comments and memes repeated. So I'm glad to see there are still people around who know what it was like to work with a truly expressive language.
About 15 years ago I was put on a Java project that ran for a year with half a dozen developers toiling away (along with an outsourced team that management eventually added to write unit tests). I spent half that time fighting with Eclipse and the other half divided between tearing my hair out trying to wade through the AbstractSpringFactoryInterfaceAbstractFrameworkInjectorAbstractionBuilder nightmare, being lectured at by people who learned everything they know about computers from in-flight magazines that this is the way professional software development is done, waiting for the one person who could actually build the application (which he did partly by unzipping the jar files and manually tweaking their contents), and actually coding.
To my complete lack of surprise, the project never achieved a working milestone and was cancelled. What did surprise me was that a coworker who was sympathetic to my grumbling persuaded the CTO who was trying to rescue the project to let me try it my way. On my own (using Perl and PostgreSQL), in a couple of weeks, I had a fully working prototype. We got the green light to proceed and built the company's flagship product on that stack. It was not my brilliant engineering as much as Perl's extraordinary ability to connect mind and machine (coupled of course with my brilliant engineering) that made it possible. I owe Larry Wall for a huge career boost.
LOL are you me? This is exactly what happened to me! Same situation, Java with an external team, project over budget and over time, gets canned and then a few weeks with Perl and it’s done
I so much feel the same. At the time I was writing Perl, each line made so much sense, as if I was speaking my mother tongue. It was clearly an extension of my brain.
Never had that feeling with any other programming language, and it took me years to eventually let Perl go and try to wrap my head around Python.
I wonder how much Larry Wall's background as a linguist has to do with that, which perhaps also explain some of Perl's "messier" features, just like natural language is kind of messy.
I once had a long conversation about this with a linguist and Perl programmer that I randomly met in a pub. However, I was quite drunk and don't really recall too much, and we never saw each other again.
This is quite an interesting phenomenon, and kind of explains why perl is disliked so much.
Computer programming theory has large swathes of inspiration from theoretical linguistics - think lisp. That's nice for theoreticians because it makes things like parsing easier to think about rigorously. Perl on the other hand, to my knowledge is the only significant programming language to be inspired by practical linguistics, and therefore appeals to concepts like context and ambiguity way more than other languages. This means that a lot of computer scientists academics absolutely hate it, and so it was very much neglected in the education space.
The other side effect of this is you still get a good number of talented programmers with backgrounds in the humanities and social sciences who do very well on perl.
As fast as you type you're coding. Even though I've now spent years in other languages compared to Perl, it's still stop-start in every other language.
I've said it many times, but Perl really moulds to your brain rather than the other way around. You bend Perl how YOU want it.
As a medium long time perl guy who's been dragged kicking and screaming to do a bit of python recently I'm going to repeat this here:
Python and perl are actually pretty much exactly the same - analogous to the Judean People's Liberation front versus the People's Liberation front of Judea. However the languages are optimised for a slightly different purpose. Python helps you to think more like the computer does, whereas perl helps the computer to think more like you do.
This can be nice in Python. The `dis` module makes execution pretty transparent, & it's easy enough to know what bytecode a given line will compile to (granted, comprehensions creating closures does make that a bit harder)
CPython's implementation is also straightforward enough that you can look up ceval.c to get a gist of what an opcode is doing
I associate this with what we used to call "one-liner programming": I would write a single line of Perl code (in bash, prefixed with `perl -Mwarnings -MDebug -E'<code here>'`, convince myself the code did what we needed, and then share it around as a paste in irc / chat / whatever. It was amazing what you could achieve with the right modules, and Perl's flexibility allowed your mind to roam freely.
Incidentally, the fact that you cannot write this type of one-liner in any meaningful way with Python is one reason I do dislike that language.
About Python, are there practical situations outside IRC where you can't include a newline in there? This ..
python -c '
import re, sys
for line in sys.stdin: print(line.lower().count("foo"))
'
works in shell interactively (both bash and zsh support multiline history entries well), or in shell scripts, and also in slack/mattermost/matrix/email.
It's sad that Perl is dying a slow death. Between Python and Perl, both styles of coding are possible.
While Python is my preferred language for most tasks, I still use perl as an ad hoc stream processor with `perl -pe` and nothing really beats it at the task. Anything more than 10 lines and I find python easier to deal with (or at least it's my comfort zone).
Don’t fall into the meme trap of hating on Perl. Although it’s only now used in a handful of companies run by OGs and possibly by devops, I urge you to take a look and spend a month using it - really using it. .. because it really is a beautiful language and it really makes Stream-of-Conscious programming the norm