With function signatures and state variables added in 5.010, I consider Perl feature-complete and have not really missed anything from it for as long as I've been writing Perl.
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!
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.
One of my criteria for good tools is that they scale well from the smallest possible use case to absolutely massive. Git meets this criterion for example.
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.
> 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.
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].
I’ve had very limited contact with Perl, but for scripting purposes it does seem like the best option, so I intend to sit down to it and learn it better. It looks like a great next step after sed and awk (perl -pe). I love the ability to write terse scripts, reasonable speed for a scripting language and, as you said, backwards-compatibility (such a stark contrast compared to Python).
What is your project? Raku has some cool features and interesting syntax, I took a look at it before the rename, but find myself reaching for Python for basically everything.
While it's not my favorite language. I have to admit that function signatures go a long way towards making perl feel somewhat normal to work with. I have to imagine they are pretty big boons for IDEs.
Backwards compatibility for languages, libraries, environments, compilers etc. etc. is super super important. Without it no language/libraries/.. will be successful long term. Because people will simply switch to more modern offerings instead or not upgrade to newer versions. Making things “deprecated” is really bad. Just don’t. An API is forever. So ack accordingly.
> What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility.
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.
When I was about 20, I went to the local Barnes and Noble to find a book about programming.
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.
That would be "Programming Perl" by Larry Wall. For me too it was the only programming book of that size I was compelled to read cover to cover. Larry is a great writer but maybe that's to be expected from a linguist. If Python is the number cruncher's favourite language Perl (and subsequently Ruby) must be the linguist's favourite. I got into programming after being intrigued by regular expressions in the advanced section of a chapter on Search And Replace in Dreamweaver 3 Bible back in 2000. At the end of the section there was a footnote to Jeffrey Friedl's "Mastering Regular Expressions" which I read cover to cover. Most of the examples were written in Perl as it was the only language with regex support so deeply baked-in so I had to then go to the source - "Programming Perl" by Larry Wall.
I don’t really miss perl. I do miss the period when perlmonks was relevant to me. I haven’t really seen a similar community since. Maybe rose tinted spectacles on my part but i learned some really enlightening algorithms on there specifically in text processing and i recall it being a really warm community.
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 miss perlmonks as well, now that I do mostly python. It was like stack overflow, except discussions were encouraged. It gave you far more understanding than copying a SO answer usually does.
It's not objective, but I find I have more fun in Perl than any other language. The initial jump was steep, but it helped that I already knew some shell. Now I think in references, I can guess what $_ is going to be, I slap in a big, my $val = s/<RE_HERE>/other_thing wherever I want, I could go on!
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.
A few years ago I pulled out Higher Order Perl and started playing with some of the advanced features/techniques available in the language. And it was really fun! I think Perl was the first popular multi-paradigm language.
I've used Perl off and on throughout my career, even working at one job that was pretty much exclusively Perl. I've also used Java and C/C++. I've done a lot of work with embedded systems where C was the order of the day.
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.)
> But back to Perl. I always thought one of the best things about Perl was CPAN.
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.
> nearly always find a module that would accomplish a specific task I needed
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 still use Perl whenever I need to get something complex done quickly. Whether it's the handy command-line switches and features for easier one-liners, or just easier stream text processing, or easier external command execution, or the huge library of modules that often support things Python doesn't, Perl is my "fuck it, I just need to get this done" language.
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.
For me it’s any kind of text processing; especially code generation for some one-off task, like churning out SQL or bash scripts/shell commands. Faster than doing it by hand. __END__ is one of my best friends because I can dump the input data right into the script. On the rare occasion I am irked whatever language I’m working in does not have format/write, which comes from the Fortran tradition iirc.
"Bare bones" seems to be a good thing for Perl. I use Strawberry Perl on Windows and it is orders of magnitude faster than Powershell for processing large files of text strings using regular expressions.
I hope the addition of a "new object-oriented programming framework" won't take away the "bare-bones" speed of the current release.
Don't worry. The Perl community, which I love BTW, has bee fighting over Moose, Mouse, Moo and the inclusion of a Meta Object Protocol in the core since the mid-2000s which, I would argue is partly responsible for its decline. So for Perl OOP will always remain an option unless you count blessed hashrefs.
Perl enabled me to take a business-owner's disorganised national spreadsheet of teachers, locations and contact details and turn it into a web application, freeing him from fielding phone calls all day and boosting conversions over a period of 15 years. Perl's superb regex handling was essential in extracting and gradually refining the data until it was fit to be entered into a database. From that point on Perl, along with PostgreSQL, literally ran the business while generating opportunities for hosting promotions with bigger companies. Those who (m|kn)ock Perl usually haven't spent a significant amount of time using it to add real value to a business.
Maybe I’m missing the point of this piece, but it’s probably because I’m still reeling from the author’s idea that adding “say()” which is “print()” with a newline added, is somehow an improvement to the language.
The point is not about `say` itself (which has been there since Perl 5.10, released on 2007/12/18), it's only an example of how much Perl uses modularity (via `use`) to enable new features while ensuring a) code dependent on a new feature alerts on Perl versions without the feature and b) backward compatibility of new Perl versions with old Perl code.
Compare:
# Perl
use feature 'say'
vs:
# Python
from __future__ import print_function
Which at first blush follow the same principle, except that Python decides that `from __future__` is a vision into upcoming doom, that is a future version of Python for which code that preexists becomes incompatible unless it is ported to the new version.
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.
(yes yes I am aware that with enough effort and trickery you could write code that works on both py2 and py3. I did that a long time ago; it's a pain, and doesn't solve the problem of preexisting code)
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.
But leave it in and there's no parse error. No magic preprocessed comments or fake code trickery like JS (which has a commitment to backwards compatibility as well) has to do[0]:
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)
I'm working in Windows (employer's choice) and need to process some huge data files on the desktop.
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.
When you refer to modern hardware with vectorization, are you saying perl beats software that makes use of vector instructions? If so wow! Afaik perl is a plain old interpreted language with no JIT, what makes it so fast? I had an idea of perl as in the same performance category as Python, Ruby and friends.
Uh,those features are here for almost decade now, some longer IIRC.
But man, just being able to write
use v5.10
have been a blessing when you need to support some legacy infrastructure. Old Python broke after upgrades, Ruby broke, but Perl code keeps on trucking.
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.
Please don't blame bare word file handles on "C heritage"
--
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:
> Perl receives such an unnecessary amount of hate
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!
I don't think it's hate. I think it's more "why would I choose Perl over Python?" Perl has a painful syntax, Python greatly improves on this with easy syntax. I don't want to have to relearn the syntax every time I reach for a scripting tool.
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.
So, this is on the stack overflow blog. And Joel Spolsky famously thinks that to rewrite a codebase from scratch is the "single worst strategic mistake that any software company can make" [1].
I wonder if this is how you end up being a Perl user in 2022.
Eh? He's not wrong. for any serious (in production and actually being used by paying customers) software it _would_ be crazy to rewrite a codebase. I can't think of a compelling reason to.
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.
I'd argue perl's major value is from stability in the sense that what the perl developers write today can be run on the perl available on any machine, new or old. If a lot of perl developers end up use'ing lots of these new features that feeling of compatiblity will go away.
If you need new code you write today to run on 20 year old systems, don't use the newer features. Perl 5.36 is backwards compatible to code written for Perl 5.6 after all. If you need 20 year old code to run on new machines, the same thing occurs - you hand it to a recent Perl 5 and it works. Compare and contrast the last 20 years of PHP or Python.
Probably not the place to ask, but some of you might find this interesting enough to take pity on me.
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.
I spent the last 16 years of my career using Perl for about half of what I wrote.
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.
Looking forward to v7 and intro docs that only use "even more" Modern Perl.
For a bigger push, we should all volunteer on those "Do X in Y" language sites and add Perl examples. Same with Amazon Lambda and other opportunities where pick your language is available.
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.
I'm surprised with the emphasis on new features that such old features were highlighted. The 'say' function was added in 2007. Signatures were added in 2014, though to be fair they didn't stop emitting an "experimental" warning until this latest release.
I skimmed the article looking for a mention of a REPL or a new debugger. Perl is a great language but it lacks these tools. Sometimes I just want to try a couple of lines of Perl code in a REPL, but I cannot. Instead, I need to create a file. Also, when debugging with `perl -d`, I cannot use the Up arrow key to get the previous command. Not a big deal but the coding experience will be significantly improved with those tools.
``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.''
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.
I think that 'perl -d' needs to have Term::Readline to be installed to provide line editing. Otherwise you could use DDD, which provides an ugly but functional GUI to gdb, and perl -d. Or ptkdb which is better IMO ('perl -d ptkdb', requires the module and Tk).
Spent about 4 weeks learning perl at an internship 10 years ago. I believe that is one of the biggest professional mistakes I ever made. There is literally nothing I would recommend doing with perl over python.
I think of Perl as a Python-PHP hybrid. A pragmatic product of its time that will endure, and while I'm grateful for never needing it, I'm glad that it's a solid option still for those who do.
I used to write automation for systems management with an old IBM product called Tivoli.
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.
Sorry, but what? The top features they highlight here are a print statement that adds a new line, a change to the bonkers default of creating some kind of implicit global named variable every time you open a file, representing time as an object (with a strftime function!) and… function signatures?
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!
The `print` statement in perl has always behaved more or less as it does in the "other languages" you describe.
`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.
Ya those were my thoughts exactly, and I used Perl heavily for several years.
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.
>“Perl is still about 20 years behind everyone else”
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.
forgotmypw17|3 years ago
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!
theonething|3 years ago
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.
singingfish|3 years ago
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.
yamtaddle|3 years ago
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].
yakubin|3 years ago
arthurcolle|3 years ago
cogman10|3 years ago
cryptonector|3 years ago
I'll let myself out now.
mbrodersen|3 years ago
duskwuff|3 years ago
cutler|3 years ago
gyulai|3 years ago
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.
ra88it|3 years ago
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.
cutler|3 years ago
barrenko|3 years ago
CraigJPerry|3 years ago
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.
btilly|3 years ago
collyw|3 years ago
HeckFeck|3 years ago
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.
wainstead|3 years ago
shp0ngle|3 years ago
I successfully hide away all my bad perl memories and now it’s coming all back
HankB99|3 years ago
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.)
guilherme-puida|3 years ago
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.
[0]: https://corecursive.com/tdih-cpan/
wainstead|3 years ago
petre|3 years ago
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.
thatwasunusual|3 years ago
CPAN is indeed alive and kicking; https://metacpan.org/
0xbadcafebee|3 years ago
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.
wainstead|3 years ago
LordKano|3 years ago
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.
wistlo|3 years ago
I hope the addition of a "new object-oriented programming framework" won't take away the "bare-bones" speed of the current release.
rurban|3 years ago
cutler|3 years ago
anthk|3 years ago
cutler|3 years ago
JackFr|3 years ago
lloeki|3 years ago
Compare:
vs: Which at first blush follow the same principle, except that Python decides that `from __future__` is a vision into upcoming doom, that is a future version of Python for which code that preexists becomes incompatible unless it is ported to the new version.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".
(yes yes I am aware that with enough effort and trickery you could write code that works on both py2 and py3. I did that a long time ago; it's a pain, and doesn't solve the problem of preexisting code)And not just that, Perl alters its parser behaviour live (and scoped to the module!) so remove `'signatures'` from `use` and you get:
But leave it in and there's no parse error. No magic preprocessed comments or fake code trickery like JS (which has a commitment to backwards compatibility as well) has to do[0]: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...
csdvrx|3 years ago
I write and deploy brand new perl code in 2022 to replace some clunky python and javascript - for real! AMA!
wistlo|3 years ago
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.
avyjit|3 years ago
qsort|3 years ago
clscott|3 years ago
2. Are you hiring?
auraham|3 years ago
xani_|3 years ago
But man, just being able to write
have been a blessing when you need to support some legacy infrastructure. Old Python broke after upgrades, Ruby broke, but Perl code keeps on trucking.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.
ksherlock|3 years ago
--
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;
tyingq|3 years ago
Which then inspired the bad idea of expanding on that?
mikejulietbravo|3 years ago
csdvrx|3 years ago
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!
michaelwww|3 years ago
lmm|3 years ago
ibiza|3 years ago
For scripting anything longer than a command line, I'll take Python.
pmontra|3 years ago
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.
gyulai|3 years ago
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-...
uhtred|3 years ago
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.
superkuh|3 years ago
cestith|3 years ago
SighMagi|3 years ago
calvinmorrison|3 years ago
draxil|3 years ago
use common::sense
Which is also quite nice, giving slightly more opinionated defaults.
robotguy|3 years ago
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?
xyzzy4747|3 years ago
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.
balthigor|3 years ago
flukus|3 years ago
CGI scripts are basically FaaS on your own machines.
cutler|3 years ago
cheaprentalyeti|3 years ago
1024core|3 years ago
cheaprentalyeti|3 years ago
HeckFeck|3 years ago
jlv2|3 years ago
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.
unknown|3 years ago
[deleted]
johnmc408|3 years ago
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.
garfieldnate|3 years ago
auraham|3 years ago
ksherlock|3 years ago
``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.''
darrenf|3 years ago
https://metacpan.org/pod/Devel::REPL https://metacpan.org/pod/Reply
Not to mention the Jupyter kernel: https://metacpan.org/dist/Devel-IPerl
heresie-dabord|3 years ago
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.
unknown|3 years ago
[deleted]
wazoox|3 years ago
fijiaarone|3 years ago
mgraczyk|3 years ago
xani_|3 years ago
Almost all Perl code will
TristanBall|3 years ago
Really?
What were the repercussions of this terrible deed?
alxmdev|3 years ago
hannibalhorn|3 years ago
Spooky23|3 years ago
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.
raggi|3 years ago
publicola1990|3 years ago
unknown|3 years ago
[deleted]
xivzgrev|3 years ago
unknown|3 years ago
[deleted]
tomcam|3 years ago
brazzy|3 years ago
> $time->month # Jan - Dec
> $time->wday # Sun = 1, Sat = 6
> $time->day # Sun - Sat
Seriously?
jasonm23|3 years ago
For everything else, there's anything.
pkrumins|3 years ago
samiam_iam|3 years ago
[deleted]
orf|3 years ago
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!
wwweston|3 years ago
`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.
eduction|3 years ago
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.
shp0ngle|3 years ago
I didn’t know about the function signatures. It’s nice, I guess.
But I don’t want to write perl again anyway.
tyingq|3 years ago
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.
unknown|3 years ago
[deleted]
thesuperbigfrog|3 years ago
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
IncRnd|3 years ago
[1] https://gist.github.com/adulau/939629
unknown|3 years ago
[deleted]
unknown|3 years ago
[deleted]
newaccount2021|3 years ago
[deleted]
Hippieblog|3 years ago
[deleted]
samiam_iam|3 years ago
mansilladev|3 years ago