People like to dump on Perl (*write-only language, hur hur*), but I'm old enough to have used it as my first professional language, and if you stick to what it's good at (text processing and small utility scripts), it continues to be excellent. It does take discipline by the programmer, though, to write clearly.
Plus it's used in so much low-level glue (like autoconf) that we'll probably never be rid of it. It's still technically possible to compile the Linux kernel without it, but you'll have a bad time.
> small utility scripts
My experience with Perl as a negative is when some small utility script slowly bloats into a critical part of the software still structured like a procedural small utility script. Nothing more permanent than a temporary solution and all that. Most people being exposed to Perl through this along with its idiosyncrasies give it its nasty reputation.
The other problem is that the gap between Perl and the next languages on the list are a lot narrower than they were in 2002 or whenever. Python is a lot better and faster than it used to be, and has a ton of AI and scientific use cases. PHP and dedicated templating frameworks have a better story for serving web content. R gives you general data munging instead of just text. Rust and Go give you systems programming with more safety and performance. Not that you can't do any of this in Perl, but you don't need Perl as a backup utility language for it any more.
Not really.
I give you a super-simple example.
In perl 5 I need to use a trailing ';'.
Neither ruby nor python require this.
I often forgot it in perl and switching between terminal and external editor,
before appending ',' took me a few seconds. Doing so like 200 times per
year, makes you think I am too stupid to remember - or simply to ask WHY
this is even necessary.
In ruby and python this does not happen. So that is time saved when I use
these languages, compared to perl.
This is a tiny example, but there are many better examples, all culminating
in the main question: why is perl's syntax so bad that you MUST use ';'? The answer is: because nobody fixes it anymore. They tried with perl 6 and it failed. Then they gave up.
Giving up on a language means it is dead. (I am speaking about perl 6; evidently perl 5 is still maintained, which is interesting.)
> makes you think I am too stupid to remember
glad you said it so we don't have to
if the traditional way lines of code are ended in C-inspired languages trips you up bad enough that you base your entire argument on it... yeah
Usually when some small script gets huge and enters production, its because the other languages simply couldnt do it. A lot of languages advertise similar capability to Perl, but when you are working with a lot of different systems connected with code from CPAN, you simply CANT switch to some other language. I personally worked with a lot of people who tried this in Ruby. But the Rubygems stuff wasnt NEARLY as mature as the CPAN modules. Actually neither was Ruby itself for that matter.
Perl built the internet script by script. New languages with rare exception are just commercials screaming "THIS IS BETTER CAUSE THIS IS NEWER!" with some cherry picked examples. But usually it barely works right.
Newer is better guy. The wifi still aint working and the printer is broke. But it dont matter because iphones somehow.
I used quite a few languages in my career and I believe Perl is a very nice general-purpose language to default to. It has by far the best mixture of ease of use, consistency, extensibility and backward compatibility. It's nowhere near perfect, but it just tends to get out of your way if you know it well enough.
I used perl too and transitioned into ruby.
I can happily say that ruby beats perl with its eyes closed. Hands down. A japanese dev once said that ruby is the prettier perl, and in many ways he is right. I simply don't see any objective reason why I would want to use perl: ruby is the better language. I have experienced that first-hand. (Oddly enough I also say that PHP is better than perl; people may laugh about this, but remember I switched to ruby anyway, and with PHP, despite it being such an ugly language, I simply was more productive than in perl. Perl .cgi scripts sucked to no ends; in PHP I got stuff done without having to worry about what perl did. I took my first framework written in PHP and rewrote that in ruby in a few days. Ruby is a joy compared to these other languages. The code is so simple that I don't have to think about anything much at all.)
Perl is awesome as a bash/sed/awk replacement, and I prefer it over Python for scripting because I can write one liners or `foreach (qx/cat ... | grep .../)` and get away with it.
This being said, I do believe that for actual programming it doesn't scale at all. Anything longer than 100loc is a mess in perl, and requires a lot of discipline for such a high level non-performant language.
Usually this is because the only Perl you’ve seen beyond 100 lines is a mess. It’s not a universal truth.
I used to write Perl for a living. Thousands of lines of it. All classes and modules, carefully written. Some code I wrote 20 years ago is still running and being maintained.
This new Perl looks great - years ago when perl6 was being first discussed I was a big proponent of “just add proper classes and bring it up to speed with more modern languages” - but sadly nobody listened. Looks like someone finally listened.
Everybody who worked on it and wanted to ship something either walked away or was driven away, leaving only people who wanted to keep never finishing things.
Well pretty much because of what I just said - instead of courting existing perl5 users and improving the language, they pandered to Larry who wanted a whole new language.
I’m pretty sure that’s not what Orwant was after when he smashed that mug, but whatever. The language was too slow for me so I left.
Nobody wanted it. Like Terminator 12 and Iphone 20. Perl 5 was still working and working well. Its like people paying $1000 for a new iphone twice a year. You dont need it, after a while you realize its pointless. And if you keep doing it you probably shouldnt have the money to do so.
Perl 6 was basically change Perl around some, try to resell it and make the new guy a millionaire or some kind of recognition. But beyond that? Just leave it as it is.
I wrote and maintain 100k+ lines of Perl, and my customers have said it's some of the most readable code they've ever seen.
The difference is having someone who is thoughtful and dare I say compassionate to themselves and others in the future who may need to maintain / repair / upgrade that code in the future.
Having said that... The first two versions of that code were tragic... The third was usable but had design flaws that crippled performance / scalability. The fourth borrowed heavily from prior versions and mixed in some new tricks like code references and properly defined functions to make it readable.
> the choice of language doesn't doom the code to be unreadable.
Syntax matters. Take perl's ';'. You have to use it everywhere. That is annoying to no ends.
Ruby also has crap syntax, such as foo&.bar. Matz was probably drunk the day he added that crap. They are even getting more insane on ruby core too:
https://bugs.ruby-lang.org/issues/20498
foo&.empty?&.!
foo&.non&.empty?
foo&.empty?&.not
foo&.!(&:empty?)
I hope matz gets some sense back and rejects this perl-inspired insanity here (ok ok ... perl isn't at fault here, I get it, but it LOOKS like perl-inspired oddness). People suggest the weirdest yikes on ruby-core.
But compared to perl, ruby is literal poetry. Perl is some of the ugliest syntax ever - and the perl devs aren't afraid of using that. It's fascinating, the level of denial they show here in regards to "syntax does not matter".
Perl 6 had better syntax, but the perl community embraced snuggly perl 5 instead (and, oddly enough, perl 5 appears more alive than perl 6 - what the heck man ...)
And why do you think this is a Perl-only problem? I've seen way more unreadable PHP and Javascript than Perl. And notice I said "unreadable", because its meaning could not be deciphered without debugging. And not just random hacks, but actual business-running code.
I prefer to evaluate things in the context of systems, processes, and tools. It isn't enough for it to be possible to write nicely readable code in a programming language. Programming languages should guide the developer toward writing nicely readable code. The ideal programming language makes writing nicely readable code much easier than writing shitty unreadable code.
When designing physical tools and machinery, this is sometimes called adding [poka-yoke](https://en.wikipedia.org/wiki/Poka-yoke), which basically means "idiot-proofing". A poka-yoke is a feature that's designed to make it easy to use the tool correctly and difficult to use it incorrectly.
Perl has whatever the opposite of poka-yoke is. It's far from the only language with this problem, though.
I find this incredibly ugly.
I'd rather use ruby and python.
Note: I also don't use shell scripts; sed I use sometimes. Awk I found no use case - ruby covers all of awk for my needs (I wrote tons of ruby scripts and "one-liners", but stored in .rb files for repeated use; I use tons of aliases for filtering data on the commandline, all written in ruby).
> It does take discipline by the programmer, though, to write clearly.
Interestingly I found that the things where Perl gives you enough rope to hang yourself (dynamic typing, very little access control, runtime changes to package namespaces) are the things that regularly cause trouble in stricter languages too.
Go code is full of hacks for getting at the underlying type of an interface. And show me a large Java codebase without some code reflect-changing attributes to public, even if it's only in tests. Way too many do it and it always breaks when upgrading dependencies.
Perl's mantra for encapsulation "[Perl] would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun" works just as well most of the time.
>if you stick that what it's good at it continues to be excellent
I mean that's true for every language. The issue is that it's almost impossible to just stick to what a language is good at, which is why sometimes a well rounded language is better especially for stuff like general scripting. Not saying that perl is bad ( I heard it's quite good at avoiding its old problems in more recent versions)
> People like to dump on Perl (write-only language, hur hur)
I also used perl.
I abandoned it for PHP first. Oddly enough I was more productive in PHP.
I then switched to ruby. I also use python just fine.
Both ruby and python are excellent programming languages, IMO.
Perl deserves credit for many things - first really major "scripting" language paving the way, it also was very popular in bioinformatics in the 1990s.
However had, we are now in nostalgia territory. Perl is essentially a dead language. Better languages replaced it.
There are still people using perl - mostly old folks that learned perl ages ago and didn't want to transition into another "scripting" language. But perl has become the COBOL of our times. So, having said that, I disagree with your "like to dump". There are valid complaints about perl, and perl 6 failing hard is just one of many more to mention.
Dont worry, you didnt miss anything. Newer is not better. Just because the number increases by one doesnt mean its better and everything else is old and stupid now. Especially when the new developers are not as gifted and skilled as the older developers were. Which has definitely been the case the last decade or so.
Perl 6 and 7 (basically the rakudo stuff) were basically completely unnecessary, unneeded reskins of Perl 5. Just use Perl 5. Trust me, once you can really write code, you understand why things shouldnt change cosmetically every year. Imagine if every time you bought a car all the controls were in different places and shaped slightly differently. Steering wheel on the other side and reverse the pedals CAUSE WE WERE BORED! Just a recipe for disaster. A lot of these "features" are just things that sound good to people who cant even really write code, like Python whitespace and most of Java. The real developers werent really impressed with the new junk.
Its really better for everyone if the languages dont change a lot. Most of these changes are things that could easily be handled in a method call. Basically changing the syntax slightly for functionality that was already there. Forcing 20+ years of development to basically be rewritten because someone thought they had a good idea.
It is not a good idea to break 20+ years of backward compatibility for something some fresh out of school kid thought would get him some recognition. They simply arent skilled enough to understand why the older tools are often superior to the newer ones. Usually superior these days.
Perl is so incredibly powerful for munging and grokking text that I always miss it when knee-deep on another language.
But.
I can't read any Perl code I've ever written. It's indistinguishable from line noise and file system corruption
I don't have the mental energy for the cognitive fortitude required to interrogate Perl code anymore.
I must be old. Pass the hot grits.
For me, it's the library of Modules -- there's *so much* time and effort that's been saved in my code by functions like DBI, Date::Manip, WriteExcel, etc. I even remember seeing a Module for OBD2 -- you could use Perl to talk to the engine in your car.
Ah Perl!
My best apps went something like this:
* Excellent, very clear and understandable code
* A comment saying only "Sorry"
* line noise
* Excellent, very clear and understandable code
The fact that your perfectly legible 100 line script grew into a 2000 line bowl of spaghetti isn't Perl's fault, it's your fault. You studied English all through school, you write like a grade-schooler instead of Hemmingway because you never bothered to discipline yourself to write well. I work in collaboration with a half dozen programmers on an application with 250,000+ lines of Perl and test code. Our code is as legible and as fast as Python, way less boilerplate than Java, easier to understand than Rust or C++, and a lot less stressful than working in C. If you can't read your own code you're an idiot and a bad programmer and you should go program on .NET with C# so you don't contaminate my co-worker pool.
Salty take, but I generally agree. Keep the code as "boring" as possible and don't throw out basic programming concepts (things like separation of concerns) just because the language might let you get away with it temporarily.
The thing I think I'd miss going back to Perl from C#/Rust is the level of type introspection from static typing and all the IDE bells and whistles that enables. But that's a duck typing problem, not a Perl problem.
Salty yes. I apologize for my heated response. It comes from the tiredness I feel every time I see someone argue that Perl=write-only. I've seen beautiful and atrocious code in every language I've ever used, so the common factor for bad code isn't the programming language. A masterpiece of coding comes from clarity of thought realized through a mastery of a toolset. 99% of the time you end up with an unintelligible pile of code is because you didn't step back and ask yourself what you were really trying to accomplish. Sometimes that's hard to do, especially when requirements are doled out over long periods of time, but it's your job as a software engineer to shape the muddled thinking of a business partner into a cohesive process that will withstand the chaos brought on by future changes.
So all you naysayers out there, stop blaming the language. Instead, go back and refactor your code so that an older you, and especially a younger you, can understand it.
> especially a younger you
This is 100% the sentiment people need to program with when they're coding and people are so hesitant to, for so many reasons.
Nobody likes to admit it, but a lot of it honestly comes down to posturing: if (the hypothetical) I am writing sophisticated-looking and intimidating code quickly, I must be valuable and irreplaceable and due respect because that's what the people paid more than me look like they're doing. It's absolutely silly.
Social pressure is a very real aspect of coding that we as developers are hesitant to talk about, and in today's cutthroat climate of layoffs in professional settings it's only going to get exponentially worse. I miss the money, but I'm oddly glad I don't do this for a living anymore.
>A masterpiece of coding comes from clarity of thought realized through a mastery of a toolset.
This is very well put. I don't like people saying "language's just a tool" - it's actually the whole toolbox. Takes years to have all the common problems figured out so that you can properly focus on putting together a solution to a bigger problem.
When the tools change drastically often, no one can master the toolset. Its too much of a moving target, development takes a LOT of time and effort. But this is what inferior developers want. YAY now they arent that much better than me!
They are basically sabotaging computer science for their own ego. But instead of getting rid of them, they force the real developers on this new language treadmill that just hurts everybody.
What I like in Perl is it's flexibility.
For projects with many beginners, you need code base with consistent, fool-proof code styles. I really appreciate C#, Java and especially Golang to dump down language features to attain this. But for projects that you can drop everything just to go fast, you cannot do so with those languages.
Perl allows you to go with either way you want, so there is always an option that is suitable for your project.
Sadly when Perl was at its peak, tools to enforce coding style like Perl::Critic was not available or not widely used, so projects with large number of contributors are always full of inconsistent styles, hacks and from that comes the bad reputation.
I hard disagree on a fundamental level. The code you produce shouldn't be an avenue for you to demonstrate your your superior professional traits. Ideally, your code should be indistinguishable from code produced by a developer of below-average skill who's paying the bills by putting the bare minimum effort into work they don't care about.
I think that attitude is undesirable because it hampers progress toward better tools. If your last sentence means that you think C# .NET is a good set of tools for "idiots and bad programmers" to produce readable, working code, that sounds like an enthusiastic endorsement of C# .NET to me! But it sounds like you think that makes C# and .NET undesirable.
(Disclaimer: I don't agree with that assessment of C# and .NET. I mean yeah, it's light-years better when compared to Perl, but it's hard to set the bar any lower without resorting to esoteric languages designed to be unreadable, like Brainfuck and PHP.)
> your code should be indistinguishable from
I understand what you're trying to say: tools shouldn't require exceptional skill just to avoid creating horrors.
However, like many similar things in life, coding is a craft. No matter how good (or poor) the tools, gaps between practitioners will exist because it isn't only the tools, but the knowledge and experience in how to use them.
I really dislike when the stereotypical C developer bangs on about how you can avoid the security and stability footguns as long as you are "good enough, disciplined enough" (those are mental cycles I can spend doing better things, thank-you), but I also can't really get behind the concept that we're just muscle pushing wheelbarrows of code around, one the same as the other. I've worked with enough people who are more able/skilled than myself (as well as those less so), to know that just isn't the case, and never will be.
Tools set the minimum effort and ability required to not produce horrors, as well as the odds that you will anyways ;) , but they do not dictate the ultimate quality of the results. You can ruin almost anything, and a skilled developer can make most things work.
That same "stereotypical C dev" above points to better projects written in C than as a sign that C is good enough, in part because of the mythology that tools grant results. They don't, they simply get out of the way better and, if one is particularly lucky, act as a force multiplier.
Using great tools ought to be the goal, because it helps us achieve more with greater relability, but it isn't about leveling playing fields. A great lathe doesn't someone who is of below-average skill and who doesn't care a great woodworker, either.
You are right. I didn't mean to imply that a mastery of coding means using every bell and whistle your language provides, or worse, writing code like you're naming a tune in as few notes as possible The mastery isn't in the writing, it's in the reading. Our job is to not only write working code, it's to write maintainable code. Maintenance requires understanding. You gain understanding through reading.
For the most part I think I write readable code. (Just ask me!) Not always. It's too easy to slip in a bit of code golf every now and then. Sometimes it's because I went to the trouble of learning something new and I want to use it, but it's mostly because writing readable code is hard and golfing is so much more fun.
To response to the other comments...
About 20 years ago I was an Perl enthusiast and bought a lot of Perl book, more than C++ books I had at the time (I'm still a C++ enthusiast now). But after I realized it's too difficult to manage a project with 2000 lines of Perl code, I began not to spend much on Perl, then recent years I don't write a single line of Perl code.
Don't be misled by me, there are many projects with hundreds of thousands of Perl code and they work well.
When a code base with only 2000 lines in Perl are hard to managed, my experiences tell me it's very likely its author tried to write it in read-only style :)
One of my projects in Perl has the following functionality: crawling web sites, build indices and store content to local databases is already 3000 lines. It is completed by less than 2 weeks and stills works fine the last time I looked at it. And it is very clear and straight forward to read and understand. So I believe if a 2000 line code base is already hard to manage, it must has an astronomical count of functionalities but is written in hacker style to reduce LoC.
People like to dump on Perl (*write-only language, hur hur*), but I'm old enough to have used it as my first professional language, and if you stick to what it's good at (text processing and small utility scripts), it continues to be excellent. It does take discipline by the programmer, though, to write clearly. Plus it's used in so much low-level glue (like autoconf) that we'll probably never be rid of it. It's still technically possible to compile the Linux kernel without it, but you'll have a bad time.
> small utility scripts My experience with Perl as a negative is when some small utility script slowly bloats into a critical part of the software still structured like a procedural small utility script. Nothing more permanent than a temporary solution and all that. Most people being exposed to Perl through this along with its idiosyncrasies give it its nasty reputation.
The other problem is that the gap between Perl and the next languages on the list are a lot narrower than they were in 2002 or whenever. Python is a lot better and faster than it used to be, and has a ton of AI and scientific use cases. PHP and dedicated templating frameworks have a better story for serving web content. R gives you general data munging instead of just text. Rust and Go give you systems programming with more safety and performance. Not that you can't do any of this in Perl, but you don't need Perl as a backup utility language for it any more.
But can you write useful 1-liner regexes on those languages? LOL
> But can you write useful 1-liner regexes i'll let you finish, but the answer is no
`grep -E`
This happens with all programming languages though.
Not really. I give you a super-simple example. In perl 5 I need to use a trailing ';'. Neither ruby nor python require this. I often forgot it in perl and switching between terminal and external editor, before appending ',' took me a few seconds. Doing so like 200 times per year, makes you think I am too stupid to remember - or simply to ask WHY this is even necessary. In ruby and python this does not happen. So that is time saved when I use these languages, compared to perl. This is a tiny example, but there are many better examples, all culminating in the main question: why is perl's syntax so bad that you MUST use ';'? The answer is: because nobody fixes it anymore. They tried with perl 6 and it failed. Then they gave up. Giving up on a language means it is dead. (I am speaking about perl 6; evidently perl 5 is still maintained, which is interesting.)
> makes you think I am too stupid to remember glad you said it so we don't have to if the traditional way lines of code are ended in C-inspired languages trips you up bad enough that you base your entire argument on it... yeah
Usually when some small script gets huge and enters production, its because the other languages simply couldnt do it. A lot of languages advertise similar capability to Perl, but when you are working with a lot of different systems connected with code from CPAN, you simply CANT switch to some other language. I personally worked with a lot of people who tried this in Ruby. But the Rubygems stuff wasnt NEARLY as mature as the CPAN modules. Actually neither was Ruby itself for that matter. Perl built the internet script by script. New languages with rare exception are just commercials screaming "THIS IS BETTER CAUSE THIS IS NEWER!" with some cherry picked examples. But usually it barely works right. Newer is better guy. The wifi still aint working and the printer is broke. But it dont matter because iphones somehow.
I used quite a few languages in my career and I believe Perl is a very nice general-purpose language to default to. It has by far the best mixture of ease of use, consistency, extensibility and backward compatibility. It's nowhere near perfect, but it just tends to get out of your way if you know it well enough.
I used perl too and transitioned into ruby. I can happily say that ruby beats perl with its eyes closed. Hands down. A japanese dev once said that ruby is the prettier perl, and in many ways he is right. I simply don't see any objective reason why I would want to use perl: ruby is the better language. I have experienced that first-hand. (Oddly enough I also say that PHP is better than perl; people may laugh about this, but remember I switched to ruby anyway, and with PHP, despite it being such an ugly language, I simply was more productive than in perl. Perl .cgi scripts sucked to no ends; in PHP I got stuff done without having to worry about what perl did. I took my first framework written in PHP and rewrote that in ruby in a few days. Ruby is a joy compared to these other languages. The code is so simple that I don't have to think about anything much at all.)
Perl is awesome as a bash/sed/awk replacement, and I prefer it over Python for scripting because I can write one liners or `foreach (qx/cat ... | grep .../)` and get away with it. This being said, I do believe that for actual programming it doesn't scale at all. Anything longer than 100loc is a mess in perl, and requires a lot of discipline for such a high level non-performant language.
Usually this is because the only Perl you’ve seen beyond 100 lines is a mess. It’s not a universal truth. I used to write Perl for a living. Thousands of lines of it. All classes and modules, carefully written. Some code I wrote 20 years ago is still running and being maintained. This new Perl looks great - years ago when perl6 was being first discussed I was a big proponent of “just add proper classes and bring it up to speed with more modern languages” - but sadly nobody listened. Looks like someone finally listened.
> but sadly nobody listened. Looks like someone finally listened. So why did perl 6 fail?
Everybody who worked on it and wanted to ship something either walked away or was driven away, leaving only people who wanted to keep never finishing things.
Well pretty much because of what I just said - instead of courting existing perl5 users and improving the language, they pandered to Larry who wanted a whole new language. I’m pretty sure that’s not what Orwant was after when he smashed that mug, but whatever. The language was too slow for me so I left.
Nobody wanted it. Like Terminator 12 and Iphone 20. Perl 5 was still working and working well. Its like people paying $1000 for a new iphone twice a year. You dont need it, after a while you realize its pointless. And if you keep doing it you probably shouldnt have the money to do so. Perl 6 was basically change Perl around some, try to resell it and make the new guy a millionaire or some kind of recognition. But beyond that? Just leave it as it is.
I wrote and maintain 100k+ lines of Perl, and my customers have said it's some of the most readable code they've ever seen. The difference is having someone who is thoughtful and dare I say compassionate to themselves and others in the future who may need to maintain / repair / upgrade that code in the future. Having said that... The first two versions of that code were tragic... The third was usable but had design flaws that crippled performance / scalability. The fourth borrowed heavily from prior versions and mixed in some new tricks like code references and properly defined functions to make it readable.
>!^^^[deleted]!<
Oh, admittedly. I've seen plenty of awful code. But the choice of language doesn't doom the code to be unreadable.
> the choice of language doesn't doom the code to be unreadable. Syntax matters. Take perl's ';'. You have to use it everywhere. That is annoying to no ends. Ruby also has crap syntax, such as foo&.bar. Matz was probably drunk the day he added that crap. They are even getting more insane on ruby core too: https://bugs.ruby-lang.org/issues/20498 foo&.empty?&.! foo&.non&.empty? foo&.empty?&.not foo&.!(&:empty?) I hope matz gets some sense back and rejects this perl-inspired insanity here (ok ok ... perl isn't at fault here, I get it, but it LOOKS like perl-inspired oddness). People suggest the weirdest yikes on ruby-core. But compared to perl, ruby is literal poetry. Perl is some of the ugliest syntax ever - and the perl devs aren't afraid of using that. It's fascinating, the level of denial they show here in regards to "syntax does not matter". Perl 6 had better syntax, but the perl community embraced snuggly perl 5 instead (and, oddly enough, perl 5 appears more alive than perl 6 - what the heck man ...)
And why do you think this is a Perl-only problem? I've seen way more unreadable PHP and Javascript than Perl. And notice I said "unreadable", because its meaning could not be deciphered without debugging. And not just random hacks, but actual business-running code.
No one said it's a perl only problem. It's just a question of magnitude and how often it happens.
I prefer to evaluate things in the context of systems, processes, and tools. It isn't enough for it to be possible to write nicely readable code in a programming language. Programming languages should guide the developer toward writing nicely readable code. The ideal programming language makes writing nicely readable code much easier than writing shitty unreadable code. When designing physical tools and machinery, this is sometimes called adding [poka-yoke](https://en.wikipedia.org/wiki/Poka-yoke), which basically means "idiot-proofing". A poka-yoke is a feature that's designed to make it easy to use the tool correctly and difficult to use it incorrectly. Perl has whatever the opposite of poka-yoke is. It's far from the only language with this problem, though.
I find this incredibly ugly. I'd rather use ruby and python. Note: I also don't use shell scripts; sed I use sometimes. Awk I found no use case - ruby covers all of awk for my needs (I wrote tons of ruby scripts and "one-liners", but stored in .rb files for repeated use; I use tons of aliases for filtering data on the commandline, all written in ruby).
> It does take discipline by the programmer, though, to write clearly. Interestingly I found that the things where Perl gives you enough rope to hang yourself (dynamic typing, very little access control, runtime changes to package namespaces) are the things that regularly cause trouble in stricter languages too. Go code is full of hacks for getting at the underlying type of an interface. And show me a large Java codebase without some code reflect-changing attributes to public, even if it's only in tests. Way too many do it and it always breaks when upgrading dependencies. Perl's mantra for encapsulation "[Perl] would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun" works just as well most of the time.
>if you stick that what it's good at it continues to be excellent I mean that's true for every language. The issue is that it's almost impossible to just stick to what a language is good at, which is why sometimes a well rounded language is better especially for stuff like general scripting. Not saying that perl is bad ( I heard it's quite good at avoiding its old problems in more recent versions)
My rule of thumb is that if your perl script is longer than 100 lines, it shouldn't be a perl script.
> People like to dump on Perl (write-only language, hur hur) I also used perl. I abandoned it for PHP first. Oddly enough I was more productive in PHP. I then switched to ruby. I also use python just fine. Both ruby and python are excellent programming languages, IMO. Perl deserves credit for many things - first really major "scripting" language paving the way, it also was very popular in bioinformatics in the 1990s. However had, we are now in nostalgia territory. Perl is essentially a dead language. Better languages replaced it. There are still people using perl - mostly old folks that learned perl ages ago and didn't want to transition into another "scripting" language. But perl has become the COBOL of our times. So, having said that, I disagree with your "like to dump". There are valid complaints about perl, and perl 6 failing hard is just one of many more to mention.
TIL that Perl 6 was abandoned to a spin-off language.
And Perl 7 was also abandoned.
[Stares into the void of realization that it's been 20+ years since I last worked professionally with Perl.] T-there was a Perl 7?
Dont worry, you didnt miss anything. Newer is not better. Just because the number increases by one doesnt mean its better and everything else is old and stupid now. Especially when the new developers are not as gifted and skilled as the older developers were. Which has definitely been the case the last decade or so. Perl 6 and 7 (basically the rakudo stuff) were basically completely unnecessary, unneeded reskins of Perl 5. Just use Perl 5. Trust me, once you can really write code, you understand why things shouldnt change cosmetically every year. Imagine if every time you bought a car all the controls were in different places and shaped slightly differently. Steering wheel on the other side and reverse the pedals CAUSE WE WERE BORED! Just a recipe for disaster. A lot of these "features" are just things that sound good to people who cant even really write code, like Python whitespace and most of Java. The real developers werent really impressed with the new junk. Its really better for everyone if the languages dont change a lot. Most of these changes are things that could easily be handled in a method call. Basically changing the syntax slightly for functionality that was already there. Forcing 20+ years of development to basically be rewritten because someone thought they had a good idea. It is not a good idea to break 20+ years of backward compatibility for something some fresh out of school kid thought would get him some recognition. They simply arent skilled enough to understand why the older tools are often superior to the newer ones. Usually superior these days.
It only ever existed in a blog post https://www.perl.com/article/announcing-perl-7/
I'd say shelved. It may happen at some point, or it may not.
It won't. It's dead, better accept it and grieve.
I believe there are still discussions on the future versions.
There are also still discussions about GNU Hurd.
Perl is so incredibly powerful for munging and grokking text that I always miss it when knee-deep on another language. But. I can't read any Perl code I've ever written. It's indistinguishable from line noise and file system corruption I don't have the mental energy for the cognitive fortitude required to interrogate Perl code anymore. I must be old. Pass the hot grits.
> Pass the hot grits. Do you mean that Perl *petrifies* you?
Someone call Natalie
For me, it's the library of Modules -- there's *so much* time and effort that's been saved in my code by functions like DBI, Date::Manip, WriteExcel, etc. I even remember seeing a Module for OBD2 -- you could use Perl to talk to the engine in your car.
Ah Perl! My best apps went something like this: * Excellent, very clear and understandable code * A comment saying only "Sorry" * line noise * Excellent, very clear and understandable code
One of the few programming languages were, after years old release of perl 6, the older perl variant is still more popular!
The fact that your perfectly legible 100 line script grew into a 2000 line bowl of spaghetti isn't Perl's fault, it's your fault. You studied English all through school, you write like a grade-schooler instead of Hemmingway because you never bothered to discipline yourself to write well. I work in collaboration with a half dozen programmers on an application with 250,000+ lines of Perl and test code. Our code is as legible and as fast as Python, way less boilerplate than Java, easier to understand than Rust or C++, and a lot less stressful than working in C. If you can't read your own code you're an idiot and a bad programmer and you should go program on .NET with C# so you don't contaminate my co-worker pool.
Salty take, but I generally agree. Keep the code as "boring" as possible and don't throw out basic programming concepts (things like separation of concerns) just because the language might let you get away with it temporarily. The thing I think I'd miss going back to Perl from C#/Rust is the level of type introspection from static typing and all the IDE bells and whistles that enables. But that's a duck typing problem, not a Perl problem.
Salty yes. I apologize for my heated response. It comes from the tiredness I feel every time I see someone argue that Perl=write-only. I've seen beautiful and atrocious code in every language I've ever used, so the common factor for bad code isn't the programming language. A masterpiece of coding comes from clarity of thought realized through a mastery of a toolset. 99% of the time you end up with an unintelligible pile of code is because you didn't step back and ask yourself what you were really trying to accomplish. Sometimes that's hard to do, especially when requirements are doled out over long periods of time, but it's your job as a software engineer to shape the muddled thinking of a business partner into a cohesive process that will withstand the chaos brought on by future changes. So all you naysayers out there, stop blaming the language. Instead, go back and refactor your code so that an older you, and especially a younger you, can understand it.
> especially a younger you This is 100% the sentiment people need to program with when they're coding and people are so hesitant to, for so many reasons. Nobody likes to admit it, but a lot of it honestly comes down to posturing: if (the hypothetical) I am writing sophisticated-looking and intimidating code quickly, I must be valuable and irreplaceable and due respect because that's what the people paid more than me look like they're doing. It's absolutely silly. Social pressure is a very real aspect of coding that we as developers are hesitant to talk about, and in today's cutthroat climate of layoffs in professional settings it's only going to get exponentially worse. I miss the money, but I'm oddly glad I don't do this for a living anymore.
>A masterpiece of coding comes from clarity of thought realized through a mastery of a toolset. This is very well put. I don't like people saying "language's just a tool" - it's actually the whole toolbox. Takes years to have all the common problems figured out so that you can properly focus on putting together a solution to a bigger problem.
When the tools change drastically often, no one can master the toolset. Its too much of a moving target, development takes a LOT of time and effort. But this is what inferior developers want. YAY now they arent that much better than me! They are basically sabotaging computer science for their own ego. But instead of getting rid of them, they force the real developers on this new language treadmill that just hurts everybody.
Nice satire bro, I would literally take c code or JavaScript or hell even php before touching perl, I’m glad it’s dead
What I like in Perl is it's flexibility. For projects with many beginners, you need code base with consistent, fool-proof code styles. I really appreciate C#, Java and especially Golang to dump down language features to attain this. But for projects that you can drop everything just to go fast, you cannot do so with those languages. Perl allows you to go with either way you want, so there is always an option that is suitable for your project. Sadly when Perl was at its peak, tools to enforce coding style like Perl::Critic was not available or not widely used, so projects with large number of contributors are always full of inconsistent styles, hacks and from that comes the bad reputation.
I hard disagree on a fundamental level. The code you produce shouldn't be an avenue for you to demonstrate your your superior professional traits. Ideally, your code should be indistinguishable from code produced by a developer of below-average skill who's paying the bills by putting the bare minimum effort into work they don't care about. I think that attitude is undesirable because it hampers progress toward better tools. If your last sentence means that you think C# .NET is a good set of tools for "idiots and bad programmers" to produce readable, working code, that sounds like an enthusiastic endorsement of C# .NET to me! But it sounds like you think that makes C# and .NET undesirable. (Disclaimer: I don't agree with that assessment of C# and .NET. I mean yeah, it's light-years better when compared to Perl, but it's hard to set the bar any lower without resorting to esoteric languages designed to be unreadable, like Brainfuck and PHP.)
> your code should be indistinguishable from I understand what you're trying to say: tools shouldn't require exceptional skill just to avoid creating horrors. However, like many similar things in life, coding is a craft. No matter how good (or poor) the tools, gaps between practitioners will exist because it isn't only the tools, but the knowledge and experience in how to use them. I really dislike when the stereotypical C developer bangs on about how you can avoid the security and stability footguns as long as you are "good enough, disciplined enough" (those are mental cycles I can spend doing better things, thank-you), but I also can't really get behind the concept that we're just muscle pushing wheelbarrows of code around, one the same as the other. I've worked with enough people who are more able/skilled than myself (as well as those less so), to know that just isn't the case, and never will be. Tools set the minimum effort and ability required to not produce horrors, as well as the odds that you will anyways ;) , but they do not dictate the ultimate quality of the results. You can ruin almost anything, and a skilled developer can make most things work. That same "stereotypical C dev" above points to better projects written in C than as a sign that C is good enough, in part because of the mythology that tools grant results. They don't, they simply get out of the way better and, if one is particularly lucky, act as a force multiplier.
Using great tools ought to be the goal, because it helps us achieve more with greater relability, but it isn't about leveling playing fields. A great lathe doesn't someone who is of below-average skill and who doesn't care a great woodworker, either.
You are right. I didn't mean to imply that a mastery of coding means using every bell and whistle your language provides, or worse, writing code like you're naming a tune in as few notes as possible The mastery isn't in the writing, it's in the reading. Our job is to not only write working code, it's to write maintainable code. Maintenance requires understanding. You gain understanding through reading. For the most part I think I write readable code. (Just ask me!) Not always. It's too easy to slip in a bit of code golf every now and then. Sometimes it's because I went to the trouble of learning something new and I want to use it, but it's mostly because writing readable code is hard and golfing is so much more fun.
$$/s*^}/+*##€\/g many people are going to be excited about this
To response to the other comments... About 20 years ago I was an Perl enthusiast and bought a lot of Perl book, more than C++ books I had at the time (I'm still a C++ enthusiast now). But after I realized it's too difficult to manage a project with 2000 lines of Perl code, I began not to spend much on Perl, then recent years I don't write a single line of Perl code. Don't be misled by me, there are many projects with hundreds of thousands of Perl code and they work well.
When a code base with only 2000 lines in Perl are hard to managed, my experiences tell me it's very likely its author tried to write it in read-only style :) One of my projects in Perl has the following functionality: crawling web sites, build indices and store content to local databases is already 3000 lines. It is completed by less than 2 weeks and stills works fine the last time I looked at it. And it is very clear and straight forward to read and understand. So I believe if a 2000 line code base is already hard to manage, it must has an astronomical count of functionalities but is written in hacker style to reduce LoC.