Later I got another role solely because they couldn't find Perl programmers and I wasn't half bad at it. But this was an actual application written by a bunch of people who wanted to write clever code and it was like handing over the keys to a missile depot to a bunch of arsonists. Many thousands LoC. By the end of it, I was told that we need to move to using Java and I could barely contain my relief.
For one-off scripts, still nothing flows like Perl. It is the most interesting language I have coded in, bar none.
[0] correction: Learning Perl, the llama book (thanks @ninkendo)
Even PHPs prominence (and ease of use) can be traced back to the parts it borrows from Perl; since the web is just manipulating text after all.
I went on a similar journey to you. Started with C, moved to bash, then to perl to replace bash scripts, and you're right that it feels like a super power.
But the most interesting language I've ever coded in was probably Ruby, because it changed the way I look at languages. In Ruby, everything is an object and everything is mutable - this makes the dynamic metascripting possibilities simply absurd.
I don't advocate for these languages anymore, as Perl is easy to become "write once, read never", in a way that's much worse than bash- but I can't help but feel like we have definitely lost a killer language for text processing. Seemingly nobody writes perl anymore.
At the beginning of the transition, I had to look up Python idioms for what I knew in my fingers in Perl. Over the last couple of years, when it made sense for a one-off in Perl, I would omit semicolons, omit braces, count on significant indentation. Can I still write Perl? Yes, and not badly, but not as fluently as before about 2018.
However I would say an awful lot of the professionals I was around already thought Perl had a bad smell even in the 1990s. It was definitely looked down up on in academia by then. Maybe not in an IT department or Math department but in the CS department it was. It was used by IT guys, and QA guys, and somebody gluing some tools together. An awful lot of people thought it was unacceptable for it to be in serious production code or anything that had to be long term maintainable or be worked on by a team of people larger than size = 1. Your perception of it definitely came from where you were at the time and how you encountered it. If you were on a team producing software for sale that involved a bunch of people and you had version control and QA and everything Perl was already not your thing.
I had a similar path to Perl as a lot of people here. I was making games and into C when I learned about Linux from a friend. From there I heard about Perl and started using it to automate making my websites… those halcyon days before someone started calling them “web logs,” and later, “blogs,” etc.
Text munching and slinging around files was much easier in Perl than it was in C and I became a big fan.
The community was awesome. And the books were great.
I feel like Perl embodied that hipster-Socialist Bazaar style moment in programming/tech.
I am unapologetic about my love for Perl. Something I learned in that role was how much more important transparency is than cleverness. Perl has a way of enticing you to do very "clever" things -- there's more than one way to do it, as the saying goes, and some of those ways are VERY NEAT! Unfortunately, a large number of the "neat" approaches also approach brainfuck-levels of oddness.
Most languages don't have that rabbithole, or at least the hole isn't that deep. But with perl, man, you can do some ridiculous and awesome things that even YOU won't immediately understand six months from now.
About the 2nd or 3rd time you get bit by that particular snake, though, you start to build your code much more conservatively, and with much more of a long-term intentionality built in. The code I wrote in that job after those lessons took root is still probably the best work I've done as a programmer -- neat, clean, consistent, and above-all understandable to whomever ended up needing to work on it later. And I put a lot of that down to just how easy it is to write HORRIBLE Perl.
All of my code was garbage of course, but it was an incredible amount of fun, a very valuable learning experience.
I miss those days, but that probably has less to do than the programming language and more to do with the carefree days. :-)
I'm not clear which way the author thinks this works but having started coding in the 90s I feel that with Perl you had to try to understand the quirks of language and the language didn't try to reach out to programmers to make things easy. Whereas other coding languages aim to be intuitive, with clearer syntax, more logical naming and frameworks to obscure complexity, which to my mind is a better way to bridge the gap between us and "the machines".
I loved Basic, then VisualBasic, then C, and then Perl... and after Perl, I've never really found it challenging to learn a new language. After almost a year of working on some cgi script (gossamer threads, I think?) I had this alarming realization that I did not understand the context of a block of code I seemed to spend most of my time editing. It was a multi-page regular expression. I was (and am still) pretty naive to how the language is implemented or even parsed, and I find it most interesting how we can write in languages with the barest understanding of their underlying details. I'm at that point with a lisp, occasionally catching glimpses below the surface, but now with decades of diving deep and in other languages. Sometimes I think it might be fun to return to Perl, but when I read modern Perl, it seems to bear such little resemblance to the code of 25 years ago.
The writing of the O’Reilly Perl books had this micheviousness to them that is also reflected in the language itself. It espoused an apparent simplicity in doing simple things, like reading from a file or taking user input, that languages like C++ had much more ceremony around. Likewise, when I used it to create a compliance test generator for a company I worked for, it took me a few days to write something that would take their source questions and answers and generate an entire website that folks could use to give exams and certifications for regulatory compliance.
To this day, I have not found any other language that makes text processing as easy as it was in Perl, and given how much of our work is processing text and strings, I’m still a little surprised other languages haven’t made it as easy as Perl did.
I gave it up in 2020, perceiving that python had won. It was a sad day - working in python feels like typing while missing three fingers. I go to reach for an idiom and not only is it not there, I'm told the phantom limb syndrome is for everyone's good, including mine.
I've never found the code of skilled perl programmers difficult to read. I think bad programmers will always write code that is difficult to work with, even in languages that are supposed to prevent it. The most miserable time I ever had understanding someone else's code came at the hands of a brilliant, overly clever, somewhat inexperienced python hacker. I will admit, though, that this feat of confusion required a prodigy, whereas perl makes it quite easy to shoot everyone in a thirty yard radius in the foot. Just the same, I've always thought the messiness of perl was a myth, a result of misuse, abuse, and inexperience. Well written perl conveys much at a glance where in visually cleaner languages, all shapes have the same outline.
But it's also true that by the time I gave it up, I was already looking for a replacement. The language is bold and beautiful and opinionated, and in the fullness of time, some of those opinions proved to be wrong. The world moved forward and perl didn't, and I found myself wanting to do things with objects, and types, and tooling, and functions, and exceptions, that it just didn't do, or didn't do well. Some languages, like PHP and javascript, grew beyond their humble beginnings and bolted on the rigorous and increasingly mandatory machinery of the modern world. Perl didn't.
So my leaving had two big factors: the language didn't grow up, and people didn't want to read my code.
I'm still looking for a replacement. The serious contenders seem to be Go and Ruby, both of which I really like a lot. I dabble in Haskell and Lisp looking for pieces of what I've lost. I have negotiated an uneasy ceasefire with python and javascript out of professional obligation. We can work together, though admittedly neither one of us is entirely happy about it.
Perl was a beautiful thing, a thing I appreciated like art and poetry. I'm glad to have been there for the years in which it flourished. But I also think the world has passed it by. Even looking past hacked in features, it had a more fundamental problem. The tug of war between standardization and expression is like the one between society and the individual. Neither side should ever really win, but perl favored expression more than we now think is wise. We didn't know it then. And the feeling was glorious. But in the decades since, we all - myself included - have decided the balance between those things is ... well we don't know exactly where it is, but we do know it involves less individual freedom than that. The language made a lot of gambles that turned out wrong, but that's the big one.
I think lisp fell prey to that, too, by the way. So formless and expressive that by the time you got done writing your software, you'd essentially invented a language specific to it. Great, in the narrow scope of your project, language and domain fitting hand in glove. Not awesome if you need to hire help. Ads for people who speak Emacs Lisp or Autocad Lisp are telling. You can invent the most beautiful language in the world, but the fact that only three people speak it is surely a strong point against it.
Perl is and was a beautiful thing. I miss it. I seek out its children when I can. I write jokes and references and eulogies where I can, tucking little utility functions stolen from perl into languages where they don't belong, places that never touched that unix heritage. Perl is humble enough to give you the space to do things your way, rather than its way, giving you permission to break all the rules and requesting that you use the freedom with wisdon and goodness and politeness. That sort of bold faith and generosity sparks in me a fierce love. I haven't found it anywhere else. I doubt I will, because as wonderful as it is, it's since been considered unwise. Programming is a social endeavor, and while a specialist language like GLSL can thrive in a little niche, a glue language spoken by only a few people isn't a glue language at all - it's another arcane system that needs to be glued. No, python won. Perhaps it even deserved to.
So for me, perl is dead... but also long live perl.
I worked at a VFX place that was held together by loads of perl, written over a good 15 years. Some of it was clever, but most of it was plain readable scripts.
The key to keeping it readable was decent code reviews and someone ripping the piss out of you for making unreadable soup.
Its all python nowadays, I do miss CPAN, but I don't miss perls halfarsed function args.
However for the longest time, the documentation for perl was >> than python. At the time python doc were written almost exclusively for people who knew how to python. Perl docs assumed you were in a hurry and needed an answer now, and if you were still reading by the end assumed you either cared or were lost and needed more info.
With the rise of datascience, python has lost its "oh you should be able to just guess, look how _logical_ the syntax is" to "do it like this."
I certainly don't believe it. Everyone I talked to at the time who worked with Perl knew it would not go away: humanity had chained too much of the infrastructure of the internet to it. Someone would have to maintain it for many years to come, even if Larry's new experiment became a wild success. (Already back then people seemed skeptical of the experiment and hung back with Perl 5 waiting to see what came out of it before paying too much attention.)
I still struggle to understand why Perl went out of favour[1] but I think what another commenter wrote here might come close: for Unixy folks who know shell, C, awk, sed, Vim, etc. Perl is a natural extension. Then came a generation of programmers brought up on ... I don't know, Visual Basic and Java? and these were more attracted to something like Python, which then became popular enough to become the next generation's first language.
[1]: As someone who knows me might understand: https://entropicthoughts.com/why-perl
Anyhow, toward the end of my time there, I had to interview candidates. Because I came to believe that the above is how one had to work with Perl, I took to asking the ones who said they knew Perl, "Can the reverse builtin reverse a list?" (I won't spoil the answer for you.) Most would answer with "Yes" or "No"; 75% of them were mistaken. Either way I'd ask them "Suppose you weren't confident about that answer. How would you determine the truth?" IIRC, 90% of them said "I'd write this one-liner..." and (I swear) 100% of the one liners would give any reasonable person an impression of an answer that turns out to be incorrect. The ones that said "I'd check the perldoc" were the only ones I'd approve for subsequent interviews.
(re nobody codes in Perl: I still do professionally, and I'll probably never understand why it draws so much hate)
The two languages I enjoy the most are Perl and Lisp - and the majority of my non-work related coding is split between those two.
There's no humility in the list.
Perl
- Was an easy jump from bash to Perl
- Perl never felt like it "got in the way"
- was WAY too easy to write "write only code"
- that being said, I learned Java first and most people found MY Perl code to be very legible
- regexes as first class citizen were amazing
- backwards compatible is GREAT for older systems still running Perl (looking at you banks and some hedge funds)
Python
- Forced indentation made it MUCH easier to read other people's code
- everything is an object from day one was much better than "bless" in Perl
- no standard way of setting up an environment for MANY years hurt
- sklearn and being taught in universities were real game changers
The enormous reason that I see is the insistence, from Larry Wall and others, on a bottom-up "community" transition from Perl 5 to Perl 6. The design process for Perl 6 was announced at a Perl conference in 2000 [1]; 15 years later, almost every Perl user was still using Perl 5. The inability of the Perl community to push forward collectively in a timely way should be taken by every other language community as a cautionary tale.
Tim O'Reilly made a secondary point that may also be important. For a long time, Perl books were O'Reilly's biggest sellers. But the authors of those titles didn't act on his suggestion that they write a "Perl for the Web" book (really a Perl-for-CGI book). Books like that eventually came, but the refusal of leading authors to write such a book may have made it easier for PHP to get a foothold.
[1] https://en.wikipedia.org/wiki/Raku_(programming_language)#Hi...
Only because people kept writing horrible code and using Perl as an excuse. Perl is like C, your code is as readable and maintainable as you choose to make it. It's like that old saying about blaming your tools. Just stop writing crap code.
There should be one-- and preferably only one --obvious way to do it.
But not that many. And that's why Perl is still Perl. Popularity brings change which means old code stops working.
Perl code from the year 2000 still works in a perl interpreter+libs today. And perl code written today still works on perl interpreter+libs from the year 2000. That incredible stability and reliability is what makes it great. Write something then use it 20 years later and everything just works anywhere you try to run it.
That's why I chose Perl.
Ever tried to deal with 20-year-old duct tape?
It was the first language I wrote professionally and I always thought it was a lot of fun, but if I want to be humbled these days I reach for Haskell (like a lot of the Perl community it sounds like...).
EDIT: okay I read the article, thanks to welpo for the archive link. Yeah this is kind of a nostalgic piece so I think my original comment is still relevant. I do like Perl still, I will always have a spot in my heart for it. I appreciate especially how seriously Larry Wall tried to think about approaching things vis-a-vis linguistics even if I don't necessarily think that's the best approach for a language used by an engineering team these days.
I hope it sticks around in any case. It is truly unique.
I guess it became popular because it existed and there was nothing better (nobody will write in awk if not pressed to).
We don't need badly designed tools to stay humble. There is enough cognitive load from all the bad programmers (and now LLMs spewing slop), no need to add another nonsense.
I admit though that writing perl makes you feel "clever" - "huh that's a funny shortcut I didn't know! Writing $\<>^^ will give me name of last used file on blue moon on thursday!" but... uh.
But the article or at least the title would be much more suitable if perl is replaced by "CUDA". You can't be working with that and be arrogant, because even self centric people would suffer enough pain not to change. And if perl makes you feel it is made by humans. Then "CUDA" sure would feel like something that came straight from the hell.
Note: I understand that the article is more about talking about perl and remind people that it existed and was famous language one day. But I couldn't resist the temptation of the title.
Rust
There was something so wonderfully down-to-earth and humane about those O'Reilly books. But actually most IT books had something casually playful and creative about them. A quality you rarely find these days.
I was a mediocre developer and student in my CS program and actually considered getting out at a few points. I really loved systems and building solutions though, and I ended up becoming a DBA.
For some reason my mental model resonated with Perl. I was able to use it almost like a writing process, getting my “outline” laid out in Perl and refactoring supplementing with more efficient C code or third party stuff later.
It was cool, i started fixing data integration issues and automating processes around the databases. Eventually a colleague and I basically built an application that made our DR testing failover and failback processes a two-click event. I left that company long ago and I know a bunch of our stuff ran almost 20 years before the system was migrated to AWS.
IT is more industrial and efficient these days. That’s not a bad thing, but I had alot of fun being the kid showing the old people what Linux was and gluing all of these systems to orchestrate them. Unfortunately Perl is an artifact of that era.
Tcl was by far the easiest to use, while Perl sat on the other end of the spectrum for both skill needed to write it as well as to just be able to read it.
As the mantra goes, "Power, but at what cost?!?"
That's true, but obscures what IMHO is a deeper truth: thinking in perl naturally leads to thinking in "streams of text", which is a kind of general composability that's been largely forgotten in the Unix world.
These days every project has it's own giant list of dependencies, it's own conventions about code structure, it's own list of para-toolchain utilities like linters and formatters. Often it even has it's own set of vscode extensions you pretty much have to use.
Nothing is just a tool anymore.
I write Perl and I hate this mindset a lot. A LOT. Some people get excited and feel like they are megawizards of the White Council because they can line up all their sigils and make them dance, and thus feel just that little bit superior. There's nothing superior about maintaining a program where to change it, you need to solve puzzles three, make the change, and wrap it in another puzzle for the next guy.
I know that feeling of being a wizard, and I used to have that smug expression on my face, too. But now I'm over 40, and I'm jumping from one place to another in a magical codebase to debug it, and I can't help but feel like if it was just that little bit less magical, I could have fixed it and be done with it quite a while ago already.
I'd say Perl is the fruit of the marriage between shell and Lisp.
Could not stop talking about CUDA, and why everything else was terrible, and how nobody listened to him, and how that was because they couldn't handle the truth, and how he could solve everyone's problems if they would only let him, on and on. He didn't last that long at my company.
Maybe he was taking his CUDA pain and pushing it onto other people.
So often, people want their systems to be scriptable… they were once, and then people destroyed the things that made all that possible.
All that old code still works, though.
> perlcritic is a Perl source code analyzer. It is the executable front-end to the Perl::Critic engine, which attempts to identify awkward, hard to read, error-prone, or unconventional constructs in your code. Most of the rules are based on Damian Conway's book Perl Best Practices. However, perlcritic is not limited to enforcing PBP, and it will even support rules that contradict Conway. All rules can easily be configured or disabled to your liking.
https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic
It helped me a lot. I think every Perl developers should use it, might help to avoid headache later on. Be careful with severity level "brutal" and "cruel" and "harsh", however. I think "gentle" works in many cases. That said, I used "brutal" and I only fixed the legitimate issues. "brutal" helped me write a proper POD, for one, as "gentle" does not complain about that.
At some point when the LLM fails, you'll need a real programmer to figure it out.
But IMO, LLMs are code generation, and code generation always fails at some point when the pile of generated code topples, no matter the language.
The amount of bad enterprise LLM code that will be cranked out in the next few years is going to be fascinating to watch.
But what about people who didn't work with Perl, or only used it as a side thing? I know I personally put off deepening my superficial knowledge of Perl 5 in the early 2000's, in anticipation of "Perl 6". The Osbourne Effect is a real thing.
EDIT Or, companies starting major new projects, and deciding what language to write it in? It's one thing to say, "Perl 5 will be supported for a long time, we don't need to migrate our existing projects off it." It's another thing to say, "We want to start a new project; should we start it in Perl 5, which will become 'legacy' in a year or two when Perl 6 comes out? Or should we write it in Python?"
I wouldn't say I was brought up on Visual Basic though. It was not a language that taught structured programming at all.
I believe this, too.
I do not use Python. I would rather use Perl (!), Tcl, Lua (!), Go (!), C (!), OCaml, Erlang / Elixir, and Factor / Forth, and very rarely Common Lisp (SBCL). I do not like Java / Kotlin and related languages. That said, I started with shell scripts, and then probably a little bit of Perl and Tcl, and very often C because back when I was a kid I was modding ioquake3 forks that are written in C.
When I was a kid and just started working I would still often code with whatever I came up with initially, but then you go back to that 3 months later and you have to throw the whole thing out because it's impossible to maintain or add to.
On the other hand there are sometimes additions to a language that's just so useful that you have to expand your vocabulary, for example in C# that's happened a few times. One of the notable additions there was LINQ that made manipulating data so much easier. It can become dangerous though, the same as for example with a complicated DB stored procedure.
Unfortunately it doesn’t do automatic tail call elimination but that’s a tooling limitation more than a language limitation.
>Partway through, Jon Orwant comes in, and stands there for a few minutes listening, and then he very calmly walks over to the coffee service table in the corner, and there were about 20 of us in the room, and he picks up a coffee mug and throws it against the other wall and he keeps throwing coffee mugs against the other wall, and he says "we are fucked unless we can come up with something that will excite the community, because everyone's getting bored and going off and doing other things".
https://en.wikibooks.org/wiki/Raku_Programming/Perl_History#...
Intermission: The Jon Orwant Mug-Throwing Incident in 2000
By 2000, it was evident that Perl needed an infusion of life:
"The [P5P / Perl Conference] meeting was originally a gathering of Chip Salzenberg, Jarkko Hietaniemi, Elaine Ashton, Tim Bunce, Sarathy, Nick Ing-Simmons, Larry Wall, Nat Torkington, brian d foy and Adam Turoff, brougt together to draft a constitution of sorts since the community seemed to be fragmenting. Jon showed up to the meeting late and found us talking about the community and started throwing things to express his discontent with how perl itself was stagnating, possibly even dying, and that we should be talking about reviving Perl. The cup incident was planned theatre from what I was told later. So, it was already a fait accompli but the tantrum was it's outing." [1]
https://www.nntp.perl.org/group/perl.packrats/2002/07/msg3.h...
Andrew.Savige@ir.com [Andrew.Savige@ir.com] quoth:
*>I am interested to learn more about this incident.
*>What this really the catalyst for the current Perl 6 development?
*>How many mugs were broken?
*>Were they coffee mugs or coffee cups?
*>What colour were they?
*>Did anyone keep some broken cups for later display in musuem?
*>Did anyone photograph the incident or broken cups?
https://web.archive.org/web/20110716115800/http://www.spider... is about as close to a photo of this as you'll find :)
e.
Raku being in such an indeterminate state for so long was an eternity for it to lose mindshare to Ruby.
big tech sort of replaced wall street as main career choice for some people and naturally attracted "wallstreet bros" type into the tech, who are now known as "tech bros"
I stopped using it circa 2000 for no real reason other than Python was easier for teams to adopt and common modules became well-maintained enough where CPAN was no longer a competitive advantage. It also helped that Guido lived and worked a few minutes north in Reston, VA back then.
That said, I still "think" in Perl regex to this very day. ;)
Learning Perl (the llama book) was my first programming book, and it taught me programming in general, not just Perl, and I still think it was an amazing book. Very approachable, helpful to beginners, I read it cover to cover. There’s also “learning Perl objects references and modules”, which is a bit of a sequel to Learning Perl. Those two books helped me land my first gig as a Perl programmer, and started my whole career.
In the past when I used perl, I did the same thing.
But I came to learn one thing about perl - its good point is its bad point.
When I used it, perl was the highest level language I ever used. It was expressive, meaning I could take an idea in my head, and implement it in perl with the least friction of any language.
When I worked with other people's perl, I found they were mindful and cared about what they were doing.
But the way they thought was sometimes almost alien to me, so the expression of their thinking was a completely different type of perl, and it was lots less readable to me. And frequently the philosophy of what they wrote was backwards or inside out from what I would do.
Now I have replaced perl with python day to day and although implementation of code seems a few steps removed from my thinking, it seems that other people's code is more easily read and understood. (this is just my opinion)
You mean you don't like writing things like...
sub foo {
my ($a, $b, $c) = shift;
?1. Enterprise Development
Java et Al led to a generation of developers working further from the kernel and the shell. Professionalization of the field led to increased specialization, and most developers had less to do with deployment and management of running software.
Tools also got much better, requiring less glue and shifting the glue layer to configs or platform specific languages.
Later on, DevOps came for the SysAdmins, and there's just much less space for Perl in the cloud.
2. The rise of Python
I would put this down mostly to universities. Perl is very expressive by design, in Python there's supposedly only "one right way to do it". Imagine you're a TA grading a hundred code submissions; in Python, everyone probably die it in one of three ways, in Perl the possibilities are endless. Perl is a language for writing, not reading.
3. Cybersecurity became a thing
Again, this goes back to readability and testability. Requirements for security started becoming a thing, and Perl was not designed with that in mind.
4. The Web was lost to Rails, PHP, then SPAs
I'm less clear on the why of that, but Perl just wasn't able to compete against newer web technologies.
And they were wrong. Perl went away a long time ago.
It's not without reasons that the UNIX guys did Plan 9 afterwards, let me tell you.
Suppose the Table family type their son Bobby's name into a form. The Perl program now has a "tainted" string in memory - "Robert'; DROP TABLE Students --".
The Perl code passes this string through a regex that checks the name is valid. Names can include apostrophes (Miles O'Brien) and hyphens (Jean-Luc Picard) along with spaces and normal ASCII letters, so the regex passes and the string is now untainted.
Honestly, I think all CS/EE programs should require an OWASP course and that coding should require regular continuing education that includes defensive coding practices for correctness, defined behavior, and security.
But I couldn't understand anything of it.
Hence I became an economist within cyber security instead.
The older languages may be artifacts of our era of code, but I'm excited to see what the next wave of documented prompting vibe coding will bring.
I might finally understand what the heck my students' code is doing HA!
And what's interesting is that it's complicated in a lot of similar ways, in terms of thought space, as perl was. Perl was great because you could be clever, where you really couldn't in more pedestrian languages.
I find (and I'm not sure this is a good thing) that my python output these days feels very clever sometimes...
I don't think I ever thought about it but I think I have implicitly taken this to heart since I last was using Perl seriously. Almost every engineering org I've worked for in the last decade has had Ruby as a part of its stack for e.g. scripting or lambdas and it's what I reach for when I need to script something. And I've done Rails work in a few orgs too, which has few parallels in its niche even without considering Perl.
Although I suspect for most people Python is where they land if we're just talking about scripting or hacking something together...or anything (I hate it but it is what it is lol).
Yeah good point, if there's one thing from Perl that will live far longer than the language itself it's PCREs. I can't thank my experience with the language enough for my facility in crafting regexps.
When I still used Perl (10y ago) Ruby was notably slower on many tasks. Ruby probably the slowest among popular script languages.
I'm not sorry to have stopped working in Perl, broken cups or no; thinking back on my time with it puts me forcibly in mind of what I believe to have been Wirth's comments on the hazards of early exposure to BASIC, and "The Rails' Progress" in the late 2000s and after I would nominate as the corresponding farce.
People who have actually used sh/awk/sed know quite well how terrible they are.
I remember Perl evangelists bragging about "associative arrays" as if they were God's Gift to Humanity that no other language could touch, only because they knew no other language. Not even realizing how much more limited Perl's associative arrays were because of its complete lack of reasonable reference semantics.
I'm not sure I interpret you correctly but the increased prevalence of good package managers on Linux surely contributed to increased usage of languages not installed by default, unlike Perl.
I think "parse don't validate" doesn't help in this example, but naively the regex would not check whether a name is valid but "extract all parts of the string that are provenly safe".
Which is not reasonable for SQL statements, so someone invented prepared statements.
I think the idea is that the Regex parsing forces the programmer to think about what they're doing with the string and what the requirements for the non-tainted variable are.
For example, a file name string would not allow unescaped directory separators, dots, line breaks, null bytes (I probably got most details wrong here...) and the regex could remove these or extract the substring until the first forbidden character.
Sure, this cannot prevent mistakes.
But the idea, I think, is not to have a variable "safeUserName", instead a "safeDbStatement" one.
ps: ah well, that was fast https://en.wikipedia.org/wiki/Taint_checking#History :) (1989)
In PHP, you can construct objects directly from $_GET/POST (and erase everything from these vars to make sure they are not used directly), then lean on data types to make sure that these values are not used in a wrong place.
> The inability of the Perl community to push forward collectively in a timely way should be taken by every other language community as a cautionary tale.
I think this is a good point that I hadn't considered before.
I think Perl stopped being able to attract new users. There is always going to be users leaving. If they aren't replaced, you will slowly shrink.
I think the point you raised is part of why they couldn't attract new users. I also think people asked themselves "why chose perl now, if I know I need to re-write when Perl6 comes?" and decided Perl5 was bad choice. I also think the fact Perl had this reputation for being ugly, difficult, and "write only line noise" kept people from even considering it, even if that reputation didn't match production codebases.
Both approaches have their merits. Like with maven, where I once saw a question on a forum that was like "how do I do X?" and the reply was basically "You can't, don't try to do so, as that's wrong".
Yes, I hate to write
sub foo($$$) {
my ($a, $b, $c) = @_;
}
It just grinds my gears that _I_ need to check to see if the caller has given me all the required bits. That seems like something the language should do.
I understand that it does give you a lot of flexibility, but Hnnnnnnnnn
(from what I recall object oriented perl doesn't give you this flexibility, but I'm not sure, as I never really did it. )
1. shift only shifts off the first element.
2. (if classify this as a bug) using $a and $b are frowned upon because they're the default variables when using sort.
Serious question: is that solved? I still see a forest of options, some of which depend on each other, and at last count my laptop has 38 python binaries. What's the standard way?
Not saying your anecdote is inaccurate, but my perception around that time was that "Learn PHP in 24 Hours" was a lot hotter than O'Reilly's Perl books - so it may have just been luck, marketing, a flashier title, or even just that PHP was better suited for what people wanted to learn and do.
It succeeded because it was a beautiful and horrible combination of those tools/languages. If you know those things, Perl is really easy to bang together and generate a webpage or use to automate administrative task.
Given Larry Wall's education, perhaps we shouldn't be surprised that Perl underwent a linguistic evolution from pidgin[1] to creole[2].
I came to Perl a bit late, not being a super adept user of Unix and only having written C in school. I'd put myself in the category of Perl developer that was part of the second "creole language" phase of Perl's development. I learned a ton of Unix and got better at C by learning Perl.
While Perl's mixed nature made it successful, when the world of web development expanded to include more people without the necessary background to benefit from the admixture, it went from asset to hinderance. All that syntax went from instantly familiar to bizarre. A perfect example of this are the file test operators[3].
The Perl 6 struggles definitely added to the difficulties posed by the changing nature of the web dev community. They created enough uncertainty that tons of people asked themselves "Why should I learn Perl 5 when Perl 6 is just around the corner?". That slowed adoption from in the 2001-2010 timeframe while Python and Ruby grew rapidly.
Rakulang is kind of magical. Writing it is like using a language given to us by aliens. I wish it was getting more uptake because it is fun and truly mind expanding to write.
In the end, I think the shifting nature of the community was a larger factor in the decline of Perl than the slow Perl 6 rollout and failure of messaging around it.
I still love writing Perl 5 and I wish I got to do more of it.
[1] https://en.wikipedia.org/wiki/Pidgin [2] https://en.wikipedia.org/wiki/Creole_language [3] https://perldoc.perl.org/functions/-X
I will say coming from years of perl that python had a refreshing amount of "batteries included" via the standard library.
It was only rarely that my code needed "outside help", usually something like requests or numpy.
I suspect this is because I used python in the same environment as perl, automating unixy kinds of things.
I suspect "setting up an environment" is because python has been so successful, becoming an enormously broad general language.
There is a new package manager every year. Language features are introduced every major release.
Most languages have a decent enough framework or two that the differences between using them for different use cases may be closer than many folks realize vs whatever we hear about as the new hotness through the grapevine.
A mess can be made in a lot of languages, and a long time ago, it was even easier, except some of that code worked and it didn't get touched for a long time.
There is still a lot of perl around but I'd be a little surprised if any new projects would use it at least where it doesn't already have a big presence.
1. The rise of other web languages that did what Perl was good at but better.
Perl was probably a fine language for sysadmins doing some text munging. Then it became one of the first languages of the web thanks to Apache and mod_perl, but it was arguably never great at that. Once PHP, Python, Ruby, and (eventually) JavaScript showed up, Perl's significant deficiencies for large maintainable codebases made it very hard to compete.
In many cases, a new, better language can't outcompete an old entrenched one. The old language has an ecosystem and users really don't like rewriting programs, so that gives it a significant competitive advantage.
But during the early rise of the web, there was so much new code being written that that advantage evoporated. During the dot com boom, there were thousands of startups and millions of lines of brand new code being written. In that rare greenfield environment, newer languages had a more even playing field.
2. Perl 6 leaving its users behind.
As a language maintainer, I feel in my bones how intense the desire is to break with the past and Do Things Right This Time. And I'm maintaining a language (Dart) that is relatively new and wart-free compared to Perl. So I can't entirely blame Wall for treating Perl 6 as a blank check to try out every new idea under the sun.
But the problem is that the more changes you make to the language, the farther you pull away from your users and their programs. If they can't stay with you, you both die. They lose an active maintainer for the core tools they rely on. And you lose all of their labor building and maintaining the ecosystem of packages everyone relies on.
A racecar might go a lot faster if it jettisons all the weight of its fuel tank, but it's not going to faster for long.
I think the Perl 6 / Raku folks go so excited to make a new language that they forgot to bring their users with them. They ran ahead and left them behind.
3. A wildly dynamic language.
If you want to evolve a language and keep the ecosystem with you while you do it, then all of that code needs to be constantly migrated to the new language's syntax and semantics. Hand-migrating is nightmarishly costly. Look at Python 3.
It's much more tractable if you can do most of that migration automatically using tools. In order to do that, the tools need to be able to reason in detail about the semantics of a program just using static analysis. You can't rely on dynamic analysis (i.e. running the code and seeing what it does) because it's just not thorough enough to be safe to rely on for large-scale changes to source code.
Obviously, static types help a lot there. Perl 5 not only doesn't have those, but you can't even parse a Perl program without running Perl code. It is a fiendishly hard language to statically analyze and understand the semantics of.
So even if the Perl 6 folks wanted to bring the Perl 5 ecosystem with them, doing so would have been extremely challenging.
I would say this is a case study in a programming language tragedy, but I honestly don't even know if it's a bad thing. It may be that programming languages should have a life cycle that ends in them eventually being replaced entirely by different languages. Perhaps Perl's time had simply come.
I am grateful for all of the innovative work folks have done on Perl 6 and Raku. It's a cornucopia of interesting programming language ideas that other languages will be nibbling on for decades.
Perl won't stop you from doing insane things, true, but you can write garbage unmaintainable code in any language.
I agree with the intention of the quote, sadly it didn't work out like that.
In fact it's a pretty big feature in the latest video (a drum) where he calls it
> a horrible material, because when it's fresh and young the adhesive's really goey and hard to get off, and then, when it gets old, the adhesive dries and it's... hard to get off
and he has to deal with both on the same drum.
I've carried one pretty much every day of my life (so, starting at about 14 or 15; I'm 55). A tool that can trim a thread, open a box, open a bottle of wine, tighten a couple kinds of screws, punch a hole, and pluck a splinter while still being small enough for EDC is a big win in my book.
Is it the BEST screwdriver? Certainly not. Is it the BEST corkscrew? My WineRabbit is losing no sleep on that question. Are there better tweezers in the house? Absolutely. But the SAK is in my pocket, and is good enough for most tasks.
Yesterday the knob on my office door was loose. It's the kind of household issue that often drags on, bc you notice it when you're doing something else, kinda make a plan to get a screwdriver and fix it, but then forget about it until the next time you touch the doorknob.
But because I had my Swiss Army in my pocket, I took 10 seconds to tighten the screw right then. Problem solved.
As they say in photography, the best camera is the one you have with you.
- a lot of things I did in perl ended up using regular expressions
- in comparison python use of regular expressions is not first-class so many problems would use string functions instead. (although r'<expr>' was less ambiguous wrt quoting rules)
- in perl path manipulation would use regular expressions
- in python I embraced os.path
- I would use oo in python, but rarely in perl
- argparse
sub foo ($x, $y, $x) { ...}
It's just syntactic sugar, so you still can't pass in multiple lists, and the list must be the final parameter.
If you have a module called "My::Module", and you call "My::Module->some_method", then you'd implement that like:
sub some_method {
my ($pkg, @args) = @_;
$pkg->some_other_method;
sub some_method {
my ($self, @args) = @_;
A minimal class is just:
package My::Module;
sub new {
my ($pkg, %opts) = @_;
my $self = bless \%opts, $pkg;
return $self;
}
1;
def fizzbuzz(n, *args):
cur = ['' for x in range(1,n+1)]
for m, postfix in args:
cur = [y+postfix if x%m==0 else y for x, y in zip(range(1,n+1), cur)]
cur = [str(x) if y == '' else y for x, y in zip(range(1,n+1), cur)]
return cur
print("\n".join(fizzbuzz(100, (3, 'fizz'), (5, 'buzz'))))Edit: It might be easier to instead replace input functions with ones that return TaintedString, unusable as a regular string. But it's easier to write a linter rule that prohibits any unsafe (default) system functions than one which requires safe input functions, I suppose.
It depends on what "setting up" means.
Creating an environment, given that the Python binary it will use is already installed, is trivial (standard library functionality since late 2012). So is choosing which environment to use. So is installing pre-built packages, and even legacy source packages are pretty easy (but slow, and installation runs arbitrary code which is entirely needless for these) when they only contain pure Python code. Even dependency resolution is usually not too bad.
The big problems are things like
* building multi-language packages from source locally, because this is expected to set up temporary local build environments (and build tools have to avoid recursion there)
* using external non-Python dependencies (essentially unsolved, and everyone works around this by either vendoring stuff or by not declaring the dependency and failing at runtime) — see https://pypackaging-native.github.io/ for an overview of the problems and https://peps.python.org/pep-0725/ for what they're trying to standardize to deal with it
* dealing with metadata for source packages; in the really general case you have to build the source to get this (although the package-building API now provides a hook so that build backends can specifically prepare metadata). This is mainly because some packages have dependencies that depend on very particular platform details that (apparently) can't be expressed with the "environment marker" scheme in standard metadata (https://peps.python.org/pep-0508/#environment-markers)
* and, of course, figuring out which packages need to be in your environment (Python won't decide for you what your direct dependencies are) and managing that environment over time. The reason all these other tools popped up is because Pip only installs the packages and offers very basic environment inspection; it's only now starting to do anything with lockfiles, for example, now that there is finally a standard for them (https://peps.python.org/pep-0751/).
But if you mean, is there a standard toolchain that does everything and will be officially blessed by the core language developers, then no, you should not ever expect this. There is no agreement on what "everything" entails, and Python users (a large fraction of which don't fit the traditional image of a "developer" at all) have widely varying workflows and philosophical/aesthetic preferences about that. Besides which, the core language team doesn't generally work on or care about the problem; they care about the interpreter first and foremost. Packaging is an arms-length consideration. Good news, though: the Python Packaging Authority (not at all authoritative, and named with tongue firmly in cheek, but a lot of people didn't get that) is stepping up and working on official governance (see https://peps.python.org/pep-0772/).
> at last count my laptop has 38 python binaries
Something has gone very wrong (unless you're on Windows, such that admin rights would be needed to create symlinks and by default `venv` doesn't try). To be clear, I mean with your setup, not with the tooling. You should only need one per distinct version of Python that your various environments use. I'd be happy to try to help if you'd like to shoot me an email (I use that Proton service, with the same username as here) and give more details on how things are currently set up and what you're trying to accomplish that way.
It's become a poster child for how not to do a major transition.
KDE3/4, GNOME 2/3, Python 2/3 transitions all benefited from this hindsight (still experiencing a lot of pain themselves).
Raku might be an interesting language (I haven't dug deep), but it's not Perl. Larry et al should've just called it separately from the start and allow others to carry on the Perl torch. They did this too late, when the momentum was already dead.
Perl 5 was a product of its time, but so was Linux, C, Python 2 or PHP3, and they're still very much relevant.
I don't have a link, but it may have been in one of his State of the Onion talks.
https://www.google.com/search?q=larry+wall+state+of+the+onio...
Perl's language design fetishizes solving self-inflicted puzzle after puzzle after puzzle.
https://www.artima.com/weblogs/viewpost.jsp?thread=147358
Language Design Is Not Just Solving Puzzles
by Guido van Rossum, February 10, 2006
Summary: An incident on python-dev today made me appreciate (again) that there's more to language design than puzzle-solving. A ramble on the nature of Pythonicity, culminating in a comparison of language design to user interface design.
Some people seem to think that language design is just like solving a puzzle. Given a set of requirements they systematically search the solution space for a match, and when they find one, they claim to have the perfect language feature, as if they've solved a Sudoku puzzle. For example, today someone claimed to have solved the problem of the multi-statement lambda.
But such solutions often lack "Pythonicity" -- that elusive trait of a good Python feature. It's impossible to express Pythonicity as a hard constraint. Even the Zen of Python doesn't translate into a simple test of Pythonicity.
In the example above, it's easy to find the Achilles heel of the proposed solution: the double colon, while indeed syntactically unambiguous (one of the "puzzle constraints"), is completely arbitrary and doesn't resemble anything else in Python. A double colon occurs in one other place, but there it's part of the slice syntax, where a[::] is simply a degenerate case of the extended slice notation a[start:stop:step] with start, stop and step all omitted. But that's not analogous at all to the proposal's lambda <args>::<suite>. There's also no analogy to the use of :: in other languages -- in C++ (and Perl) it's a scoping operator.
And still that's not why I rejected this proposal. If the double colon is unpythonic, perhaps a solution could be found that uses a single colon and is still backwards compatible (the other big constraint looming big for Pythonic Puzzle solvers). I actually have one in mind: if there's text after the colon, it's a backwards-compatible expression lambda; if there's a newline, it's a multi-line lambda; the rest of the proposal can remain unchanged. Presto, QED, voila, etcetera.
But I'm rejecting that too, because in the end (and this is where I admit to unintentionally misleading the submitter) I find any solution unacceptable that embeds an indentation-based block in the middle of an expression. Since I find alternative syntax for statement grouping (e.g. braces or begin/end keywords) equally unacceptable, this pretty much makes a multi-line lambda an unsolvable puzzle.
And I like it that way! In a sense, the reason I went to considerable length describing the problems of embedding an indented block in an expression (thereby accidentally laying the bait) was that I wanted to convey the sense that the problem was unsolvable. I should have known my geek audience better and expected someone to solve it. :-)
The unspoken, right brain constraint here is that the complexity introduced by a solution to a design problem must be somehow proportional to the problem's importance. In my mind, the inability of lambda to contain a print statement or a while-loop etc. is only a minor flaw; after all instead of a lambda you can just use a named function nested in the current scope.
But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption.
Mathematicians don't mind these -- a proof is a proof is a proof, no matter whether it contains 2 or 2000 steps, or requires an infinite-dimensional space to prove something about integers. Sometimes, the software equivalent is acceptable as well, based on the theory that the end justifies the means. Some of Google's amazing accomplishments have this nature inside, even though we do our very best to make it appear simple.
And there's the rub: there's no way to make a Rube Goldberg language feature appear simple. Features of a programming language, whether syntactic or semantic, are all part of the language's user interface. And a user interface can handle only so much complexity or it becomes unusable. This is also the reason why Python will never have continuations, and even why I'm uninterested in optimizing tail recursion. But that's for another installment.
Larry Wall originally wanted to call it "Pearl", but found there was already a language by that name, so he shortened it to "Perl".
The name is sometimes expanded as "Practical Extraction and Report Language", or as "Pathologically Eclectic Rubbish Lister" (Larry Wall's own phrase, mentioned in the Perl man page).
But yes, "Perl", not "PERL", is the correct name for the language.
(Ada, which was named after a person, has had the same problem, though as far as I know there isn't even a retronym for Ada.)
Perl did not only have mod_perl. It also had the same kind of frameworks that made Ruby and Python great for web development. It was called Catalyst and was production ready around the same time as RoR and Django.
The real reason why perl failed on this front, IMHO, is that the language makes it super unergonomical to define any nested data structures. In Javascript, Ruby and Python, a list of dictionaries is just some JSON-like syntax: { "x": [...], "y": [...] }
In perl you have to deal with scalars, references, references to scalar, value references, ... and you have the sigils that mean different things depending on what the variable contains. I mean, I spent significant time writing perl and never figured this out.
In a world where you just want a CRUD to load/save a piece of structured data, the ones that let you operate on the data and keep your sanity wins.
The king wisely had the software developer beheaded,
and they all lived happily ever after.
Should people just not make new languages any more?
Should new languages not bear deep resemblances to existing ones?
> Hand-migrating is nightmarishly costly. Look at Python 3.
> It's much more tractable if you can do most of that migration automatically using tools.
There was and is in fact abundant tool support for this in Python. The `2to3` script shipped with Python and the corresponding `lib2to3` was part of the standard library through 3.11. The third-party `six` compatibility libraries are still downloaded from PyPI more often than NumPy.
> In order to do that, the tools need to be able to reason in detail about the semantics of a program just using static analysis.
The experience of these tools users disagrees, from what I've seen. They produce ugly code in places, but it generally passes the tests. Yes, manual fixes are often necessary, but there were source packages published in that era (and it's not like they disappeared from PyPI either) that would detect the Python version in `setup.py`, run the tool if necessary at installation time, and have happy users.
Perl was once everywhere. Or at least it felt that way. Around the turn of the millennium, it seemed that almost every website was built on the back of this scripting language. It processed massive amounts of text—mechanisms for doing this powerfully and easily were part of the language—and it was even used in bioinformatics, munging and churning through genetic data. Based on one list, the companies that used Perl ranged widely: Amazon, Google, Yahoo, Deutsche Bank, Akamai, Citibank, Comcast, Morgan Stanley, Mozilla. A lot of Craigslist was programmed in Perl.
Even at its peak use, the popularity of Perl was always a bit surprising. Perl is an undeniably messy language. It’s often referred to as the “duct tape of the internet,” with programmers joking that it’s a “write-only” language: You write in it but seldom read it (at least successfully).
There is an amalgamated mashup nature to Perl, all in service of its motto: “There’s More Than One Way to Do It.” Just as there are synonyms in English, Perl has a variety of approaches to writing the same thing. While this is a common feature of programming languages to a certain degree, Perl seems to want to knock you over the head with it. There are multiple ways, for example, of writing conditional statements, from using the traditional “if” to “unless”; to writing an if statement backward in a single line; to even a three-part operator that involves a question mark and a colon. I have a distinct memory, in the early 2000s, of writing code in Perl one day, and the next day not understanding what I had written.
But this clutter and baroque structure are in fact intentional and part of the broader philosophy that underlies Perl. The language’s creator, Larry Wall, was trained in linguistics, and his intention was to become, along with his wife, a missionary involved in rare languages. Wall ended up taking a different path and fully embraced coding. But his deep thoughts around how languages work never left him.
Wall’s perspective seemed to be that an obsession with linguistic purity was overrated. English has words from French, Greek, German, and even Akkadian, betraying its winding history and multifarious origins. We split our infinitives and dangle our modifiers. We have puns, both intended and not. So what’s a little bit of strangeness when it comes to how to write an if statement? Wall viewed evolution as part of the process of language development. There is an organic process going on here, and the final products needn’t be orderly. And so, a broad—and nonjudgmental—approach to language construction is vital, whether it’s a language designed to write scripts or sonnets.
Perl has its “more than one way” to do things and English has its numerous styles and flexible nature, a nature that can contain everything from cooking recipes to haikus, shopping lists to Faulkner. That is the sign of something that is truly open-ended. As Wall once said: “I’m a firm believer that a language … ought to be an amoral artistic medium.” If Perl has any overarching vision or dogma, it’s merely the fact that, perhaps, there shouldn’t be programming dogma at all.
To be clear, I was never a deep user of Perl. Its syntax and messiness overwhelmed its power for me, and when I was introduced to the well-ordered structure of Python, I ran to that language and never really looked back. This might in fact be a hint as to why the language lost its luster. Even in 1998, during its heyday, there were suggestions that Perl’s bloat might lead to a desire to jump to something “cleaner.” Whatever the reason, Perl is no longer as popular as it once was.
Still, I find myself returning to this strange language, and I think it’s because of the humility at its core. We need humility as we recognize that our world is more complicated than we might be able to comprehend, even or especially when it comes to the large technological systems of our own making (AI, cough cough). A single comprehensive theory or model won’t cut it in a world of exceptions and edge cases and raging complications. We need slow, stumbling approaches, and Perl’s evolved pluralism can show us the way.
Customers also do not really care what something is or isn't built in, except if the product is made for developers.
The vast majority of products are made for non-developers.
https://www.youtube.com/watch?v=1kFnHPHBcb4
Did you know Ada and Linda were both named after unrelated people with the same last name?
They should, but they should understand it's very hard to get widespread adoption when they do. Not impossible, but very hard.
> There was and is in fact abundant tool support for this in Python. The `2to3` script shipped with Python and the corresponding `lib2to3` was part of the standard library through 3.11. The third-party `six` compatibility libraries are still downloaded from PyPI more often than NumPy.
Yes, and even so everyone involved knows the transition took a very long time, required a ton of labor, and was a major headache for many years.
Work on Python 3 began in 2006, and Python 2 wasn't officially sunsetted until 2020 [1]. To put that in perspective, the Python community spend almost as much time migrating to Python 3 as they spent in Python's entire history prior to that point. (Python was 15 in 2006, and it took them 14 years to deprecate Python 2.)
You'll notice too that the easiest changes to automate were the ones that were either lexical (renaming core library methods) or syntactic (print to print()), and the hardest ones involved the change to types of values (strings).
Static types make it much easier to automatically migrate code.
Mason was available before any of those.
There are also other, less popular options as is often the case with any Perl feature or module.
It's pretty good at everything it does. Are there purpose built specialist tools that are better for many of the things it does? Sure! But the efficacy of a Swiss Army Knife shows that, most of the time, you don't need to bother chasing down the perfect screwdriver (e.g.) if there's just a loose screw to deal with.
I had a clear simple straightforward mental model of how Lisp and PostScript references and also C pointers worked, which only misled and confused and disappointed me when thinking about Perl:
https://donhopkins.medium.com/the-shape-of-psiber-space-octo...
When I sat down and tried to type my simple straightforward design in as Perl, I suddenly realized that you can't have a reference to something that doesn't have a name, and that Perl name based references, as much as they masqueraded as C or C++ "&" syntax that takes the address of an object, were a TOTALLY DIFFERENT THING.
Perl loved to cherry pick and amalgamate the syntax of other languages (usually terrible languages like bash and awk), presumably to "help people who know that language learn Perl easily", but without any of the semantics, which actually makes it MUCH harder to learn, because "&" LOOKS like C but behaves completely differently and is much more limited and quirky.
You don't have to assign a C value to a global variable in order to take its address.
The syntax and choice of sigils isn't the hard part about learning a language, and if you get the semantics wrong, imitating just the shallow surface syntax of another language that got the semantics right only confuses and disappoints.
When you haphazardly mix and match the "syntactic sugar" of many poorly designed languages together into a discordant stew of artificial sweeteners with bizarrely different semantics, you get "syntactic syrup of ipecac".
Pre-Perl 5 (Perl 4 and earlier):
References were purely symbolic, built on typeglobs and package-variable names. You could only alias or refer to a variable that lived in the symbol table; there was no way to grab a pointer to a literal or temporary value, and you couldn't take a reference to a lexical (my) variable under strict. This made nested or nameless data structures effectively impossible without heavy manual bookkeeping.
Perl 5.0 (October 1994) — Hard references and anonymous structures:
Perl 5 finally introduced true, first-class references via the backslash operator (\) and the anonymous data constructors: [ … ] for arrays and { ... } for hashes. This let you write things like:
my $tree = { name => "root", children => [ { name => "leaf" } ] };
Explicit dereferencing, context-sensitivity, and autovivification:
Even with hard references, you must unpack them explicitly ($ref->[0], $href->{key}), and Perl’s context rules (scalar vs. list vs. void) can still be tricky. Perl’s autovivification feature (auto-creation of nested hashes/arrays on first dereference) eases some boilerplate—but can also surprise newcomers used to more explicit models.
How Perl compares to Lisp, PostScript, JavaScript, Ruby, Python, etc:
Lisp: Lists are built from cons cells and can be manipulated directly as first-class values, e.g. (list 1 2 (list 3 4)).
PostScript: Arrays ([1 2]) and dictionaries (<< /Key (Value) >>) are literal, nested, and don’t require separate pointer syntax.
JavaScript / Ruby / Python: All provide JSON-style literals ([1,2,[3,4]], {"x":1,"y":[2,3]}) and let you dive into nested structures without ever writing a backslash or sigil beyond the top-level container.
By not getting references right from day 1, then reluctantly iterating over decades on experimental hacks and after-the-fact syntactic baggage layered on top of the initial terrible design, Perl made trade-offs that cost much more than they saved from the self-inflicted problems they were trying to solve.
Fragmented syntax: Multiple dereferencing forms and feature-gated tweaks (postfix deref, autovivification pragmas) splinter Perl into a patchwork of behaviors.
Surprise side-effects: Autovivification can silently spawn large, unused data structures, leading to hidden memory/performance hits.
Subtle bugs: Context-sensitive rules (when autovivify, when not) remain a common gotcha, even for veteran Perl hackers.
Compatibility drag: Supporting both legacy 5.x versions and modern features forces extra version-checks, boilerplate, and warning squelches.
Cognitive overhead: Juggling backslashes, sigils, and varied deref styles demands a more fragmented mental model than the uniform list/map syntax of Lisp-style or JSON-based languages.
"The unspoken, right brain constraint here is that the complexity introduced by a solution to a design problem must be somehow proportional to the problem's importance." -Guido van Rossum
Edit: Of course Perl finally apes JSON-style literal syntax almost verbatim, but still has the old bad semantics, and getting there plastered over deep complexity you still have to cope with:
Feature-gated syntax: New deref forms (postfix, slices) require pragmas or newer Perl versions.
Autovivification surprises: Nested lookups can silently create unused data, bloating memory.
Multiple deref styles: Backslashes, braces, arrows and sigils—each with its own context rules—fracture your mental model.
Legacy support: To run on <5.24, you need version checks, warning silences, or to avoid modern sugar altogether.
Hidden complexity: Under the JSON-like literals lies a maze of sigils, contexts, and edge-case behaviors—far from the uniform simplicity of Lisp / PostScript / JS.
"Many, if not most" isn't good enough, because the edge cases always come back to bite you. You can't just rearrange the deck chairs on the Titanic and expect the ship not to sink. And sank it did, a long time ago.
Valid is either
sub () {
my ($x, $y, $z) = @_;
sub ($x, $y, $z) {If uv isn’t a standard, it’s because not enough people have tried it. It is obscenely good at its job.
We didn’t see adoption nearly this fast for poetry, pipenv, or conda (or hatch or PDM, but I never saw those as even reaching critical mass in the first place).
Those tools got pretty popular, but it took a long time and most folks found them to have a lot of tradeoffs (miles better than Python’s first party tooling, but still).
I’m not seeing that with “uv”. Other than concerns about Astral’s stewardship model (which could be valid!), I’m not seeing widespread “it works but is hard to use” dissatisfaction with the to the way I do with, say, poetry.
Couple that with uv durably solving the need for pyenv/asdf/mise by removing the pain of local interpreter compilation entirely, and I do think that adds up to uv being fundamentally different in popularity or approach compared to prior tools. Is that “different” the same as “better”? Time will tell.
As to being written in Rust? Shrug. A ton of shops for whom uv has been transformative don’t even know or care what language it’s written in. Being Rust provides, in my opinion, two benefits: a) avoiding chicken-and-egg problems by writing the tool for managing a programming language environment in a different language that is b) not bash.
Myself, I like Wiha's fullsize multibit one that I got in 2018 or so, first because it's an excellent, versatile, thoughtfully designed, and very repairable tool, and second because keeping it and one big flathead in my toolbag is all the screwdrivers I usually need around the house. Granted, that's about a 20-pound toolbag. But it's also everything I'll need in the 90+% home repair/maintenance case, along with my socket set ~99%, and I never have trouble finding it or anything that lives in it. (Unless I forget to put things back, of course. But that's on me.) Same for everything else a Swiss Army does, which is why there isn't one in my toolbag.
I don't really need to convince you, of course. I'd just hate to see anyone inadvertently misled into overspending on a broadly unsafe "all things to all people" social statement play, the exact equivalent in taste and quality of a Mont Blanc fountain pen, rather than invest the same money in more reasonably priced tools worth using. And what's on my keyring is a Leatherman Squirt.
The Perl syntax for this is pretty similar:
[1,2,[3,4]], {"x", 1,"y", [2,3]}
that can also be written, with a bit of syntactic sugar:
[1,2,[3,4]], {x => 1, y => [2,3]}
For many, if not most, cases, given a Perl data structure, the round trip "Perl -> JSON -> Perl" is transparent.
This is untrue though.
my ($x, $y, $z) = @$_[0];
If $_[0] is an array reference, @$_[0] becomes a list.
The joke was a reference to most wrong Perl programs being valid for something.
Hence the meme: "93% of Paint Splatters are Valid Perl Programs"
standard
I've heard this a lot, but I don't really understand the use case. It seems that people want to do development in Python, want to install and manage third-party Python packages, and know how to use command-line tools, but somehow they don't already have Python installed and would find it challenging to install directly? Building from source on Linux is a standard "get dev packages from the system package manager; configure, make and install" procedure that I've done many times (yes, putting it beside the system Python could break things, but you can trivially set an alternate install prefix, and anyway the system Python will usually be a version that meets the basic needs of most developers). Installing on Windows is a standard Windows installer experience.
Aside from that, people seem to imagine "chicken-and-egg" scenarios with pip making itself available in the environment. But this is a thoroughly (if inefficiently) solved problem. First off, for almost three years now pip has been able to install cross-environment (albeit with an ugly hack; I detail some of this in https://zahlman.github.io/posts/2025/01/07/python-packaging-...). Second, the standard library `venv` defaults to bootstrapping pip into new environments — taking advantage of the fact that pre-built Python packages are zip archives, and that Python has a protocol for running code from zip archives, which the pip package implements.
The real bootstrapping issue I've heard about is https://github.com/pypa/packaging-problems/issues/342 , but this affects very few people — basically, Linux distro maintainers who want to "build" an entire Python toolchain "from source" even though it's all Python code that the runtime could bytecode-compile on demand anyway.
So what if uv is everywhere you look? So were Poetry, pipenv, and so on. Give it time.
Even then, if you have the original environment, you may very well not need to re-create it. If you do need to re-create an equivalent for a newer Python version (EOL versions of Python don't just spontaneously vanish, but maybe you upgraded your system or something, or better yet maybe you're planning in advance for that) then you generally can easily create the needed requirements.txt (or, for that matter, a PEP 751 lockfile) from the old environment.
Again, no. I have a very fine set of tools available for jobs large enough when it'll matter.
You just seem really invested in the idea that the SAK sucks, when it just doesn't. It's entirely sufficient for most small jobs. That there exist BETTER options for larger jobs does not mean the SAK sucks.
>I'd just hate to see anyone inadvertently misled into overspending on a broadly unsafe "all things to all people" social statement play, the exact equivalent in taste and quality of a Mont Blanc fountain pen,
I have absolutely no idea what you mean to be saying with this sentence.
Are you arguing that Victorinox knives are expensive and dangerous? That's a wild thing to say. The one in my pocket was like $35, and it's safe as houses.
Are you arguing they're somehow equivalent to high-end fountain pens? That's even crazier, since perfectly delightful fountain pens exist at a fraction of the cost of a Mont Blanc (which, IME, is a pen that people who care more about brands than nibs buy).
Maybe take a breath, and try again?
>I remember encountering exactly that problem in the late 80's [...]
Tell me what I wrote that was untrue. Perl 5 wasn't released until October 1994.
In Perl 4, symbolic aliases worked via typeglobs, and there was no way to grab the address of a literal, temporary or lexical variable.
And even in Perl 5, references still required complex syntax, had lots of surprising side-effects, edge cases, subtle bugs, multiple forms, context sensitive rules, autovivification hacks, memory overhead and waste, subtle foot guns, and they were pointlessly much more complex and harder to use than references in most other languages.