What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO.
Solo project with ~23K LOC of Perl and counting here. Bless you, Larry Wall and Perl maintainers. Keep it up!
I see what you did there.
Edit: for those downvoting me because they don't understand my comment, it refers to the fact that bless is function of the standard library to associate an object with a class.
If you're downvoting me because you think it's a stupid and off topic comment, that is perfectly valid and acceptable to me.
It was a simple blessing, and perhaps a reference to this interview with Larry.
To me, the language creator's faith is one more reason to use it.
Anyway I manage a 250kline code base written over 20 years which is in surprisingly good shape consider it's age and how many people have touched it. Last time we upgraded the perl for the first time in a decade - going through the addition of many features and major internal changes (e.g. unicode, optimisation) the total number of lines of code we needed to change was at most 50. And very little having to fiddle with underlying cpan libraries.
Back to the point. Throwaway script - perfect candidate. Code capable of running the money pump for a billion dollar company. Also just as fine as any other similarly capable environment, better than some, trickier to manage the team than others.
I don't write much Perl these days and haven't for some time, but it's still what I might reach for if I were tasked with writing something suitable for a scripting language that had to run with ~0 operational or upgrade/maintenance budget for a decade or more in environments I wouldn't necessarily be able to control or influence, or else [bad thing will happen].
Imagine trying to upgrade this to some new syntax...
http://modernperlbooks.com/ is where you can read it for free.
Plenty of examples and exercises.
I think Raku deserves way more attention. Its implementation is suboptimal in many ways and it's improving slowly due to very small core team. With more exposure, more people would come, and hopefully some of them would consider contributing, accelerating the pace of development.
I'll let myself out now.
No, 5.36 stabilised them.
https://perldoc.perl.org/perldelta#Core-Enhancements
> The 5.36 bundle enables the signatures feature. Introduced in Perl version 5.20.0, and modified several times since, the subroutine signatures feature is now no longer considered experimental. It is now considered a stable language feature and no longer prints a warning.
Is that even something they're doing on purpose? Didn't they completely botch their attempt at a new major version?
When Python moved from Python 2 to Python 3, introducing breaking changes, there was enough velocity and acceleration in the Python ecosystem for people to be willing to take the pain.
With Perl it's inertia. So even if the language designers and package maintainers wanted to make breaking changes, they couldn't, because people would just stop updating. All that's left to do is to drag out the process of this ecosystem rotting away.
All I know is that I can depend on my Perl scripts running a year from now, and I cannot do that with Python.
It feels alive and well to me in that sense, while the stability and dependability of Python does seem to rot pretty quickly.
Paint me unconvinced. Python2 is still a thing, 14 years later.
Picked up the O'Reilly Javascript book from around 2000. Had no idea what javascript was, just wanted to learn how to program and trying to pick the most popular language.
$40 later, I got home and started reading! Very confusing, the first half of the book covered the language runtime (I think?) and the second half covered the browser sandbox, and it took me 200 pages to realize that I can't easily read or write to files on my machine with this language. Not what I was hoping for!
Back to Barnes and Noble, another $40 and I came home with the O'Reilly camel book, Beginning Perl I think? Cover to cover read, probably the last time I did that with a programming manual.
Decades have passed, I'm in the same camp as those that prefer Ruby now, but man what a breath of fresh air Perl was back in 2000.
Randall Schwarz used to run a podcast that was a total goldmine. Fond memories of listening to that on the train on the way to work.
I think $_ belongs to a different era, before levelling everything to the lowest common denominator became seen as a good thing. I found the limitations of its rivals less than compelling, and besides JavaScript is arguably more complex than Perl these days.
I successfully hide away all my bad perl memories and now it’s coming all back
But back to Perl. I always thought one of the best things about Perl was CPAN. I could nearly always find a module that would accomplish a specific task I needed and then I was just left to write the glue to implement that function (or functions) for my particular needs. I'm surprised CPAN is not mentioned. I wonder if it is still active. I also wonder about security of CPAN in todays environment. I find stuff like pypi and npm to be pretty scary.
I haven't started anything in Perl in quite some time. All the cool kids are using Python so I've been sharpening my skills with that. (But it's all hobby projects these days.)
I'm a younger developer, so I wasn't around when Perl was super popular. I listened to the Corecursive episode about CPAN [0] and was really impressed. It's a good listen even if you're not that interested in Perl anymore.
Then you didn't have to write PC/SC smartcard code in Perl. Also most of the MQTT clients are crap, only Net::MQTT::Message is useful but then you have to write the network client yourself and if you also need TLS, good luck, the modules doing that have like 200+ failed tests. CPAN is great but if you need anything out of the ordinary you'll probably find modules in a state of disrepair, abandoned in 2010.
I have written MQTT clients in Python and the module support was good. But then I discovered it was easier (for the most part) to use the Mosquitto cli utilities and pipe stuff to/from them. For cases where that was awkward, it was easy enough to write in C and use the PAHO libraries directly.
CPAN is indeed alive and kicking; https://metacpan.org/
I can't wait for the day that programming languages as a concept are obsolete. It feels exactly like hand-tool woodworking. I would love to stop building tables and chairs over and over, instead just buy them from Code IKEA.
Perl is still my go-to language when I need to write something quickly.
I have so many purpose driven utilities that I have written in Perl, that it saves me several man-hours of work every month.
I hope the addition of a "new object-oriented programming framework" won't take away the "bare-bones" speed of the current release.
It's a shame too because as you say the Win32 API stuff works great up until the antivirus kicks you in the nads.
I love Win32 because it's the closest we have to a universal GUI format for software.
Compare:
# Perl
use feature 'say'
# Python
from __future__ import print_function
IOW py2 code doesn't run on py3, barking at you in obscure ways if you try, and py3 code doesn't run on py2, barking at you in obscure ways if you try. (or worse, partially runs and either explodes in mid flight or silently corrupts data).
Whereas Perl code written targeting vX runs on Perl vY as long as Y >= X, and if Y < X then Perl tells you "unsupported feature foo" or "your perl is too old, update to at least X".
$ perl5.18 sig.pl
Feature "signatures" is not supported by Perl 5.18.4 at sig.pl line 1.
BEGIN failed--compilation aborted at sig.pl line 1.
And not just that, Perl alters its parser behaviour live (and scoped to the module!) so remove `'signatures'` from `use` and you get:
$ perl5.30 sig.pl
Malformed prototype for main::my_subroutine: $foo, $bar, $baz = 'fury' at sig.pl line 7.
To invoke strict mode for an entire script, put the exact statement `"use strict";` (or `'use strict';`) before any other statements.
(They had to make it a string in void context instead of a comment because comments are removed by JS obfuscators, but it's essentially a magic comment/preprocessor directive)
[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
At the $dayjob, writing some python assuming late model 3.10.x, and discovering that the API has changed when I have to make sure it works on 3.6.x and 3.7.x.
Nevermind important libraries like pandas changing the API so some functions you 've used for years just disappear.
I've got 30+ year old perl 5, that just works. And is readable. I wish 2 year old python could just work.
I write and deploy brand new perl code in 2022 to replace some clunky python and javascript - for real! AMA!
Perl (Strawberry Perl for Windows) is much faster than native Powershell (or CMD) scripts. A few Perl one-liners and I have 2 GB processed in a couple of minutes.
Big fan of Perl here.
This matches my experience: my task is IO bound, processing tens of GB in a matter of minutes.
> I'm working in Windows (employer's choice)
Work prefers MacOS, Windows is my personal choice :)
Windows 10 and 11 are a pleasure to use: between the Windows Terminal and tools like AutoHotKey, there's no Linux equivalent, even for a commandline geek.
Using Windows (and Perl, and other weird things I like) may not be fashionable, but it's hard to beat.
What I miss it's a "strings(1)" replacement for Perl.
Other languages could do the same, but often they have a few more layers before they start running that C code.
I'd be curious to know if the perl grammar also somehow lends itself to being fairly optimizable for it's interpreter.
IDK. I didn't waste time checking why.
My guess is that due to the much smaller code size, it reaches a sweetpoint where it fits nicely in the L1 or L2 cache.
But it's just a hunch, I couldn't prove it.
while(<STDIN>) {
print $_;
}
Compared to every other scripted languages I've tried, it's always faster - so much that it often rivals compiled code (even with extra optimizations as explained before)
> Is it just all-around faster
Yes - also faster to deploy, and harder to break in deployment due to dependencies rarely evolving. No need to pip install whatever.
Consequently, tracking modules' versions (say in python) and their break in compatibility is a thing of the past. Some may say it's because it's dead. I guess I'm a necrophiliac then, because it makes my life so much easier that I'm loving it :)
2. Are you hiring?
Using the stock install as much as possible.
Since a perl interpreter is available about everywhere, this makes the scripts cross platform very easily too.
> 2. Are you hiring?
Maybe? You have no email in your profile. Can you please send your CV to my nickname at outlook dot com?
But man, just being able to write
use v5.10
In vast majority of cases the code changes were just "well, the new version of lib gives some warnings about deprecation, might as well clean it up a bit". The minority of cases has been Mojolicious breaking stuff again.
--
Some of the improvements were needed because in places Perl’s Unix/C heritage shows through a little more than we’d like it to in the 21st century. One good example of this is bareword filehandles. You’re probably used Perl code to open a file looking like this:
open FH, 'filename.dat' or die;
I agree. We might deny it, because we are geeks, not fashionistas, but there's such a thing as "cool for geeks" like running Rust code on MacOS with some PostgreSQL sprinkled on, and such a thing as "uncool" like running Perl code over Windows and exchanging CSV files.
Personally, IDGAF: I care about what works the best, not what's cool. I care about performance. I care about the code not breaking due to weird compatibility issues. I care about keeping the stack as simple as possible, because what's simple often works better.
If, god forbid, I need something more complicated than CSV, I reach for sqlite --- which, unfortunately, is starting to become the "cool" option, and therefore might get turned into the proverbial hammer that makes all your problems look like nails!
If your system isn't performant, it's shit. Performant is relative to what you're trying to do and how picky your users are, but at some point you're going to be optimizing for milliseconds without question.
Regular expressions are way better in Perl. I increasingly find myself going back to Perl for RE heavy projects because it's so cumbersome in Python by comparison.
I'm still undecided on if Perl needing semicolons everywhere is only 'as bad' or 'worse' than Python forcing you to worry about the exact number of tabs/spaces indenting lines, but I'm leaning toward python being easier in that respect.
Still, when I have to get something done quickly, especially if it's an immediate need I don't see having to worry about later, Perl is what I turn to. Everything in Python becomes a "Project".
That's a matter of opinion. C style languages are a lot easier for me than whitespace significant languages; my editor will go to the matching bracket with ^G, but I can't do that with whitespace to get to the end of a block. The type sigils are a bit tricky to figure out, but if you spend the time to understand it, it makes sense (but that's also a mater of opinion, too).
I use Python and Perl. Some people who like Python want everything to be Python and "hate" anything that isn't Python. It approaches zealotry in some cases.
Perl syntax is expressive and is similar to C, C++, Java, and yes Bash. These are successful languages too despite not being pythonic.
Actually using the language itself is far less painful in Perl than it is in Python.
Every new Dev says the previous code is shite. Odd that the plumber and electrician do it too.
It's as if nobody can produce good work except for $ME at $NOW
It's the fault of the non-programmers who read "Learn Perl in 2 hours and become a millionaire" books, had a massive s*t on a keyboard and started a business with it
For scripting anything longer than a command line, I'll take Python.
I slowly switched from Perl to Ruby for writing my own text processing scripts. A loop with <> is very convenient but I was using Ruby for work (still do among other languages) and Perl for nothing. I was forgetting how to do stuff in Perl.
I wonder if this is how you end up being a Perl user in 2022.
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
For the record, I became a perl user (for fun!) in 2022 because I was attracted to the text processing capabilities, the awesome documentation, the baked in regex handling, the way it's so integrated into unix culture, the fact that it feels like a nice and natural step up from awk or bash when I want to process text files or work with the filesystem, and also the fact that I just find python so boring.
Oh, also Perl is a very powerful command line tool that can be easily piped into on linux. I don't think python or ruby are as powerful in that regard but I could be wrong.
It's wrong when stated as a blanket statement like that. It depends on the particulars of the case.
I've worked in a company that's taken this dictum as gospel and took it to its absurd extreme where refactoring of any kind was forbidden.
I would explain some dark corner of the codebase and everybody would basically agree that it was in bad shape. I would then explain what I wanted to do about it and people would say "Is that a refactor you're suggesting?" in a tone of voice that would be more appropriate when saying "Is it killing babies that you're suggesting?"
As coincidence would have it, that was a Perl shop. So I speak from experience. And that experience has left me somewhat scarred.
Imagine working on a codebase where any mistake you ever make you're just stuck with. And it's not just your mistakes, but other people's as well. And the mistakes just pile up and pile up and start interacting with each other in nasty ways and there's just no way out. I love being a programmer, but there is little in the world that I hate more than having to be a programmer under such circumstances.
What's more is that the financial benefit of not refactoring is a benefit that usually accrues to those who are in power in a company and who don't have to touch the codebase, whereas the psychological cost of not refactoring accrues to those who have no power who are forced by the others to wallow in the muck. -- That's the thing that Spolsky consistently just doesn't get. He consistently represents the one-sided view of someone "in power".
As a programmer under such circumstances, it really makes no sense to throw away your psychological wellbeing so that your company's owners can make more money, just like it doesn't make sense for a miner to give himself lung cancer so that the owners of the mine can make more money.
Conversely: If you're the owner of a software company (or mine, or whatever) you should partially think of refactoring as an employee benefit that will pay for itself through increased productivity. It's a point that's very convincingly made by Tom DeMarco in his book "Peopleware" [1]. Asking your employees to dial down the quality of their output so you can realize cost savings almost never makes sense when you take into account the human side of the economic equation. You'll demotivate them and the losses in productivity will outweigh the cost savings.
[1] https://www.audible.com/pd/Peopleware-Audiobook/B09WDR3P3V?a...
You're only noticing half of the picture.
If you want to write code that'll still run in 20 years, do the same.
use Modern::Perl;
use common::sense
Which is also quite nice, giving slightly more opinionated defaults.
I had an idea years back to build crosswords on the surface of a truncated icosahedron (https://i.imgur.com/qlLl434.jpg) but I had no idea how to find sets of 5-letter words that would mesh like that. A very clever programmer friend of mine whipped something up in Perl over a weekend using hashes. Basically it pre-emptively runs through the dictionary and hashes all wildcard forms of a word back to the original word (l...s->leaks, etc), then at each stage of filling out the puzzle it just grabs the list of words that hash to the current pattern. Say you're looking for something that fits s..p. it would return [stops, swept, soupy] etc, then tries each recursively. If the list is empty, there is no solution at that level so it backs up and tries the next word at the previous level.
I learned enough Perl to be able to make the code able to accept different polyhedra. The program takes quite a while to run on larger models, like say the rhombicosidodecahedron, so I've been looking for ways to speed it up. My background is with assembly and embedded C so I'm sure my implementation of these hash lookups would be slower than Perl's. Are there any other, maybe compiled, languages that have fast hash lookups like this?
Nowadays I have my own startup and my code is a mixture of JavaScript, TypeScript, and Rust.
Rust is good for anything sufficiently complex that you want to run quickly, have a small footprint, and want to be sure it works, while allowing for easy refactoring due to the strong type safety.
JavaScript is good for anything you want to write quickly and the code quality doesn't matter as much (e.g. test scripts). It's also much easier to write than Perl syntax-wise and has great async support (unlike Perl). Also it has a much larger ecosystem of libraries and easy to use in IDEs like VSCode. Obviously JS/TS can also be used in both the frontend and backend which is another big advantage.
TypeScript is sort of in between - if the JS codebase gets too large it should be written in TS instead. This makes the code less "write-only".
Perl and PHP were pretty good solutions as scripting languages until JS added good async/await support, map/filter/reduce, and destructuring syntax in my opinion. JS probably requires the least lines of code to get a program working.
CGI scripts are basically FaaS on your own machines.
And I read the article.
The title makes no sense. The article show anything meaningful as to why Perl has improved and is "not your Grandfather's Perl". Most of what the article talks about has been around for over a decade. If anything, it shows that Perl really still has under it the same old decrepit beast it always been hiding away.
Also a modern OO seems nice, though not sure what is in it. Would also like to see a default async library (maybe POE, but I never used it and find the name a bit strange for a default...but then I like Tokio...) Not my area at all, but an opinionated way of async seems nice.
``As shipped, the only command-line history supplied is a simplistic one that checks for leading exclamation points. However, if you install the Term::ReadKey and Term::ReadLine modules from CPAN (such as Term::ReadLine::Gnu, Term::ReadLine::Perl, ...) you will have full editing capabilities much like those GNU readline(3) provides. Look for these in the modules/by-module/Term directory on CPAN. These do not support normal vi command-line editing, however.''
https://metacpan.org/pod/Devel::REPL https://metacpan.org/pod/Reply
Not to mention the Jupyter kernel: https://metacpan.org/dist/Devel-IPerl
https://github.com/viviparous/preplish
Perl's concise syntax makes working in a REPL a pleasure. Python has a REPL but the design of the language makes it expand both in length (for loops) and in width (tabs).
I am a recent convert to working in a REPL first to test programming ideas.
rlwrap perl -dee
my ($grandchildren) = @_Almost all Perl code will
Really?
What were the repercussions of this terrible deed?
Python's origin was as a teaching language (originally ABC I think?), and thus the simplicity of the syntax. It was kinda cool that Python was around for so long before it took off... I had the O'Reilly Python book way back in the 90s.
Perl's influences were awk, sed, bash, C, Fortran, and Lisp.
It was the best job ever. The systems monitoring tool used ancient Perl4 (this was circa 2001 when Perl4 was like a decade old) and Prolog to handle event management.
> $time->month # Jan - Dec
> $time->wday # Sun = 1, Sat = 6
> $time->day # Sun - Sat
Seriously?
For everything else, there's anything.
I wouldn’t call this as “Perl moving forward”, I’d call this “Perl is still about 20 years behind everyone else”.
Wait until they find out that other languages print statements let you customise the line ending!
`say` removes the need for anyone to write their own "I'm tired of the manual newline ritual" function and provides a standard for where the newline is added. That's a marginal convenience, but given the frequency with which people either do write their own or newline inconsistency gets encountered (or both), it's a reasonable one.
And it's in pieces like this one not because it's a huge thing to crow about, but to illustrate the opt-in nature of incremental changes or sets of changes to perl.
`say` is also about 15 years old, like Time::Piece. The author is not announcing features that are new to the whole world, just new to a certain audience, possibly including the author.
This is also true of the filehandle scoping feature (which is 22 years old). If you find the old bare filehandle scope behavior only notable enough to hurl a drive-by "bonkers" at it then I suppose that's one way of advertising that you haven't spent much time thinking about unix shell utilities and associated features/issues.
Function signatures are slightly younger than typescript, or at least, the most familiar syntax for them; both the old and more recent means are essentially naming a list of arguments.
In general: perl is an opportunity to think about programming languages differently. There's a lot of contexts in which I never use it anymore, but it's rare to find people with substantial insights who casually disparage it.
The number two feature they listed was released more than 22 years ago.
Perl is fine for certain tasks, I have no problem with people who choose to use it, but at a certain point I'd argue it's better to learn a new language than try to use Perl for a new type of task.
I didn’t know about the function signatures. It’s nice, I guess.
But I don’t want to write perl again anyway.
The version of Perl on your favorite Linux distro might be. I think that's the point the article was trying to make...that distros ship VERY old versions of Perl.
Perl 5: I'm not dead!
TIOBE: 'Ere! 'E says 'e's not dead!
Internet: Yes he is.
Perl 5: I'm not!
TIOBE: 'E isn't?
Internet: Well... he will be soon-- he's very ill...
Perl 5: I'm getting better!
Internet: No you're not, you'll be stone dead in a moment.
TIOBE: I can't take 'im off like that! It's against regulations!
Perl 5: I don't want to go off the chart....
Internet: Oh, don't be such a baby.
TIOBE: I can't take 'im off....
Perl 5: I feel fine!
Internet: Well, do us a favor...
TIOBE: I can't!
Internet: Can you hang around a couple of minutes? He won't be long...
TIOBE: No, gotta get to Reddit, they lost nine today.
Internet: Well, when's your next round?
TIOBE: Next year.
Perl 5: I think I'll go for a walk....
Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?
Perl 5: I feel happy! I feel happy!
=====================
You can write Perl in Latin: https://metacpan.org/dist/Lingua-Romana-Perligata/view/lib/L...
or Klingon: https://metacpan.org/pod/Lingua::tlhInganHol::yIghun
or whitespace: https://metacpan.org/pod/Acme::Bleach