The Future of Perl(perl.topicbox.com)
perl.topicbox.com
The Future of Perl
https://perl.topicbox.com/groups/perl-core/T4bad780270b6eec5-Mda5ea1e37bdfe5d7b37f443c/the-future-of-perl
205 comments
> Every day I have to parse some new type of text file and Perl is great for that. Everyone else I work with are also in the same age range and everyone already knows Perl.
You nailed it, but this cuts both ways: as the folks who used to do everything in Perl move out, the language fades. In the last few years I see that new tasks that would be done in perl several years ago are now done in python. I like perl, but I think its best days are over.
You nailed it, but this cuts both ways: as the folks who used to do everything in Perl move out, the language fades. In the last few years I see that new tasks that would be done in perl several years ago are now done in python. I like perl, but I think its best days are over.
I also learned Perl in the 90s. I loved it at the time, as it was so much easier than writing C code to parse a config or do basic text manipulation (was working at an ISP). Hearing about the "future of Perl" feels a bit like pondering the future of VHS tapes. Perl exists, and as far as I'm concerned, it is a finished product. There are countless language options that have come onto the scene since it was in its heyday, and that leaves me wondering what the goals are regarding reinventing or reimagining Perl. Who is the target audience? What is the target problem space, and why can't those issues be tackled within the modern language ecosystem? I'm not knocking the effort or initiative. I'm genuinely curious.
The problem space is string handling, particularly regex use. There is no other language (that I know of, certainly no mainstream language) where regexes are the first class citizen they are in perl. In every other language regex handling varies from a bit of a chore to downright painful, where in perl it is natural.
So when I know I'm writing something which is primarily text regex handling, I definitely reach for perl.
So when I know I'm writing something which is primarily text regex handling, I definitely reach for perl.
What about Ruby?
>The semiconductor industry is held together with thousands of lines of Tcl and Perl code
That's where I learned Perl (along with getting familiar with Linux and Vim). I didn't have to use Tcl, but my team members had to. Based on our experience, we got a one-credit course started on these topics for our dept in college. These days they have moved on to Python though.
That's where I learned Perl (along with getting familiar with Linux and Vim). I didn't have to use Tcl, but my team members had to. Based on our experience, we got a one-credit course started on these topics for our dept in college. These days they have moved on to Python though.
That's going to work right up until you all retire around the same time
There are loads of battle-tested well-working Perl code around, and its cheaper to hire one smart dev who can learn Perl to maintain than to hire a whole team to re-write in a new PL. So no matter what is Perl's future in terms of evolution, or mindshare there will be Perl programmers until the code is retired, and its unlikely to happen anytime soon.
There is regular news about how one COBOL system or the other has become unmaintainable and is causing problems. [1] If your hypothesis would be true this wouldn't be the case, as there would always be enough smart devs to learn COBOL and keep working on them.
[1] example: https://www.bloomberg.com/news/articles/2020-04-13/an-ancien...
[1] example: https://www.bloomberg.com/news/articles/2020-04-13/an-ancien...
> There is regular news about how one COBOL system or the other has become unmaintainable and is causing problems.
Well, yes, but as someone who works in public sector in-house IT, often tangentially around old COBOL systems and has been directly involved in systems replacements for some that had become unmaintainable, I sit on the “familiar” side of the Gell-Mann Amnesia Effect with those stories and recognize that they rely almost entirely on the accounts of people and organizations whose massive institutional failures they cover for.
They aren't unmaintainable because “COBOL”, but because of poor choices is contracting and contracting oversight as they were developed, both initially and with subsequent revisions, which leaves them both poorly architected for change and without useful documentation of functional/behavioral requirements, concrete design, or, really, much of anything else, with key knowledge trapped in individual people’s heads, scattered among business and IT initially, and almost all of which have since moved on, leaving behind a smaller set of people responsible for the system who deal with it through rote, cargo cult practices that they don't understand the reasons for. They'd be unmaintainable if COBOL was a currently-popular language.
If you look at the same institutions, .NET (maybe even .NET Core) apps that are comparatively in infancy, only a handful of years old, are following those COBOL apps rapidly down the same path, and have frequently already become difficult to maintain.
But an old language is a convenient scapegoat for deep and entrenched organizational dysfunction.
Well, yes, but as someone who works in public sector in-house IT, often tangentially around old COBOL systems and has been directly involved in systems replacements for some that had become unmaintainable, I sit on the “familiar” side of the Gell-Mann Amnesia Effect with those stories and recognize that they rely almost entirely on the accounts of people and organizations whose massive institutional failures they cover for.
They aren't unmaintainable because “COBOL”, but because of poor choices is contracting and contracting oversight as they were developed, both initially and with subsequent revisions, which leaves them both poorly architected for change and without useful documentation of functional/behavioral requirements, concrete design, or, really, much of anything else, with key knowledge trapped in individual people’s heads, scattered among business and IT initially, and almost all of which have since moved on, leaving behind a smaller set of people responsible for the system who deal with it through rote, cargo cult practices that they don't understand the reasons for. They'd be unmaintainable if COBOL was a currently-popular language.
If you look at the same institutions, .NET (maybe even .NET Core) apps that are comparatively in infancy, only a handful of years old, are following those COBOL apps rapidly down the same path, and have frequently already become difficult to maintain.
But an old language is a convenient scapegoat for deep and entrenched organizational dysfunction.
I worked with a great perl backend. Some of the best written perl I've seen, but I hate perl. If I never have to touch it again I'll be happy. I'm now working in .net and I love the tooling and how easy it is to use.
It's not just COBOL, it's the whole OS environment -- which, for a lot of these old systems, involves legacy mainframe tech (z/OS) with its own peculiar jargon. Basic concepts like "file", "directory", and "disk drive" have different names, and subtly different relationships, and the closest thing to shell scripting is the notorious JCL, with a syntax derived from assembly language (back when writing applications in assembly was a common thing), and described more than once by the person most responsible for it (Fred Brooks) as "the worst computer programming language ever devised by anybody, anywhere".
Here's a blow-by-blow from someone who was, at the time, dealing with some of these systems as part of the United States Digital Service, and thought she ought to get to know the beast up close. It's not pretty:
https://medium.com/the-technical-archaeologist/hello-world-o...
Here's a blow-by-blow from someone who was, at the time, dealing with some of these systems as part of the United States Digital Service, and thought she ought to get to know the beast up close. It's not pretty:
https://medium.com/the-technical-archaeologist/hello-world-o...
It's a pay problem. I don't mind learning some random COBOL codebase and maintaining it, but clients don't want to pay consulting rates over the long term, for what they view as "maintaining an old system".
Perl is far less exotic than COBOL when compared to modern languages that are still in heavy use. It looks kinda like C or PHP and feels kinda like Python or Ruby. I've never written COBOL but it looks almost as foreign to me as a punchcard.
Understanding the runes of Perl and the difference between a "$" and a "@" etc are a lot more exotic than "ADD A TO B GIVING C." or "IDENTIFICATION DIVISION."
I think it's interesting you compare it to a punchcard, given that the 80 column limits and the fixed width layouts of COBOL (and FORTRAN) are entirely driven by punchcard layout.
I think it's interesting you compare it to a punchcard, given that the 80 column limits and the fixed width layouts of COBOL (and FORTRAN) are entirely driven by punchcard layout.
Yeah maybe a better phrasing is "Perl has more in common with languages still in heavy use" since it also has its own quirks. Interesting about the layout-- admittedly I know very little about COBOL or FORTRAN. I'm just reacting to scans of example code.
> Understanding the runes of Perl and the difference between a "$" and a "@" etc are a lot more exotic than "ADD A TO B GIVING C." or "IDENTIFICATION DIVISION."
I disagree.
"$" is understandable for just about every 2 year old on the planet[1] and understood by just about every developer on the planet, including the majority for whom English is not their first language. ("IDENTIFICATION DIVISION"? Why would you divide your name?)
"@" is understandable for a 6 year old.[2]
Calling such incredibly simple things "runes" and "exotic" is like calling "0" an exotic rune.[2]
[1] "$" is just a visual/audio/semantic/mnemonic/symbol overlaying S for "Single" and I for "Item". According to replicated scientific studies an average English baby demonstrates understanding of this concept at around 22-24 months. I think a conclusion that a 2 year old could understand "$" is reasonable.
[2] "@" is just a visual/audio/semantic/mnemonic/symbol overlaying "at" to indicate indexing, "a" to indicate "array", and "0" to indicate counting starts at zero. According to a 2018 scientific study[3] an average child has come to understand integer counting by the age of around 3 and a half, and is comfortable with counting from "0" at around 5-6 years of age. Perhaps the most challenging aspect is the notion of an "array"; but the whole point of having an "@" is to distinguish it from "$" without getting into details. I think a conclusion that a 6 year old could understand "@" more easily than they could understand addition is reasonable.
I disagree.
"$" is understandable for just about every 2 year old on the planet[1] and understood by just about every developer on the planet, including the majority for whom English is not their first language. ("IDENTIFICATION DIVISION"? Why would you divide your name?)
"@" is understandable for a 6 year old.[2]
Calling such incredibly simple things "runes" and "exotic" is like calling "0" an exotic rune.[2]
[1] "$" is just a visual/audio/semantic/mnemonic/symbol overlaying S for "Single" and I for "Item". According to replicated scientific studies an average English baby demonstrates understanding of this concept at around 22-24 months. I think a conclusion that a 2 year old could understand "$" is reasonable.
[2] "@" is just a visual/audio/semantic/mnemonic/symbol overlaying "at" to indicate indexing, "a" to indicate "array", and "0" to indicate counting starts at zero. According to a 2018 scientific study[3] an average child has come to understand integer counting by the age of around 3 and a half, and is comfortable with counting from "0" at around 5-6 years of age. Perhaps the most challenging aspect is the notion of an "array"; but the whole point of having an "@" is to distinguish it from "$" without getting into details. I think a conclusion that a 6 year old could understand "@" more easily than they could understand addition is reasonable.
I'll take a guess that you didn't grow up in the UNIX shell?
perl syntax is actually highly intuitive because it copies nearly everything from pre-existing tools, shell scripts, sed, awk, and so on. perl just packaged it all into one cohesive tool.
It was one of those languages where you barely need to read the manual because you can predict things because the syntax will be exactly what'd you'd guess it to be.
All this, of course, if and only if you had previously grown up on shell, sed, awk and friends. For anyone who hasn't, I can totally see how perl seems like alien gobbledygook.
perl syntax is actually highly intuitive because it copies nearly everything from pre-existing tools, shell scripts, sed, awk, and so on. perl just packaged it all into one cohesive tool.
It was one of those languages where you barely need to read the manual because you can predict things because the syntax will be exactly what'd you'd guess it to be.
All this, of course, if and only if you had previously grown up on shell, sed, awk and friends. For anyone who hasn't, I can totally see how perl seems like alien gobbledygook.
Yeah, just imagine a part of the Goverment would say "hey we forgot to bring in new peoples and pay them right..sorry", instead of "we did nothing wrong, it's that bad unmaintainable Code-Base and that bad Language named Cobol, and the Mainframe is btw 15 years old" told over Zoom on a Windows10 Machine ;)
Relevant recent post and discussion: Why COBOL isn’t the problem, https://news.ycombinator.com/item?id=26475331
It perfectly supports my hypothesis. Cobol is bloody 60+ old. It was in the category of “oh so old" languages in 80s already, and it took another 40 years to reach the point when its code became too old to support.
> its cheaper to hire one smart dev who can learn Perl to maintain than to hire a whole team to re-write in a new PL.
Short term? Probably.
Long term? Probably not.
At one point your _one_ Perl developer will disappear, and while you held onto that one person, the Perl language has faded even more into oblivion, making it literally _impossible_ for you to hire people to maintain your product.
Short term? Probably.
Long term? Probably not.
At one point your _one_ Perl developer will disappear, and while you held onto that one person, the Perl language has faded even more into oblivion, making it literally _impossible_ for you to hire people to maintain your product.
Yes, but in the long term everything will break, no matter what language one uses. The question is how long is long? I suppose when talking about PLs it's proportional to amount of working code in the wild.
> I suppose when talking about PLs it's proportional to amount of working code in the wild.
It comes down to the number of people that knows, or shows interest in, any given programming language.
You are right that you might need to diverge from your language of choice at one point, even rewrite your whole application (which is scary enough), but you should do that at a point where a different language is "at top", or at least trending towards "the top."
Perl is trending downwards in all statistics,[1][2][3] except maybe statistics that has to do with salaries, because it's hard to find people who can do the job.
This is not a bashing of Perl itself: I love Perl, but I also see where it's failing, which is why I make use of several different programming languages to get a job done, if necessary. At the end of the day, Perl is just another tool in the toolbox, and as a boss you need to employ people that are familiar with the most popular (not necessarily the best, sadly) tools to get the job done.
[1] https://trends.google.com/trends/explore?date=2011-01-01%202...
[2] https://insights.stackoverflow.com/trends?tags=perl
[3] https://www.statista.com/statistics/793628/worldwide-develop...
It comes down to the number of people that knows, or shows interest in, any given programming language.
You are right that you might need to diverge from your language of choice at one point, even rewrite your whole application (which is scary enough), but you should do that at a point where a different language is "at top", or at least trending towards "the top."
Perl is trending downwards in all statistics,[1][2][3] except maybe statistics that has to do with salaries, because it's hard to find people who can do the job.
This is not a bashing of Perl itself: I love Perl, but I also see where it's failing, which is why I make use of several different programming languages to get a job done, if necessary. At the end of the day, Perl is just another tool in the toolbox, and as a boss you need to employ people that are familiar with the most popular (not necessarily the best, sadly) tools to get the job done.
[1] https://trends.google.com/trends/explore?date=2011-01-01%202...
[2] https://insights.stackoverflow.com/trends?tags=perl
[3] https://www.statista.com/statistics/793628/worldwide-develop...
> Long term? Probably not.
If companies are sensible and have learned from past issues, yes. But I live in the real world, so no!
Reference: the COBOL programmers pulled out of retirement en-mass in the late 90s to perform Y2K audits/fixes.
> to maintain your product.
Often with Perl it isn't the end product that is the issue, that is more likely to have been ported to some other language/framework, but instead all that Perl is managing IT and project infrastructure.
If companies are sensible and have learned from past issues, yes. But I live in the real world, so no!
Reference: the COBOL programmers pulled out of retirement en-mass in the late 90s to perform Y2K audits/fixes.
> to maintain your product.
Often with Perl it isn't the end product that is the issue, that is more likely to have been ported to some other language/framework, but instead all that Perl is managing IT and project infrastructure.
>> Long term? Probably not.
> If companies are sensible and have learned from past issues, yes. But I live in the real world, so no!
In my world, more and more companies learns from past issues/failures. They also live in the same world as you do, which sees a decline in both number of Perl programmers and a decline in general usage of the language itself.[1][2][3]
> Reference: the COBOL programmers pulled out of retirement en-mass in the late 90s to perform Y2K audits/fixes.
That was 20 years ago. Plus, it's not a good thing that people are "pulled out of retirement" to fix things.
[1] https://trends.google.com/trends/explore?date=2011-01-01%202...
[2] https://insights.stackoverflow.com/trends?tags=perl
[3] https://www.statista.com/statistics/793628/worldwide-develop...
> If companies are sensible and have learned from past issues, yes. But I live in the real world, so no!
In my world, more and more companies learns from past issues/failures. They also live in the same world as you do, which sees a decline in both number of Perl programmers and a decline in general usage of the language itself.[1][2][3]
> Reference: the COBOL programmers pulled out of retirement en-mass in the late 90s to perform Y2K audits/fixes.
That was 20 years ago. Plus, it's not a good thing that people are "pulled out of retirement" to fix things.
[1] https://trends.google.com/trends/explore?date=2011-01-01%202...
[2] https://insights.stackoverflow.com/trends?tags=perl
[3] https://www.statista.com/statistics/793628/worldwide-develop...
> That was 20 years ago.
Correct. Longer if you count people in the 80s working to fix affected code that caused problems for 20-to-25 year term financial arrangements and so forth. I'm not saying it was recent, just this is a good example and one I don't think many have sufficiently learned from (too many think it was a fuss over nothing, when really it was a fuss to make sure it was nothing).
> Plus, it's not a good thing that people are "pulled out of retirement" to fix things.
I make no claim that it is a good thing. Just that it happened, has happened far more than that one big event, and similar things will continue to happen at different scales.
I could (but for commercial and legal reasons, shouldn't and won't) name specific examples of companies relying on systems written in elderly languages/frameworks, apparently locked to old versions of software components or hardware that they just hope won't break before they finally get budget for something new (which isn't likely to happen for a reasonable definition of "soon" under the circumstances) because finding the right people to fix it would be somewhere between gloriously expensive and actually impossible.
Correct. Longer if you count people in the 80s working to fix affected code that caused problems for 20-to-25 year term financial arrangements and so forth. I'm not saying it was recent, just this is a good example and one I don't think many have sufficiently learned from (too many think it was a fuss over nothing, when really it was a fuss to make sure it was nothing).
> Plus, it's not a good thing that people are "pulled out of retirement" to fix things.
I make no claim that it is a good thing. Just that it happened, has happened far more than that one big event, and similar things will continue to happen at different scales.
I could (but for commercial and legal reasons, shouldn't and won't) name specific examples of companies relying on systems written in elderly languages/frameworks, apparently locked to old versions of software components or hardware that they just hope won't break before they finally get budget for something new (which isn't likely to happen for a reasonable definition of "soon" under the circumstances) because finding the right people to fix it would be somewhere between gloriously expensive and actually impossible.
> In my world, more and more companies learns from past issues/failures.
Welcome to earth! We don't do it that way here.
Welcome to earth! We don't do it that way here.
Not Perl's - or any other programming language's - problem if a company doesn't know how to do their stuff.
And I'm sure some companies spent money rewriting perfectly functioning perl code into something like ruby.
Or, in my experience, node.
(Although it wasn't "perfectly functioning" Perl code but whilst it was an abhorrent mess internally, the actual problems were largely caused by the database parts - awful schema, bad server setups, godawful queries from an insane home-grown ORM, etc., which could all have been fixed in a couple of months.)
(Although it wasn't "perfectly functioning" Perl code but whilst it was an abhorrent mess internally, the actual problems were largely caused by the database parts - awful schema, bad server setups, godawful queries from an insane home-grown ORM, etc., which could all have been fixed in a couple of months.)
Node at least is sexy, and I suspect will continue with large numbers of people writing it.
Ruby however seems to be as esoteric as perl - its not js or python or java in ubiquity, it's not loved like rust and go, it doesn't have the longevity of perl, c and bash. Perl5 has run, pretty much unchanged, for over 20 years, meaning no need to update my programs. Ruby on the other hand is a treadmill language. Code written in 2005 (when rails came out and it was the new hotness) wasn't runnable a mere 10 years later in 2015. I have processes that have longer runtime!*
Time will tell how long Ruby 2 lasts, but I'd wager that perl 5 lasts longer that ruby 2.
I'm interested in stable languages that just work for most of the things I write -- I want something to perform a task and carry on doing it with minimal effort for the next decade or two. I'm not interested in perl 6 or 7 because its a new language, it's competing in a crowded sphere other more recent languages.
Perl5's value is its constantness and ubiquity.
* hyperbole
Ruby however seems to be as esoteric as perl - its not js or python or java in ubiquity, it's not loved like rust and go, it doesn't have the longevity of perl, c and bash. Perl5 has run, pretty much unchanged, for over 20 years, meaning no need to update my programs. Ruby on the other hand is a treadmill language. Code written in 2005 (when rails came out and it was the new hotness) wasn't runnable a mere 10 years later in 2015. I have processes that have longer runtime!*
Time will tell how long Ruby 2 lasts, but I'd wager that perl 5 lasts longer that ruby 2.
I'm interested in stable languages that just work for most of the things I write -- I want something to perform a task and carry on doing it with minimal effort for the next decade or two. I'm not interested in perl 6 or 7 because its a new language, it's competing in a crowded sphere other more recent languages.
Perl5's value is its constantness and ubiquity.
* hyperbole
> Perl5 has run, pretty much unchanged, for over 20 years, meaning no need to update my programs.
One of my CLI tools that lives in $HOME/bin on every machine I touch, is perl code I wrote in 1990. Haven't changed it once since then, just keep copying it everywhere.
One of my CLI tools that lives in $HOME/bin on every machine I touch, is perl code I wrote in 1990. Haven't changed it once since then, just keep copying it everywhere.
The problem is that it's not just learning Perl, it's learning Perl and the monolithic app (or forest of microservices) at the same time; and if that one smart dev doesn't want to keep doing it, you keep repeating that learning curve with all the costs associated with it.
Just around 2038 as people go "what the hell does this perl code do" as the clock rolls over.
It already supports 64 bit ints and relies on time_t and other lower level types. If these work in 2038 so will Perl.
Are you considering moving to Raku or Perl 7 or will it be Perl 5 forever?
I started a new project in Perl a couple of years ago precisely because it has remained stable and without breaking changes for all this time.
It's a feature, not a bug, that the language has remained stable and backwards compatible all this time.
I switched away from PHP (except for a few glue shims) because on several occasions they made changes which broke my shit when the web host I was using upgraded.
I want a language which doesn't cause me extra worry and inconvenience with breakage, I do enough of it already by myself.
I am so grateful for Perl, can't speak of it highly enough. It takes an amazing, WISE community to resist the shimmering temptation of breaking compatibility for so many years.
It's a feature, not a bug, that the language has remained stable and backwards compatible all this time.
I switched away from PHP (except for a few glue shims) because on several occasions they made changes which broke my shit when the web host I was using upgraded.
I want a language which doesn't cause me extra worry and inconvenience with breakage, I do enough of it already by myself.
I am so grateful for Perl, can't speak of it highly enough. It takes an amazing, WISE community to resist the shimmering temptation of breaking compatibility for so many years.
TBH, Perl being frozen in time isn't by design but rather a result of the extremely long (15+ years?) cycle of releasing Perl 6/Raku. In its heyday, Perl used to introduce new features and sigills all the time in dot versions. Also, I don't think Perl can claim the moral high ground on stability when the languages Perl was supposed to replace, such as awk, are POSIX-standardized and have multiple interworking implementations, and Perl even shipped an aggressive awk-to-Perl converter (a2p). As a legacy of Perl, PCREs with capture groups and above-regular language features invading environments and especially web frameworks and JavaScript also are of dubious value because of the attack vectors they bring.
My view:
The first version of PCRE was released in 1997, first Perl that supported PCRE in 2009. Claiming PCRE is "a legacy of Perl" is like saying C is a legacy of C#.
Calling a2p "aggressive" because it did a surprisingly good job converting awk to perl is like saying useful technology is aggressive.
Perl wasn't supposed to replace awk. It was designed to integrate features of C, shell, sed, and awk into one tool. That was spectacularly useful.
Perl is a high point in PL stability, still correctly running most Perl 4 scripts from the last century, with active community support for versions of Perl from 15 years ago. This is despite continuous evolution, eg adding Unicode support, in contrast to POSIX ("printable ASCII characters, space, BEL, backspace, tab, carriage return, newline, vertical tab, form feed, and null").
"Perl used to introduce ... sigills all the time in dot versions." Perl has never introduced a new sigil.
Perl maintains backwards compatibility despite also evolving because it's maintained by smart and conscientious professionals.
The OP discussion of the future is a continuation of that same philosophy.
The first version of PCRE was released in 1997, first Perl that supported PCRE in 2009. Claiming PCRE is "a legacy of Perl" is like saying C is a legacy of C#.
Calling a2p "aggressive" because it did a surprisingly good job converting awk to perl is like saying useful technology is aggressive.
Perl wasn't supposed to replace awk. It was designed to integrate features of C, shell, sed, and awk into one tool. That was spectacularly useful.
Perl is a high point in PL stability, still correctly running most Perl 4 scripts from the last century, with active community support for versions of Perl from 15 years ago. This is despite continuous evolution, eg adding Unicode support, in contrast to POSIX ("printable ASCII characters, space, BEL, backspace, tab, carriage return, newline, vertical tab, form feed, and null").
"Perl used to introduce ... sigills all the time in dot versions." Perl has never introduced a new sigil.
Perl maintains backwards compatibility despite also evolving because it's maintained by smart and conscientious professionals.
The OP discussion of the future is a continuation of that same philosophy.
Fair points... But that's what has happened, and whatever the reasons, I am grateful for the blessings.
Awk and friends are great, but also a bit awkward to write complex applications with, in my non-expert experience.
Awk and friends are great, but also a bit awkward to write complex applications with, in my non-expert experience.
Yeah on a second reading I didn't want to come down on Perl too harshly even though I still have memories of that moment where I had to listen to someone telling me "What, awk? We're doing Perl these days!" plus 3 not-so-pleasant projects over the years where we had to re-implement Perl systems.
OTOH there are a couple of Perl tools that I still use (or whish I'd still be able to use), and I'm grateful those exist and Perl 5 is being maintained: Norman Walsh's SGML DTD documentation generator, the old citeseer code base (infinitely more useful than it's today), Debian's apache a2enmod/a2ensite management tools (that I've partly rewritten in shell) and apt tools. I even wouldn't hesitate to use RequestTracker tools (ticket management over mail) today even though it might not scale all that well.
OTOH there are a couple of Perl tools that I still use (or whish I'd still be able to use), and I'm grateful those exist and Perl 5 is being maintained: Norman Walsh's SGML DTD documentation generator, the old citeseer code base (infinitely more useful than it's today), Debian's apache a2enmod/a2ensite management tools (that I've partly rewritten in shell) and apt tools. I even wouldn't hesitate to use RequestTracker tools (ticket management over mail) today even though it might not scale all that well.
Ruby is a more logical choice, or Elixir, depending on your usage domain. Or maybe Python or Julia if using PDL? Raku is nice but still slow and not there yet. No nice http framework like Mojolicious for one, not enough libraries to get stuff done. Pdf support is still quite lacking in Perl for instance. Good luck churning out a nice looking report for a client.
> Raku is nice but still slow and not there yet.
I agree with that general sentiment in some respects, but:
> No nice http framework like Mojolicious for one
Cro is still in beta but it's nice and popularly used as an equivalent to Mojolicious.[1]
> not enough libraries to get stuff done.
One can write:
That is to say, Raku can use tens of thousands of mature libraries from CPAN.
Stefan Seifert, creator of many of the Inlines, is using Catalyst in Raku in a production setting as part of his "battle hardening" work for the Perl Inline.[2]
(If Cro didn't exist, I daresay some folk would be using Mojolicious in Raku as well.)
> Pdf support is still quite lacking in Perl for instance.
I don't use Perl much these days but I'm surprised you're saying support is lacking. Metacpan lists over 700 PDF packages, so presumably something like a few thousand PDF modules. Are you saying they aren't up to the task of churning out a nice looking report?
In the meantime, David Warring's suite of PDF modules for Raku are highly capable.[3]
And the ability to use modules from other PLs in Raku isn't limited to Perl, even if it's currently smoothest for using Perl libraries, so one can use PDF libraries from, say, Python.
[1] https://cro.services/
[2] https://raku.land/?q=Inline
[3] https://raku.land/?q=pdf
I agree with that general sentiment in some respects, but:
> No nice http framework like Mojolicious for one
Cro is still in beta but it's nice and popularly used as an equivalent to Mojolicious.[1]
> not enough libraries to get stuff done.
One can write:
use Library::Foo:from<Perl5>;
That is to say, Raku can use tens of thousands of mature libraries from CPAN.
Stefan Seifert, creator of many of the Inlines, is using Catalyst in Raku in a production setting as part of his "battle hardening" work for the Perl Inline.[2]
(If Cro didn't exist, I daresay some folk would be using Mojolicious in Raku as well.)
> Pdf support is still quite lacking in Perl for instance.
I don't use Perl much these days but I'm surprised you're saying support is lacking. Metacpan lists over 700 PDF packages, so presumably something like a few thousand PDF modules. Are you saying they aren't up to the task of churning out a nice looking report?
In the meantime, David Warring's suite of PDF modules for Raku are highly capable.[3]
And the ability to use modules from other PLs in Raku isn't limited to Perl, even if it's currently smoothest for using Perl libraries, so one can use PDF libraries from, say, Python.
[1] https://cro.services/
[2] https://raku.land/?q=Inline
[3] https://raku.land/?q=pdf
> slow
Raku performance is decent enough where it has to be, and continues, slowly, to improve. I would be seriously surprised if cpython outperformed it, and python gets used quite a lot in the same domains.
Raku performance is decent enough where it has to be, and continues, slowly, to improve. I would be seriously surprised if cpython outperformed it, and python gets used quite a lot in the same domains.
Perl 5, although I try to write new stuff in python now to help the rest of the team. Still write the occasional webpage in perl -- it ususaly starts off as a one liner with grep, sed, etc, but I refactor into perl if it gets complex, been burnt too many times with simple bash scripts becomes more complicated as times goes on
Wrote a poller last year for a bunch of baudion devices to tell me the current configuration of them, outputting as a csv (for version control) or webpage (for nice formatting).
It's basically configure an array (qw//) of IPs and snmp strings, run some snmpwalks (not gets as the oids can change depending) - if it fails try the second IP, pull out the useful data, mangle it a bit, then output
code like my $locM = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip sysName`; my $locR = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $resip sysName`; and
It does the job, it doesn't rely on external language-specific libraries like Net::SNMP which complicates portability. There no doubt far nicer ways to do it, but my process involves
* Prod device to get original information using things like nmap, curl, snmpwalk, etc
* Mangle retrieved information to infer extra information
* Present information
Perl allows me to get from my prodding to useful output in minimal time, going from initial results from prodduing, to functioning output, in well under an hour.
Python could probably do something similar, but things like
Wrote a poller last year for a bunch of baudion devices to tell me the current configuration of them, outputting as a csv (for version control) or webpage (for nice formatting).
It's basically configure an array (qw//) of IPs and snmp strings, run some snmpwalks (not gets as the oids can change depending) - if it fails try the second IP, pull out the useful data, mangle it a bit, then output
code like my $locM = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip sysName`; my $locR = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $resip sysName`; and
if ($ver =~ /SR1/) {
$eth0 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.2.0`;
$eth1 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.3.0`;
} else {
$eth0 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.5.1.3.0`;
$eth1 = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip .1.3.6.1.4.1.22425.10.5.1.5.1.3.1`;
}
my $cmd = `snmpwalk -r 1 -t 1 -OQnv -v2c -c $snmp $mainip 1.3.6.1.4.1.22425.10.5.3.5.1.$oid_rxip`;
foreach (split(/\n/, $cmd)) {
next unless (/.../);
next if (/0.0.0.0/);
s/[" ]*//g;
$srcs->{$_} = 1;
}
It does the job, it doesn't rely on external language-specific libraries like Net::SNMP which complicates portability. There no doubt far nicer ways to do it, but my process involves
* Prod device to get original information using things like nmap, curl, snmpwalk, etc
* Mangle retrieved information to infer extra information
* Present information
Perl allows me to get from my prodding to useful output in minimal time, going from initial results from prodduing, to functioning output, in well under an hour.
Python could probably do something similar, but things like
/([0-9]*)kbit.*([0-9]*)kbit/;
my $inBit = 1000*$1; my $outBit = 1000*$2;
inBit = 0
outBit = 0
matches = re.match(".*([0-9]*)kbit.*([0-9]*)kbit/, line);
if (matches):
inBit = 1000*(int(matches.groups()[0]))
outBit = 1000*(int(matches.groups()[1]))
> The semiconductor industry is held together with thousands of lines of Tcl and Perl code.
Is that the reason why there's a shortage of new NVidia cards? /s
Is that the reason why there's a shortage of new NVidia cards? /s
There are so many stories from people that used Perl long ago but have since moved on to better languages. My story is the opposite. I tried Perl ages ago and couldn't understand why anyone would use it for anything. A couple years ago I decided to give it a try (it was the best fit for unimportant reasons). What I found was a solid language that was great for working with text, highly performant, a good replacement for Bash, and everything just worked so easily, including CPAN packages.
A few days ago, I returned to modify something I wrote last year. I was surprised at how easy it was to read and understand the code. The $ and @ that folks complain about are pretty handy tools to convey what the variable holds. Though I won't be moving most of my code to Perl, I think it's great for what it was originally intended to do.
A few days ago, I returned to modify something I wrote last year. I was surprised at how easy it was to read and understand the code. The $ and @ that folks complain about are pretty handy tools to convey what the variable holds. Though I won't be moving most of my code to Perl, I think it's great for what it was originally intended to do.
I have the opposite experience to you; I was required to use Perl ages ago and built enough software in it to actually like it. I understand why some people are big Perl lovers.
But of all the programming languages that I know (and it's a long list) Perl is the only one that I can't just jump back into. I've forgotten all the esoteric things about it. Unlike most languages, you can't get far in Perl without knowing those esoteric things.
But of all the programming languages that I know (and it's a long list) Perl is the only one that I can't just jump back into. I've forgotten all the esoteric things about it. Unlike most languages, you can't get far in Perl without knowing those esoteric things.
> people that used Perl long ago but have since moved on to better languages
For tasks where Perl is a good fit I moved to Python, but cannot say that it is better (or worse). It is much more fashionable, which is an advantage on its own though - more people will be able to read code written in Python, there are more libraries which are actively maintained.
Many years ago I used Pascal and now work with software written in C. In my opinion Pascal is much better language than C, but Pascal is mostly the thing of the past and C is still very much alive. Sometimes we have to move to languages which are worse or at best - not much better.
For tasks where Perl is a good fit I moved to Python, but cannot say that it is better (or worse). It is much more fashionable, which is an advantage on its own though - more people will be able to read code written in Python, there are more libraries which are actively maintained.
Many years ago I used Pascal and now work with software written in C. In my opinion Pascal is much better language than C, but Pascal is mostly the thing of the past and C is still very much alive. Sometimes we have to move to languages which are worse or at best - not much better.
Python has safer defaults. If you want lexical scoping, or errors when you make mistakes, you have to ask for it in Perl.
> If you want lexical scoping […], you have to ask for it in Perl.
That's false. Lexical scoping was added in 1994. One cannot ask for it, it's always "on".
> Python has safer defaults.
The parable of the mote and the beam is very opportune here. The Python defaults do not amount to much.
Python has neither strict variables (demo: https://stackoverflow.com/a/34071474) nor lexical scope (demo below). That makes it quite unsafe to program, similar to shell: a simple typo silently causes wrong results instead of being shown as error. The safe features cannot be simply enabled, the usual work-around is to use a programming language that implements these features and compiles down to Python.
----
Demo of lack of lexical scope:
Compare JS (run-time error):
That's false. Lexical scoping was added in 1994. One cannot ask for it, it's always "on".
> Python has safer defaults.
The parable of the mote and the beam is very opportune here. The Python defaults do not amount to much.
Python has neither strict variables (demo: https://stackoverflow.com/a/34071474) nor lexical scope (demo below). That makes it quite unsafe to program, similar to shell: a simple typo silently causes wrong results instead of being shown as error. The safe features cannot be simply enabled, the usual work-around is to use a programming language that implements these features and compiles down to Python.
----
Demo of lack of lexical scope:
$ python3.8 -c 'for i in range(1,4):
print(i)
print(i)'
1
2
3
3
Compare JS (run-time error):
$ node15 -e '[1,2,3].forEach(i => console.log(i)); console.log(i)'
1
2
3
ReferenceError: i is not defined
$ perl -Mv5.32 -E 'for my $i (1..3) { say $i; } say $i;'
Global symbol "$i" requires explicit package name (did you forget to declare "my $i"?) at -e line 1.
Execution of -e aborted due to compilation errors.You’re right that Python only has function scope, not quite lexical scope. But
perl -e '
sub foo { $x = 42 }
foo;
print "\$x is $x\n";
'
If perl had use strict; and -w (warnings enabled) by default so that you had to switch them off if you didn't want them I doubt python would have gained such traction as being "easier" and "more readable." The power of perl would have been better tempered by some responsibility.
I liked perl and kinda miss it sometimes but I guess I'm not too unhappy about moving to python. Python is fine. I am pleased to find out how wrong I was about significant whitespace. Having the shape of the code reflecting its content and meaning is actually a great thing. You can think, this shape looks (un)pleasant before understanding the code in detail. Better yet is never, ever having yet another goddamn argument in a team meeting about python bracing style. Python's success makes it impossible to argue that people won't accept a mandatory indenting policy as part of the semantics of the language anymore. It's an open choice for all future languages to adopt if they deem it worthwhile, not refuse to entertain because "the users will revolt."
With Perl's demise we still wait for the lisp of mass appeal for all perl as a lisp lacked uniform syntax.
I liked perl and kinda miss it sometimes but I guess I'm not too unhappy about moving to python. Python is fine. I am pleased to find out how wrong I was about significant whitespace. Having the shape of the code reflecting its content and meaning is actually a great thing. You can think, this shape looks (un)pleasant before understanding the code in detail. Better yet is never, ever having yet another goddamn argument in a team meeting about python bracing style. Python's success makes it impossible to argue that people won't accept a mandatory indenting policy as part of the semantics of the language anymore. It's an open choice for all future languages to adopt if they deem it worthwhile, not refuse to entertain because "the users will revolt."
With Perl's demise we still wait for the lisp of mass appeal for all perl as a lisp lacked uniform syntax.
Do you use 2 spaces or 4 or 8 to indent?
Leading tabs or spaces?
/s
Leading tabs or spaces?
/s
Yeah I get it, we'll do that about anything. And so I draw myself up my full height, hold up a hand, pause, then say "are you seriously trying to start an argument about python formatting? Seriously? Have you considered accounting as a career move?" And if you do it right it's not taken as malicious, gets a laugh and e move on to something else.
I'm curious if you're trying to highlight the wisdom or dramatic aspect of the Perl initiative that's the subject of the OP.
----
If you're not intending to highlight either of these things, then I suspect you perhaps haven't understood the OP.
Perl has long had features that Perl folk consider better than Python's equivalents -- the issue you raise ('strict' lexical scoping) is an exemplar -- but Perl as it currently is has these features switched off (in the name of backwards compatibility).
The proposal in the OP is that Perl folk will consensually agree on which of 30 years worth of accumulated advances in Perl to switch on by default, and then newbies will automatically get that improved Perl by default.
----
If you're not intending to highlight either of these things, then I suspect you perhaps haven't understood the OP.
Perl has long had features that Perl folk consider better than Python's equivalents -- the issue you raise ('strict' lexical scoping) is an exemplar -- but Perl as it currently is has these features switched off (in the name of backwards compatibility).
The proposal in the OP is that Perl folk will consensually agree on which of 30 years worth of accumulated advances in Perl to switch on by default, and then newbies will automatically get that improved Perl by default.
Perl is great because it makes text processing and CLI tool development really stupid simple. The language was built for that sort of thing.
Perl suffers for the same reason. It's early prioritization of text manipulation makes it not great at general purpose programming.
Perl suffers for the same reason. It's early prioritization of text manipulation makes it not great at general purpose programming.
> It's early prioritization of text manipulation makes it not great at general purpose programming.
Exactly, and that's where I went wrong the first time I looked at Perl. You can tell the language was designed by someone that knew a lot about text manipulation. That means it's really good at solving those problems. Unfortunately I wasn't using it for text manipulation at that time.
Exactly, and that's where I went wrong the first time I looked at Perl. You can tell the language was designed by someone that knew a lot about text manipulation. That means it's really good at solving those problems. Unfortunately I wasn't using it for text manipulation at that time.
The sigils are very useful in a language which doesn't play well with IDEs. They're redundant for something like C# but Perl has always struggled with IDEs and is notoriously resistant to static analysis so even good ones will have gaps. I personally have never enjoyed using one with Perl.
It does get a bit messy with coercion like (%{$hash->{$key}}) but I believe recent versions have made that a little nicer. I'm stuck on a decade old one though.
It does get a bit messy with coercion like (%{$hash->{$key}}) but I believe recent versions have made that a little nicer. I'm stuck on a decade old one though.
Yep, in a newer perl you can say:
$hash->{$key}->%*
> The $ and @ that folks complain about are pretty handy tools to convey what the variable holds.
It doesn't convey much. $scalar or @array, that's all. An array is always an array of scalars. Scalar can be almost anything: any kind of number, a string, a reference (often a reference to... an array or a hash, since you can't have arrays of arrays or array of hashes, only arrays of scalars).
It doesn't convey much. $scalar or @array, that's all. An array is always an array of scalars. Scalar can be almost anything: any kind of number, a string, a reference (often a reference to... an array or a hash, since you can't have arrays of arrays or array of hashes, only arrays of scalars).
> It doesn't convey much. $scalar or @array, that's all.
You're vastly underinformed. It conveys the mode of access. It shows at one glance if the expression is singular or list or pairs.
You're vastly underinformed. It conveys the mode of access. It shows at one glance if the expression is singular or list or pairs.
… of an array … of a hash
the whole @a %h
one particular $a[0] $h{foo}
values slice @a[5,3,7] @h{qw(bar foo quux)}
key/value pairs %a[5,3,7] %h{qw(bar foo quux)}> It doesn't convey much. $scalar or @array, that's all.
It's useful when you have a healthy mix of arrays and scalars scattered throughout your code. Static typing would be better, but $ and @ are better than tracking the information manually.
It's useful when you have a healthy mix of arrays and scalars scattered throughout your code. Static typing would be better, but $ and @ are better than tracking the information manually.
I've got a perl website dating back to 2004 - from before php5 was out - that is still used by hundreds of people a day on an internal system.
Works great, the code is deployed by a deb in the same was as it deployed in 2008.
Since initial creation, had about 10 hours effort to put in a mobile view for an iphone and blackberry in 2008/9, and maybe 5 hours effort to replace the <object> with <video> a couple of years ago. Update the 3 files, roll the new deb, and away we go for the next forseeable, until the userbase finally decides that the multi-man-year all-singing replacement that's some javascript heavy frontend and microservice backend actually lets them do their job better (which it seems isn't the case from the complaints it gets)
Sometimes a tool just works and enables you to get on and do things beneficial to your product.
Works great, the code is deployed by a deb in the same was as it deployed in 2008.
Since initial creation, had about 10 hours effort to put in a mobile view for an iphone and blackberry in 2008/9, and maybe 5 hours effort to replace the <object> with <video> a couple of years ago. Update the 3 files, roll the new deb, and away we go for the next forseeable, until the userbase finally decides that the multi-man-year all-singing replacement that's some javascript heavy frontend and microservice backend actually lets them do their job better (which it seems isn't the case from the complaints it gets)
Sometimes a tool just works and enables you to get on and do things beneficial to your product.
I once loved Perl, it was the first language I learned, but reading through the comments and link I don’t see how you turn it into a modern, well loved and well used language (or even stop the decline) through small improvements but no grand vision, or by stepping away from the past in a meaningful and painful way.
I wish them nothing but success, and sincerely hope their plan works, but I personally didn’t read anything there that made me think “oh wow, I’ll have to give Perl a try again when they deliver on their vision.”
I wish them nothing but success, and sincerely hope their plan works, but I personally didn’t read anything there that made me think “oh wow, I’ll have to give Perl a try again when they deliver on their vision.”
It is already modern. The Perl community has boldly remained committed to compatibility over chasing the shiny and breaking shit, unlike many others (coughphpcough), which is why I chose Perl for a new project a couple years ago.
I don't WANT so-called modernization. I want my program to remain working without having to change. it
I don't WANT so-called modernization. I want my program to remain working without having to change. it
> I want my program to remain working without having to change. it
Can't you bundle the interpreter, possibly stripped down and compiled as a static binary, along with your program?
But yes, strict backward compatibility, while having many downsides, provides a lot of value, too. The trade-off is situation and project dependent, and it's good to have both kinds of platforms: ones solid as a rock and moving slowly, and ones moving fast and breaking things.
Can't you bundle the interpreter, possibly stripped down and compiled as a static binary, along with your program?
But yes, strict backward compatibility, while having many downsides, provides a lot of value, too. The trade-off is situation and project dependent, and it's good to have both kinds of platforms: ones solid as a rock and moving slowly, and ones moving fast and breaking things.
https://metacpan.org/pod/pp https://metacpan.org/pod/staticperl https://metacpan.org/pod/perlcc
But that's the worst way to deploy a program.
But that's the worst way to deploy a program.
This will work for awhile until you stop receiving security updates and have to adapt to breaking changes to do so.
Bundling the interpreter would interfere significantly with being able to download and run from source.
I liked writing Perl a lot, but when it came to reading, let alone fixing, other people's Perl, it was always a bit of a nightmare. That's one of the main reasons I was reasonably happy to move away from it - nobody seemed to heed "Just because you can, doesn't mean you should" mantra. Sure you can write good Perl, and I always did my best in that area, but it was not the reality for most Perl programs out there. CPAN also turned to a bit of a mess at some point, and in general dependency management was non existent, really. Containers could help alleviate this pain now, to an extent. Still, it would need to seriously improve to lay any claims to being able to write modern stuff in Perl.
CPAN is great, but also horrible. There are so many packages that do the same thing, and it was often hard for me to know which to pick. Want OO? Use Moose, or Moo, or Mouse or whatever else. Then hope that the one you picked will continue to be maintained. I resisted moving to Python for a long time, but when I finally did it was a bit refreshing to have more packages built into the language so I didn't have to make so many choices on what 3rd-party libraries to install. Perl will always have a special place in my heart though.
As far as reading code goes, Perl could be particularly messy, but I've seen some very hard to read Python code as well. And Javascript... I still don't get why people want to use it server-side. But all these languages have tooling that helps make sure code is at least formatted correctly, and follows some sort of best practices. I think one of the hardest parts of reading Perl, to me, was that it wasn't always clear what package a particular function or class was imported from.
As far as reading code goes, Perl could be particularly messy, but I've seen some very hard to read Python code as well. And Javascript... I still don't get why people want to use it server-side. But all these languages have tooling that helps make sure code is at least formatted correctly, and follows some sort of best practices. I think one of the hardest parts of reading Perl, to me, was that it wasn't always clear what package a particular function or class was imported from.
> CPAN is great, but also horrible. There are so many packages that do the same thing
IMO, that's a good thing. Imagine having only one choice at any layer in society (to make my example extreme): one type of house, one type of car, one type of computer, on type of OS, one type of file system, one type of programming language etc.
> Want OO? Use Moose, or Moo, or Mouse or whatever else.
This is true; no built-in "proper" OO has been a pain for Perl for a long time. However, I've used to love Mouse (like Moose, but a trillion times faster), and I've never had any problems with it.
There are plans to inject proper OO into Perl, though.[1]
> Then hope that the one you picked will continue to be maintained.
This is my biggest problem. I wish there was a "system" of sorts that let _groups of people_ adopt/take over a Perl module and Just Fix It (tm). Having only one person take over a module/package isn't good enough; there must be more people involved in fixing things.
One good example is Crypt::Curve25519[2] which could/should have been fixed years ago, but because the maintainer is inactive, it won't happen.
And now we're back to where we started: because things doesn't get fixed, people create their own versions of CPAN packages just for the F[ix|uck] of it.
[1] https://dev.to/ovid/bringing-modern-oo-to-perl-51ak
[2] https://metacpan.org/pod/Crypt::Curve25519
IMO, that's a good thing. Imagine having only one choice at any layer in society (to make my example extreme): one type of house, one type of car, one type of computer, on type of OS, one type of file system, one type of programming language etc.
> Want OO? Use Moose, or Moo, or Mouse or whatever else.
This is true; no built-in "proper" OO has been a pain for Perl for a long time. However, I've used to love Mouse (like Moose, but a trillion times faster), and I've never had any problems with it.
There are plans to inject proper OO into Perl, though.[1]
> Then hope that the one you picked will continue to be maintained.
This is my biggest problem. I wish there was a "system" of sorts that let _groups of people_ adopt/take over a Perl module and Just Fix It (tm). Having only one person take over a module/package isn't good enough; there must be more people involved in fixing things.
One good example is Crypt::Curve25519[2] which could/should have been fixed years ago, but because the maintainer is inactive, it won't happen.
And now we're back to where we started: because things doesn't get fixed, people create their own versions of CPAN packages just for the F[ix|uck] of it.
[1] https://dev.to/ovid/bringing-modern-oo-to-perl-51ak
[2] https://metacpan.org/pod/Crypt::Curve25519
There is an adoption process for truly inactive maintainers: http://neilb.org/2013/07/24/adopt-a-module.html - you can also often get somewhere by just asking the current maintainer nicely by email. The timeliness of the process in the event of a non-repsonsive maintainer depends on luck and how much depends on the module. In the end it doesn't matter if a group or a person adopts it - someone still has to decide to do the work.
> There is an adoption process [...]
This is good, but to me it's too tedious. I can't wait a month for something to happen. The solution so far has been to fire up a Pinto server and serve "home-made-patched" versions of modules, which only benefits myself, not the community.
> [...] you can also often get somewhere by just asking the current maintainer nicely by email.
What could be more intrusive than creating a pull request or git issue? An email.
This is good, but to me it's too tedious. I can't wait a month for something to happen. The solution so far has been to fire up a Pinto server and serve "home-made-patched" versions of modules, which only benefits myself, not the community.
> [...] you can also often get somewhere by just asking the current maintainer nicely by email.
What could be more intrusive than creating a pull request or git issue? An email.
Just use Moo or none at all. Moose is to big and slow pulls too many deps for my taste, Mouse involves XS. Perl is messy if your coding is messy. Why server side? Because DBI, Mojolicious and a good glue language for business logic already written in Perl. Would I pick it for something new? Maybe simple scripts or some quick web service or web API access tool or things involving text processing.
I use almost no third-party modules and write largely what I call "PHP style" Perl, so mostly $variable = SomeFunction($someOtherVariable);
I've had no issues with reading my own code, and others are able to follow along as well.
I admit that, because of its poetry-enabling flexibility, in terms of readability and maintainability foot-shooting, Perl is like an AK-47 with a full clip and no safety.
I've had no issues with reading my own code, and others are able to follow along as well.
I admit that, because of its poetry-enabling flexibility, in terms of readability and maintainability foot-shooting, Perl is like an AK-47 with a full clip and no safety.
I wonder if they got burned by Perl 6/Raku. That had tons of new features but took so long to deliver that it became a burden. Anyway, I think you're right: they have to be more proactive than just going for "feature parity with a modern language".
> I wonder if they got burned by Perl 6/Raku.
I have the same feeling. I've been programming Perl since mid 90s, and I was - as many others - hyped when Perl 6 was announced early 2000s. 20 years later, it's just different programming language in my eyes; I won't spend any time on it, because if I need Perl, Perl 5.x will do just fine.
Unfortunately, because of Perl 6/Parrot/Raku, or what the current name is, I think it made many developers get off the Perl train. There are lots of good frameworks for Perl that makes it super-easy to get something up and running really quickly;
I have the same feeling. I've been programming Perl since mid 90s, and I was - as many others - hyped when Perl 6 was announced early 2000s. 20 years later, it's just different programming language in my eyes; I won't spend any time on it, because if I need Perl, Perl 5.x will do just fine.
Unfortunately, because of Perl 6/Parrot/Raku, or what the current name is, I think it made many developers get off the Perl train. There are lots of good frameworks for Perl that makes it super-easy to get something up and running really quickly;
* Mojolicious (and its multitude of plugins, Minion etc.)
* DBIx::Class (not pretty, but still just works)
* Moose/Mouse (for decent OOP)
* JSON::Validator (and friends, for mocking and validating)
Wasn't Perl 6 itself a reaction to the fact that a lot of developers already leaving for PHP in the web space and Python in the "I need something like a shell script, but need/want a real programming language".
As Jon Orwant (supposedly) said in 2000 (quoting from the article you linked):
> we are fucked unless we can come up with something that will excite the community, because everyone's getting bored and going off and doing other things
> we are fucked unless we can come up with something that will excite the community, because everyone's getting bored and going off and doing other things
I honestly don't remember. Nor do I care anymore. :)
Yeah, Perl 6 created a lot of confusion especially inside the Perl 5 community. But, in the end, they figured it all out: Perl 5 lives on and Perl 6 got out of its way by renaming itself to Raku. And, for the record: Raku itself is a gem of a language, I believe. A pretty solid OO system, optional typing, powerful language constructs, stellar Unicode support and somehow it is still staying true to Perl's rather pragmatic and, if I may say so, libertarian approach to software developing. I personally love raku's "grammars" most because they render writing parsers a routine job, it's amazing and no other programming language provides such a feature.
If you're interested I strongly suggest you to check out Brian D Foy's book on Raku: https://www.oreilly.com/library/view/learning-perl-6/9781491....
If you're interested I strongly suggest you to check out Brian D Foy's book on Raku: https://www.oreilly.com/library/view/learning-perl-6/9781491....
How about the reported Perl6 / Raku speed issues? Saying "reported" because I have not done an in-depth study if they exist, just read about it briefly somewhere (and a while ago, may a year or so). If they did/do exist, was/is anything being done about them? Asking because I, for one, found both Perl 5 and 6 interesting, and the language features of both, somewhat unusual and powerful.
Raku is a significantly higher level language than most languages. Which tends to lead to slowness.
Really it's faster in many places than it has any right to.
There is even a level under that, NQP. (simplified example below)
---
It just Rakudo on MoarVM has a bunch of optimizations to remove the needed complexity at some point. Either during compilation, or after it's been running for a while.
So with those optimizations it can sometimes beat other higher level languages. (For some specific uses it may even sometimes meet or exceed the speed of low level languages like C/C++. Mainly for algorithmic reasons.)
More optimizations would always be nice though.
Really it's faster in many places than it has any right to.
@a[1];
postcircumfix:< [ ] >( @a, 1 );
@a.AT-POS( 1 );
There is even a level under that, NQP. (simplified example below)
my $reified := nqp::getattr(@a, List, '$!reified');
my $result := nqp::atpos($reified, $pos);
---
It just Rakudo on MoarVM has a bunch of optimizations to remove the needed complexity at some point. Either during compilation, or after it's been running for a while.
So with those optimizations it can sometimes beat other higher level languages. (For some specific uses it may even sometimes meet or exceed the speed of low level languages like C/C++. Mainly for algorithmic reasons.)
More optimizations would always be nice though.
Interesting. Thanks for the reply. Just saw it now. I get it.
I think Raku is still quite a bit slower. But I am not up-to-date with the latest state. However, this is "just" a matter of optimization of the interpreter over time. It's just that Perl 5's interpreter had a head start of more than 25 years.
Yes, that is possible. Java was dead slow early on (I first used it soon after it came out, and pioneered use of servlets in my
company at the time), but after Sun's management threw millions of dollars and high-end tech people at the problem, it got fast enough for many uses in a few years, what with the Hotspot VM and JIT tech and so on.
Sorry, the millions of dollars was mostly for marketing (which is largely what led to its huge adoption), but at least some of that money would have been used to hire top people like computer science compiler specialist PhDs to work on making it faster. I had read about that at around that time.
Raku outperforms perl5 and cpython on quite a few benchmarks, and has for a couple of years now. Some of the ‘nice’ features have pathological performance, but if it becomes a problem in practice you have recourse.
Hope so. Want to try it out. I bought and read most of the llama and camel books years ago, at Perl v4 or so. Ditto for the Perl Cookbook. (All 3 by O'Reilly. Some of those Cookbooks were very good. Also had the Python and Java Cookbooks.)
Enjoyed them (the Perl books). But didn't get a chance to use Perl in non-trivial real projects.
Enjoyed them (the Perl books). But didn't get a chance to use Perl in non-trivial real projects.
I recommend going to https://raku.org/ and reading up on the language because Raku actually has features “modern languages” do not. E.G. the grammars.
I don't remember anyone paying much attention to perl6 before long after perl had peaked. It was for a while seen as an potential savior for perl but that faded too.
It was more about PHP, Ruby and Python entering the stage and diluting the market for scripting languages by each offering something special that one set of users really wanted weather it be an easier deployment path better standard libraries or a more beginner friendly community.
It was more about PHP, Ruby and Python entering the stage and diluting the market for scripting languages by each offering something special that one set of users really wanted weather it be an easier deployment path better standard libraries or a more beginner friendly community.
There is no "wonder". They did.
I did a fair amount of Perl just over a decade ago but can't really see any situation where I'd reach for it over Ruby now. Ruby has Perl's text manipulation goodness with a saner syntax.
Performance.
Perl was a legit tool in bioinformatics due to its insane text parsing performance. Ruby performance is absolute garbage.
Perl was a legit tool in bioinformatics due to its insane text parsing performance. Ruby performance is absolute garbage.
I learned Perl in the mid 2000s because I was working with a company that took text (and sometimes spreadsheet) dumps of public records data and processed them into a database. The entire ETL pipeline was a set of Perl scripts, and, as far as I know, that system is still running. The Perl iteration was actually the second iteration of that system - the first iteration was a set of C programs and shell scripts that were replaced over time.
The rich ecosystem of tested Perl modules for file formats along with the testing frameworks made coping with change bearable - not enjoyable, but bearable.
The rich ecosystem of tested Perl modules for file formats along with the testing frameworks made coping with change bearable - not enjoyable, but bearable.
Oh man the ecosystem. I still think CPAN set the bar for what a high-quality language ecosystem should look like. npm and rubygems look like amateur hour by comparison.
And ubiquity: there’s a Perl for almost all systems
I still do my NLP preprocessing in perl for this exact reason
Do they have to enter the modern world and compete with the modern languages?
Personally, I’d like them to focus on shell scripting and tool making. (But that’s what I use Perl for, so of course I’d say that)
Personally, I’d like them to focus on shell scripting and tool making. (But that’s what I use Perl for, so of course I’d say that)
Ironically making it more modern may make things like shell scripting easier.
Let's say that Perl gets a real type system, and reflection capabilities.
Then I can see something like this come to exist:
Let's say that Perl gets a real type system, and reflection capabilities.
Then I can see something like this come to exist:
use v7;
use GetOpt::MAIN;
sub MAIN ( str $name, int $count ) {
say $name for 1..$count
}They don’t have to, but it seems to be their stated goal.
I wrote a ton of Perl as well, but that stopped long ago. In the meantime I've learned a number of languages, Python and Ruby included. Maybe what they're doing is enough to slow down the decay in terms of user base. But I'd be shocked if it reversed it either by bringing old Perl users back or getting new ones.
Of course, it could just be that this is an internally focused text. Maybe there's some other document that explains a product vision that says, "Perl will be better at X,Y, and Z for groups A, B, and C"?
Of course, it could just be that this is an internally focused text. Maybe there's some other document that explains a product vision that says, "Perl will be better at X,Y, and Z for groups A, B, and C"?
This document is mostly discussing how they can deliver on a product vision without breaking existing code too badly. The product vision would be a different document of which features to add and why.
Oh, sure. But does that different document exist?
Excellent question. I think a big part of the customer story is eventually getting a standardized object model like Corinna into the core language. I do know a lot of objections to Perl have come from the bare-bones built-in objects and the dozen or so ways to build on those using CPAN modules. Getting signatures in rather than the older function prototypes is another. I don't know that there is a unified vision for what future Perl will be yet, other than something that surprises people coming from other languages a lot less yet remains Perl.
Thanks for the comment. I'd say that sounds like a good start. But making it easier for people to switch to Perl is still different than giving people reasons to switch to Perl.
For example, at my current job we picked Python as our default language because a) it's a solid language, and b) since we're doing exploratory ML work, Python's dominance in the ML and data science worlds means good tools and a strong community. Previously I switched to Ruby because a) it's a solid language, and b) Rails made it really easy to build the sort of web stuff we were building at the time. Or when I was building a mobile app I went with Dart and Flutter because it was the only decent-looking platform that would let me do cross-platform development as a solo developer, and it seemed like Google was serious about making it happen.
So I think Perl has to answer the question: whose problems are we going to solve better than anybody else? From what I've seen over the years, it looks like the answer is "people still using Perl". Which is not a terrible answer; it serves for the COBOL and Fortran communities.
For example, at my current job we picked Python as our default language because a) it's a solid language, and b) since we're doing exploratory ML work, Python's dominance in the ML and data science worlds means good tools and a strong community. Previously I switched to Ruby because a) it's a solid language, and b) Rails made it really easy to build the sort of web stuff we were building at the time. Or when I was building a mobile app I went with Dart and Flutter because it was the only decent-looking platform that would let me do cross-platform development as a solo developer, and it seemed like Google was serious about making it happen.
So I think Perl has to answer the question: whose problems are we going to solve better than anybody else? From what I've seen over the years, it looks like the answer is "people still using Perl". Which is not a terrible answer; it serves for the COBOL and Fortran communities.
Well, Perl is still a solid and improved replacement for sed, awk, and shell. PSGI puts it about on par with other platforms for persistent web apps with Mojolicious, Catalyst, and Dancer all solid frameworks for that.
It's reasonably performant. It has true multithreading with no GIL and handles multi-process programming well too. For several years the regex engine has been iterative except for places like backtracking that pretty much need to still be recursive. It's among the fastest language systems that do reflection and offer true closures and lambdas. It used to be faster than a whole lot of other languages, but lots of other have made more progress on that front. Deprecating some features and being willing to break compatibility will allow more optimizations in the compiler and opcode interpreter.
It does portable deployments really well with perlbrew. Or if you want just an easily deployable app, there's Carton. Strawberry Perl works on Windows pretty identically to how perl works on Linux or BSD. Perl runs fine on Android, although it can be a little memory-heavy for constrained devices.
One of the killer features for me is CPAN and in particular metacpan, cpanm, and CPANTesters. Having the code, docs, star ratings, and a matric of which versions are passing all test on which platform all in one place with a good search engine in front of it is really handy. NPM came a lot later for example and still doesn't have things like version pinning and local re-vendoring worked out.
As for what's going to grab a lot of new developers or lead a lot of established developers away from their current preferred languages, I really don't know. If I was starting today and looking for one primary language that was fast to develop, reasonably fast in production, full-featured as a language, and had great library support I might go with Julia, OCaml, F#, Common Lisp, Ruby, JS/Node, Racket, or Scala Native. Maybe even Pike or Lua (Lua since its FFI is so strong any C library is basically also a Lua library).
I'm someone who's been using Perl as one of my primary languages since the 1990s. It's one of my top 4 or 5 languages, and for whole classes of problems it's what I reach for first - at least for prototyping something out. I really like Raku, which has great performance in spots but is still very slow in parts of the language. That language's killer app so far is parsers, by a long shot. Since I'm still using Perl for many things, a cleaner, faster, less crufty Perl would be a great thing. I also think since most of Perl's strengths are still fairly well known but some of the more arcane things like output formats, tied variables in the core, and the core object syntax being kind of raw and under-opinioned are considered too crufty to overlook that cleaning those up might be enough to grab the attention of people who might be on the fence.
It's reasonably performant. It has true multithreading with no GIL and handles multi-process programming well too. For several years the regex engine has been iterative except for places like backtracking that pretty much need to still be recursive. It's among the fastest language systems that do reflection and offer true closures and lambdas. It used to be faster than a whole lot of other languages, but lots of other have made more progress on that front. Deprecating some features and being willing to break compatibility will allow more optimizations in the compiler and opcode interpreter.
It does portable deployments really well with perlbrew. Or if you want just an easily deployable app, there's Carton. Strawberry Perl works on Windows pretty identically to how perl works on Linux or BSD. Perl runs fine on Android, although it can be a little memory-heavy for constrained devices.
One of the killer features for me is CPAN and in particular metacpan, cpanm, and CPANTesters. Having the code, docs, star ratings, and a matric of which versions are passing all test on which platform all in one place with a good search engine in front of it is really handy. NPM came a lot later for example and still doesn't have things like version pinning and local re-vendoring worked out.
As for what's going to grab a lot of new developers or lead a lot of established developers away from their current preferred languages, I really don't know. If I was starting today and looking for one primary language that was fast to develop, reasonably fast in production, full-featured as a language, and had great library support I might go with Julia, OCaml, F#, Common Lisp, Ruby, JS/Node, Racket, or Scala Native. Maybe even Pike or Lua (Lua since its FFI is so strong any C library is basically also a Lua library).
I'm someone who's been using Perl as one of my primary languages since the 1990s. It's one of my top 4 or 5 languages, and for whole classes of problems it's what I reach for first - at least for prototyping something out. I really like Raku, which has great performance in spots but is still very slow in parts of the language. That language's killer app so far is parsers, by a long shot. Since I'm still using Perl for many things, a cleaner, faster, less crufty Perl would be a great thing. I also think since most of Perl's strengths are still fairly well known but some of the more arcane things like output formats, tied variables in the core, and the core object syntax being kind of raw and under-opinioned are considered too crufty to overlook that cleaning those up might be enough to grab the attention of people who might be on the fence.
maybe https://youtu.be/6wPMh-3qYJM?t=3837 (5:47 - 1:03:52) (meanwhile obsolete)
Off topic, but the best programmers that I've met so far in my career were Perl gurus. They had this super power where they could implement new tools from scratch and they would feel robust as if they were made by an external vendor or an open source project. It was magic to me.
I started using Perl in 2000 to rescue my diploma thesis (which was Java and C). I was working on a piece of software that was to communicate with another system that was the subject of another sister-thesis. The person working on the sister-thesis decided to abandon it. And I could really not demonstrate my work as it couldn't work standalone. In the place of the missing sister-system, I quickly put together something in Perl and was able to salvage the work and deliver my thesis. Compared to Java and C of the day, it felt like magic.
To this day, I have never seen anything that can even remotely approach the ability of Perl to prototype something out of thin air. Usually there is a gap between script-like tools (like sh, sed, awk, grep, jq, curl, etc) with which you can quickly put together stuff and a "real" language which usually needs scaffolding and preparation. Perl can do both, you can write excellent one-liners and you can also write complex software with libraries and frameworks and dependencies and tests.
To this day, I have never seen anything that can even remotely approach the ability of Perl to prototype something out of thin air. Usually there is a gap between script-like tools (like sh, sed, awk, grep, jq, curl, etc) with which you can quickly put together stuff and a "real" language which usually needs scaffolding and preparation. Perl can do both, you can write excellent one-liners and you can also write complex software with libraries and frameworks and dependencies and tests.
Yeah, I started working at a place where 90%+ of the production codebase is actively-maintained Perl, and it honestly feels great.
These guys might have a hard time fitting a recruiter's definition for a "rock star" but they're the best set of colleagues I've had in a very long time, and that's after working at multiple flashy tech companies.
Long live Perl. We can only hope to get another generation of programmers as committed and useful as the people who still write Perl every day.
These guys might have a hard time fitting a recruiter's definition for a "rock star" but they're the best set of colleagues I've had in a very long time, and that's after working at multiple flashy tech companies.
Long live Perl. We can only hope to get another generation of programmers as committed and useful as the people who still write Perl every day.
Btw, my gurus are working at Comcast. I was kind of surprised to see Perl demand in a company as big as Comcast nowadays.
Why wouldn’t the future focus be on Raku at this point? Perl is (was?) a great language, but Raku offers so much more.
Of course Raku has the “expected” things from Perl like classes and all the fantastic regex and string manipulation features.
But Raku brings:
* Optional/gradual typing (and unlike Python, declared types are enforced)
* Pattern matching, where different function definitions can be defined for different input values, like Haskell
* Multiple dispatch, so different function bodies can be defined for different sets of argument types (like pattern matching, but based on types, like Julia)
* Lazily-generated sequences, like Haskell or Clojure
* Lisp-like AST macros
* A built-in syntax for defining grammars and generating parsers
Not to mention junctions, autothreading, hyperoperators (vector operators), asynchronous operations, parallelism, concurrency, and multi-core support. The list goes on and on...
It’s unfortunate that so many programmers I talk to aren’t even willing to consider looking at Raku, even though it has a lot to offer.
But I am confused by this “future” where Perl wants to continue on to v7, v8...
Of course Raku has the “expected” things from Perl like classes and all the fantastic regex and string manipulation features.
But Raku brings:
* Optional/gradual typing (and unlike Python, declared types are enforced)
* Pattern matching, where different function definitions can be defined for different input values, like Haskell
* Multiple dispatch, so different function bodies can be defined for different sets of argument types (like pattern matching, but based on types, like Julia)
* Lazily-generated sequences, like Haskell or Clojure
* Lisp-like AST macros
* A built-in syntax for defining grammars and generating parsers
Not to mention junctions, autothreading, hyperoperators (vector operators), asynchronous operations, parallelism, concurrency, and multi-core support. The list goes on and on...
It’s unfortunate that so many programmers I talk to aren’t even willing to consider looking at Raku, even though it has a lot to offer.
But I am confused by this “future” where Perl wants to continue on to v7, v8...
I'm a little ignorant about Raku, so take my comments with a grain of salt, but...
Saying Raku is the future of Perl is like saying Objective-C is the future of C. Or Ruby is the future of C. Or Python is the future of C. Or C++ or... really most languages out there, because most of them are built on top of or branched from C.
Yet we're all quite capable of recognizing that each as its own place and path and future. They didn't replace C, and Raku didn't replace Perl.
And, of course, Perl built on what came before: C, AWK, shell scripting, sed, BASIC, LISP... and Larry Wall never pretended otherwise.
So I think Raku is a very interesting project, but calling it the future of Perl seems mistaken. Raku is the future of Raku.
Saying Raku is the future of Perl is like saying Objective-C is the future of C. Or Ruby is the future of C. Or Python is the future of C. Or C++ or... really most languages out there, because most of them are built on top of or branched from C.
Yet we're all quite capable of recognizing that each as its own place and path and future. They didn't replace C, and Raku didn't replace Perl.
And, of course, Perl built on what came before: C, AWK, shell scripting, sed, BASIC, LISP... and Larry Wall never pretended otherwise.
So I think Raku is a very interesting project, but calling it the future of Perl seems mistaken. Raku is the future of Raku.
> I'm a little ignorant about Raku, so take my comments with a grain of salt, but...
That makes two of us. Albeit, I began working with Raku in 2015, when it was still called Perl 6. What follows is just my opinion, so take my comments with a grain of salt.
> Saying Raku is the future of Perl is like saying Objective-C is the future of C.
This isn’t true. From the beginning, Perl 6 was always envisioned as the successor language to Perl 5. The reasons given for this were myriad: Perl 5 would benefit from having a more regular syntax (e.g. `$this{}` would become `%this{}`), a decideably parseable implementation [1], first-class OOP support in the standard library, as well as gradual typing and a concurrency/parallelism story, amongst many other things.
Objective-C is more of a bolt-on addition to C. It’s less a separate programming language from C than it is a potentially useful paradigm for programming in C. Objective-C was never designed to “replace C” the way Perl 6 was designed to replace Perl 5.
> and Raku didn't replace Perl.
Well, it should’ve. Other than nostalgia attached to graybearded Perl developers of yore, you can see ITT the writing is on the wall for Perl 5. IMO Perl 5 looks clearly destined to the same fate as Sed and Awk: a CLI “power tool” — critical to infrastructure in unappreciated ways — but ultimately disposable and not a serious solution.
Raku is to Perl 5 what Perl 5 is to Awk, IMO.
In my view, it was deeply unfortunate certain loud minorities from Perl 5 were able to derail Perl 6, as if that would be the thing that could save Perl 5 from its destiny of utter irrelevancy.
[1]: https://news.ycombinator.com/item?id=5770531
That makes two of us. Albeit, I began working with Raku in 2015, when it was still called Perl 6. What follows is just my opinion, so take my comments with a grain of salt.
> Saying Raku is the future of Perl is like saying Objective-C is the future of C.
This isn’t true. From the beginning, Perl 6 was always envisioned as the successor language to Perl 5. The reasons given for this were myriad: Perl 5 would benefit from having a more regular syntax (e.g. `$this{}` would become `%this{}`), a decideably parseable implementation [1], first-class OOP support in the standard library, as well as gradual typing and a concurrency/parallelism story, amongst many other things.
Objective-C is more of a bolt-on addition to C. It’s less a separate programming language from C than it is a potentially useful paradigm for programming in C. Objective-C was never designed to “replace C” the way Perl 6 was designed to replace Perl 5.
> and Raku didn't replace Perl.
Well, it should’ve. Other than nostalgia attached to graybearded Perl developers of yore, you can see ITT the writing is on the wall for Perl 5. IMO Perl 5 looks clearly destined to the same fate as Sed and Awk: a CLI “power tool” — critical to infrastructure in unappreciated ways — but ultimately disposable and not a serious solution.
Raku is to Perl 5 what Perl 5 is to Awk, IMO.
In my view, it was deeply unfortunate certain loud minorities from Perl 5 were able to derail Perl 6, as if that would be the thing that could save Perl 5 from its destiny of utter irrelevancy.
[1]: https://news.ycombinator.com/item?id=5770531
Thanks for the context! There's a lot in here that I didn't know.
That said, I do think that as soon as you rename a branch (example Perl 6 became Raku), it stops being a replacement. It's not even a branch at that point, it a fork. It's a new entity entirely, with all the pros and cons that this entails.
If the goal was to replace Perl, it shoulda stuck with Perl 6 as the name. No?
That said, I do think that as soon as you rename a branch (example Perl 6 became Raku), it stops being a replacement. It's not even a branch at that point, it a fork. It's a new entity entirely, with all the pros and cons that this entails.
If the goal was to replace Perl, it shoulda stuck with Perl 6 as the name. No?
While Raku was envisioned to be the successor to perl... I remember going to the Perl Conference back in '00 and thinking "Oh, Neat!" and being excited about Perl6.
And I waited. And I waited. And I waited.
The mindshare of improving perl5 and making it competitive with the emerging application servers and compelling for a web development platform rather than Java wained.
Java became more and more useful over the next decade while perl5 remained static. People wrote some rather impressive libraries - but the mindshare wasn't there. Mod_perl in apache was useful... but BEA WebLogic was becoming more and more useful.
Meanwhile, more and more features and major changes were slated to be part of perl6... and the release date felt more and more distant in the future for where I could actually get something to work in a production environment with perl6 and say to my manager "this should be what we target for new development."
I had changed two jobs between first getting hired as a perl programmer and perl6 being released (though I pity anyone who would have tried to run perl6 in production in '15).
So while Raku is neat... it really lost its mindshare of developers over two decades.
The writing is on the wall for perl5 - I left that in '10 when I was hired as a Java developer rather than a Perl developer.
But the writing is on the wall for Raku too - already. In '00 and even a few years later, there was still enough inertia to say "perl6 is out, lets move our stack from perl5 to perl6". Today? I don't see it. I think there would be a stronger push from perl5 to Java (or other JVM language) or Python depending on the shop.
The last version of perl4 was in '93 when perl5 started work. Perl 5.000 was released October 17, 1994. 5.004 was in '99... and then the long dark time began as efforts for perl6. Four years later we got perl 5.6... and another five years for perl 5.8. Still no perl6.
Raku won't replace perl5 because any place that perl5 is going to be replaced isn't likely going to move to Raku. The effort to move from perl5 to Raku is likely similar to the effort to move to Java, or Python, or Ruby... all languages with greater mindshare and developer stories (and Jetbrains IDEs).
I've left perl. Any scripting that I do now is groovy which leverages my tooling in Java.
In the "well it should have replaced perl5" - that boat sailed over a decade ago when the systems running perl were being migrated to other platforms and languages... and the developers lost faith, had their beards turn gray, and retired.
And I waited. And I waited. And I waited.
The mindshare of improving perl5 and making it competitive with the emerging application servers and compelling for a web development platform rather than Java wained.
Java became more and more useful over the next decade while perl5 remained static. People wrote some rather impressive libraries - but the mindshare wasn't there. Mod_perl in apache was useful... but BEA WebLogic was becoming more and more useful.
Meanwhile, more and more features and major changes were slated to be part of perl6... and the release date felt more and more distant in the future for where I could actually get something to work in a production environment with perl6 and say to my manager "this should be what we target for new development."
I had changed two jobs between first getting hired as a perl programmer and perl6 being released (though I pity anyone who would have tried to run perl6 in production in '15).
So while Raku is neat... it really lost its mindshare of developers over two decades.
The writing is on the wall for perl5 - I left that in '10 when I was hired as a Java developer rather than a Perl developer.
But the writing is on the wall for Raku too - already. In '00 and even a few years later, there was still enough inertia to say "perl6 is out, lets move our stack from perl5 to perl6". Today? I don't see it. I think there would be a stronger push from perl5 to Java (or other JVM language) or Python depending on the shop.
The last version of perl4 was in '93 when perl5 started work. Perl 5.000 was released October 17, 1994. 5.004 was in '99... and then the long dark time began as efforts for perl6. Four years later we got perl 5.6... and another five years for perl 5.8. Still no perl6.
Raku won't replace perl5 because any place that perl5 is going to be replaced isn't likely going to move to Raku. The effort to move from perl5 to Raku is likely similar to the effort to move to Java, or Python, or Ruby... all languages with greater mindshare and developer stories (and Jetbrains IDEs).
I've left perl. Any scripting that I do now is groovy which leverages my tooling in Java.
In the "well it should have replaced perl5" - that boat sailed over a decade ago when the systems running perl were being migrated to other platforms and languages... and the developers lost faith, had their beards turn gray, and retired.
> The last version of perl4 was in '93 when perl5 started work. Perl 5.000 was released October 17, 1994. 5.004 was in '99... and then the long dark time began as efforts for perl6. Four years later we got perl 5.6... and another five years for perl 5.8. Still no perl6.
Some of your dates are off a bit. 5.004 was in 1997, 5.6 in 2000, 5.8 in 2002, it was only 5.10 that took 5 years after that.
Some of your dates are off a bit. 5.004 was in 1997, 5.6 in 2000, 5.8 in 2002, it was only 5.10 that took 5 years after that.
> And I waited. And I waited. And I waited.
I agree Raku took far, far too long to please those who waited.
I'm sad that atweiden talks of Perl being disposable, especially in a thread about its future, and that they imply Raku is not destined for utter irrelevancy. I love both Perl and Raku, but irrelevancy is where we're all headed in the final analysis.
That said:
> The effort to move from perl5 to Raku is likely similar to the effort to move to Java, or Python, or Ruby...
Fwiw:
* You can use Perl libraries in Raku.[1]
* You can use Perl features in Raku.
* Raku has an excellent Jetbrains IDE.[2]
* It has a rounded out developer story -- ecosystem, OS packaging, compiler releases, mass testing, stackoverflow knowledgebase, sophisticated profilers, debugger, and so on.
[1] https://news.ycombinator.com/item?id=26575153
[2] https://commaide.com/
I agree Raku took far, far too long to please those who waited.
I'm sad that atweiden talks of Perl being disposable, especially in a thread about its future, and that they imply Raku is not destined for utter irrelevancy. I love both Perl and Raku, but irrelevancy is where we're all headed in the final analysis.
That said:
> The effort to move from perl5 to Raku is likely similar to the effort to move to Java, or Python, or Ruby...
Fwiw:
* You can use Perl libraries in Raku.[1]
* You can use Perl features in Raku.
* Raku has an excellent Jetbrains IDE.[2]
* It has a rounded out developer story -- ecosystem, OS packaging, compiler releases, mass testing, stackoverflow knowledgebase, sophisticated profilers, debugger, and so on.
[1] https://news.ycombinator.com/item?id=26575153
[2] https://commaide.com/
Raku regex performance sucks, for one.
Let's parse some data into a hash in Perl:
Let's parse some data into a hash in Perl:
%words = ($input =~ /([^\n\t]+)\t(\N+)/g);
use nqp;
my str $str = $input;
my int $pos = 0;
my int $chars = nqp::chars($str);
while $pos < $chars {
my int $tab = nqp::index($str, "\t", $pos);
my int $nl = nqp::index($str, "\n", $tab);
%words{nqp::p6box_s(nqp::substr($str, $pos, $tab - $pos))} =
nqp::p6box_s(nqp::substr($str, $tab + 1, $nl - $tab - 1));
$pos = $nl + 1;
}
for $input.lines {
my $tab = .index("\t");
%words{.substr(0, $tab)} = .substr($tab + 1);
}
I used Perl for years... Perl missed its transition window.
Randall Schwartz and the community would tell you that “Perl is more popular than ever”, because the rising tide of programmers meant it was used by more people.
The Perl 5 vs Perl 6 created weakness and Python filled the void and won over that segment.
It became the new standard. Now it will be very difficult to dislodge.
Anyway, the entire Perl 6 fiasco will serve as a lesson for future projects.
Randall Schwartz and the community would tell you that “Perl is more popular than ever”, because the rising tide of programmers meant it was used by more people.
The Perl 5 vs Perl 6 created weakness and Python filled the void and won over that segment.
It became the new standard. Now it will be very difficult to dislodge.
Anyway, the entire Perl 6 fiasco will serve as a lesson for future projects.
While confusion around P6 certainly hurt Perl, Python started to conquer over areas previously held by Perl even before that. AFAICT educational establishments didn't like Perl because it embraces expressivity. There's more then one way approach feels good once you grok it, but for the most teachers its anathema - it means you need to explain much more.
Eh, kind of. Perl as a teaching language is obviously terrible, but on the other hand Python outside of academia is basically the DSL to call numpy. I think the problem is, more simply, competition. Now that Perl isn't the only reasonable dynamic language (you have ruby, python, nodejs...), people have more choices, and are ultimately just going to use what they already know as a 'plumbing' language.
Because Raku and Perl5(7,8,9) communities are now two separate worlds and is to be considered two separate languages.
Raku seems like an incredible language which I would learn if I was a capable enough developer to understand the implications of everything it offers.
Raku seems like an incredible language which I would learn if I was a capable enough developer to understand the implications of everything it offers.
Raku is neat language, but it's not Perl. You might as well ask if the future is Python.
Perl v7 as I understand aims still to be fully compatible with Perl 5, and function as a bridge towards v8. This is to attempt smooth gradual transition, something that Raku distinctly does not have.
Perl v7 as I understand aims still to be fully compatible with Perl 5, and function as a bridge towards v8. This is to attempt smooth gradual transition, something that Raku distinctly does not have.
Fwiw Raku does have an attempt at a smooth gradual transition, and in some regards it's a remarkable success.[1]
That said, its approach is profoundly unlike the v7 strategy. My take on v7 is that it boils down to:
* Pulling off such a silky smooth gradual transition that it can continue to be used for /usr/bin/perl without unduly inducing distro and/or user revolt/forking/eoling.
* Setting the stage for a gradual clean up / refresh loosely akin to Python 3 relative to Python 1, but without Python's abrupt incompatibility discontinuities and the consequent decade of contentious and costly transition pain.
[1] https://news.ycombinator.com/item?id=26572531
That said, its approach is profoundly unlike the v7 strategy. My take on v7 is that it boils down to:
* Pulling off such a silky smooth gradual transition that it can continue to be used for /usr/bin/perl without unduly inducing distro and/or user revolt/forking/eoling.
* Setting the stage for a gradual clean up / refresh loosely akin to Python 3 relative to Python 1, but without Python's abrupt incompatibility discontinuities and the consequent decade of contentious and costly transition pain.
[1] https://news.ycombinator.com/item?id=26572531
It wouldn't be much of a future if the large amount of existing Perl code couldn't be utilised.
The original vision for Perl6 included a runtime called Parrot which would have been capable of running both Perl6 and Perl5.
If Parrot had been realised, Perl6(Raku) and Perl5 would have been able to interop similar to how Java and the other JVM languages can.
But without that, Raku and Perl remain incompatible so e.g. the existing large Perl ecosystem can't be leveraged from Raku.
The original vision for Perl6 included a runtime called Parrot which would have been capable of running both Perl6 and Perl5.
If Parrot had been realised, Perl6(Raku) and Perl5 would have been able to interop similar to how Java and the other JVM languages can.
But without that, Raku and Perl remain incompatible so e.g. the existing large Perl ecosystem can't be leveraged from Raku.
> Raku and Perl remain incompatible so e.g. the existing large Perl ecosystem can't be leveraged from Raku.
Au contraire, they remain compatible along the lines shown in this example from a StackOverflow answer[1]:
To be clear, the realization of Larry's original vision is not constrained to interop with Perl. Raku has extraordinary potential, some already realized, for pan-language compatibility via its Inlines[2].
The steady improvement of the exemplar Inline[3] for the last 6 years; its evident maturing; its suitability as a solid blueprint for upgrading all the others; all of this bodes well for being able to use a lot of the world's best existing code from within Raku this decade, with Inline::Python quite plausibly shining in this regard within the next 2-3 years.
[1] https://stackoverflow.com/a/45181464/1077672
[2] https://modules.raku.org/search/?q=inline
[3] https://github.com/niner/Inline-Perl5
Au contraire, they remain compatible along the lines shown in this example from a StackOverflow answer[1]:
use Text::BibTeX::BibFormat:from<Perl5>;
...
@blocks = $entry.format;
To be clear, the realization of Larry's original vision is not constrained to interop with Perl. Raku has extraordinary potential, some already realized, for pan-language compatibility via its Inlines[2].
The steady improvement of the exemplar Inline[3] for the last 6 years; its evident maturing; its suitability as a solid blueprint for upgrading all the others; all of this bodes well for being able to use a lot of the world's best existing code from within Raku this decade, with Inline::Python quite plausibly shining in this regard within the next 2-3 years.
[1] https://stackoverflow.com/a/45181464/1077672
[2] https://modules.raku.org/search/?q=inline
[3] https://github.com/niner/Inline-Perl5
Perl has really fallen out of favor in bioinformatics. I inherited a bunch of Perl scripts that have been running basically for over 10 years. The input data is the same so they keep working. I’m not great at Perl and I do find them hard to read. While I get the goals I’m not super happy to have these scripts end up on the continuous upgrade as the language changes path.
The goals seem good. A language needs users, and fewer and fewer are using it lately. Error messages can be obtuse, the package system while powerful is confusing..
Out cluster upgraded the os a couple years ago. Once you figure out how to a missing Perl library installed everything kept working. (The cpan installation story isn’t easy for a novice). the fact that it hasn’t changed much is kind of nice compared to some other language where a lot of scripts needed a fair amount of touch up when the language had a lot of breaking changes.
The goals seem good. A language needs users, and fewer and fewer are using it lately. Error messages can be obtuse, the package system while powerful is confusing..
Out cluster upgraded the os a couple years ago. Once you figure out how to a missing Perl library installed everything kept working. (The cpan installation story isn’t easy for a novice). the fact that it hasn’t changed much is kind of nice compared to some other language where a lot of scripts needed a fair amount of touch up when the language had a lot of breaking changes.
The same is true in many other data science branches (such as physics). Perl was the perfect glue language in the 90s but then got more and more replaced by python. I think one reason for that is Numpy/Pylab, which makes python a perfect replacement for proprietary Matlab codes. All at once, scientists can write most of their codes in a single language/software ecosystem which also feels relatively close to mathematical notation, at least you can write equations similarly readable as in (modern) Fortran. The perl sigils really got out of fashion.
> compared to some other language where a lot of scripts needed a fair amount of touch up when the language had a lot of breaking changes.
Python, I am looking at you!
Python, I am looking at you!
Similar story here - during my PhD my lab worked mostly in perl & C, but for my purposes R was a better fit. Some years down the line, I grew frustrated & moved to python, where I've been ever since. In my postdoc lab we're mostly leaning R, though a few of us are on python. I suspect newer members will be mostly python.
v8 will actually change defaults
Bad idea, imo. Keep the perl binary backwards-compatible (unless 'use v8' is specified), and add a separate perl8 alias that does so implicitly.
Bad idea, imo. Keep the perl binary backwards-compatible (unless 'use v8' is specified), and add a separate perl8 alias that does so implicitly.
It'd be interesting to see versions specified by their file extension. Perl 6 already set that precedent with the .pl6/.pm6 extensions, and I don't see any substantial downsides aside from maybe some file association inconvenience (but that's pretty trivial to fix). Plain .pl/.pm files can then always be assumed to be Perl 5 code, and to be treated as such.
Didn't think of that, but it could work. If you only provided the perl8 alias, you'd still need to add a use declaration to modules, whereas that could be absorbed into the file extension...
There's no need to set it with a file extension. You can set the #! or put use v8.
Right, but that's extra boilerplate. Granted, it's only one line (two if you do both), but still. Reducing boilerplate is already an explicit goal for v8, so it seems like it's worthwhile to be consistent on that front.
Also, not all Perl files have a shebang, and not all files are invoked in a way that'd make a shebang useful. Modules are the obvious example here.
In any case, nothing precluding all three approaches from being supported in case Perl hackers really prefer a "use v8;" over changing the filename or vice versa.
Also, not all Perl files have a shebang, and not all files are invoked in a way that'd make a shebang useful. Modules are the obvious example here.
In any case, nothing precluding all three approaches from being supported in case Perl hackers really prefer a "use v8;" over changing the filename or vice versa.
No, Perl needs to move forward. v8 would be a sane timeline since that is a year or two away anyway.
Perl deserves credit for being way ahead of the curve: It was a free, widely available, garbage-collected language with good support for strings, during a time when the server-side alternatives were basically (primitive, early) C++ or expensive commercial toolchains. By 1995 it also had CPAN, which was (I believe) the first comprehensive directory of modules available for a language ecosystem.
The combination of garbage collection, good string support, and a huge set of easy-to-use third-party modules made Perl insanely productive relative to the other options at the time. Remember - Python didn't release a 1.0 until 1994, and Java 1.0 didn't come out until 1996, and the early versions of those languages were missing a lot of features you'd recognize today, and still had plenty of bugs and performance issues to work out. By 1994 Perl had been out for >6 years, and reached version 5.0 that year. In both capabilities and maturity, it was ahead of the other free alternatives, and way ahead of trying to wrestle with string templating in C or C++. Perl enabled a ton of cool things to be built much more quickly than they would have with the other tools available at the time.
At the same time, it's hard to see a viable niche for Perl going forward. The advantages I mentioned above are no longer unique to Perl - they're now table stakes for any mainstream language. Every mainstream language has a package archive now. There are at least 7 mainstream general-purpose languages with a garbage-collecting runtime, with quality ranging from decent to incredible. Every language except C evolved decent support for string manipulation. Perl deserves tremendous credit for leading the way in making these things mainstream, but it has left Perl with very few distinguishing advantages.
Without those advantages, Perl seems destined to gradually fade away. The sheer mass of existing code means it will probably never be gone - there will always be important systems still running on Perl. But very few greenfield projects will use it, and fewer programmers will learn it in the future.
We can quibble about why Perl has gradually faded from relevance. Personally, I think people generally overweight the importance of the Perl 6 announcement, and underweight the impact of Apache's mod_php in shifting usage away from Perl. mod_php enabled hosting providers to safely enable PHP on shared hosting, while mod_perl couldn't be used in that context, because users could affect the Perl environments of other users on the same system. As a result, PHP hosting was cheap and had tons of options, while Perl hosting required a more expensive option like VPS or a dedicated box. This kick-started the PHP ecosystem, and its growth came largely at the expense of the Perl web development ecosystem. One could imagine an alternative world in which PHP never took off, and Facebook, Wikipedia, Wordpress, etc. were all started in Perl, but that's not the world we live in.
The combination of garbage collection, good string support, and a huge set of easy-to-use third-party modules made Perl insanely productive relative to the other options at the time. Remember - Python didn't release a 1.0 until 1994, and Java 1.0 didn't come out until 1996, and the early versions of those languages were missing a lot of features you'd recognize today, and still had plenty of bugs and performance issues to work out. By 1994 Perl had been out for >6 years, and reached version 5.0 that year. In both capabilities and maturity, it was ahead of the other free alternatives, and way ahead of trying to wrestle with string templating in C or C++. Perl enabled a ton of cool things to be built much more quickly than they would have with the other tools available at the time.
At the same time, it's hard to see a viable niche for Perl going forward. The advantages I mentioned above are no longer unique to Perl - they're now table stakes for any mainstream language. Every mainstream language has a package archive now. There are at least 7 mainstream general-purpose languages with a garbage-collecting runtime, with quality ranging from decent to incredible. Every language except C evolved decent support for string manipulation. Perl deserves tremendous credit for leading the way in making these things mainstream, but it has left Perl with very few distinguishing advantages.
Without those advantages, Perl seems destined to gradually fade away. The sheer mass of existing code means it will probably never be gone - there will always be important systems still running on Perl. But very few greenfield projects will use it, and fewer programmers will learn it in the future.
We can quibble about why Perl has gradually faded from relevance. Personally, I think people generally overweight the importance of the Perl 6 announcement, and underweight the impact of Apache's mod_php in shifting usage away from Perl. mod_php enabled hosting providers to safely enable PHP on shared hosting, while mod_perl couldn't be used in that context, because users could affect the Perl environments of other users on the same system. As a result, PHP hosting was cheap and had tons of options, while Perl hosting required a more expensive option like VPS or a dedicated box. This kick-started the PHP ecosystem, and its growth came largely at the expense of the Perl web development ecosystem. One could imagine an alternative world in which PHP never took off, and Facebook, Wikipedia, Wordpress, etc. were all started in Perl, but that's not the world we live in.
CPAN was (at best) the second because it was based on CTAN, the Comprehensive TeX Archive Network: https://en.wikipedia.org/wiki/CTAN
Also mod_php was more akin to FastCGI with the limited access it gave PHP to the Apache request cycle. While mod_perl allowed you to effectively override any stage of the Apache request cycle with custom code. With mod_perl2 this was pushed to the point where I believe the Apache Foundation was running Apache for their SMTP servers running custom Perl protocol handlers.
Also mod_php was more akin to FastCGI with the limited access it gave PHP to the Apache request cycle. While mod_perl allowed you to effectively override any stage of the Apache request cycle with custom code. With mod_perl2 this was pushed to the point where I believe the Apache Foundation was running Apache for their SMTP servers running custom Perl protocol handlers.
I didn’t count CTAN because Tex isn’t a general-purpose programming language, and so wasn’t competing for the same use-cases.
FastCGI wasn’t available for Apache until ~2004, so having something “akin to FastCGI” was actually a significant advantage until then. mod_perl was strictly more powerful, but that power made it inappropriate for use in a shared hosting environment, which limited Perl’s addressable market.
FastCGI wasn’t available for Apache until ~2004, so having something “akin to FastCGI” was actually a significant advantage until then. mod_perl was strictly more powerful, but that power made it inappropriate for use in a shared hosting environment, which limited Perl’s addressable market.
> Personally, I think people generally overweight the importance of the Perl 6 announcement, and underweight the impact of Apache's mod_php in shifting usage away from Perl.
I'll agree with this... conditional. The overweight of the importance of the Perl 6 announcement also had a change in the release cadence of perl5.
Prior to the perl 6 announcement, there was a release of perl 5 every year - sometimes multiple releases in a year.
With the announcement of perl 6 in July of 2000 - there wasn't another release until 2002... and then the next in 2007... and then the next in 2010.
That decade of stagnation when everyone was waiting for perl 6 shouldn't be underweighed either.
This also coincided with the rise of php and Java with application servers during which there wasn't any significant of perl in a web serving environment. And while there were web application frameworks for Perl (Catalyst in '05, Mojolicious in '08, Dancer in '09)... that was too little, too late.
And the web has become the dominant story for how applications run - not scripts.
Perl lost development mindshare at a time when the "how things work" was undergoing a major shift. Raku remains a language designed for scripts rather than delivering data to other systems. The rise of Docker for serving may give Raku some reprieve - but so much effort has already been focused elsewhere. I don't see Raku with Cro being a compelling alternative for a new developer over Spring Boot or NodeJS.
I'll agree with this... conditional. The overweight of the importance of the Perl 6 announcement also had a change in the release cadence of perl5.
Prior to the perl 6 announcement, there was a release of perl 5 every year - sometimes multiple releases in a year.
With the announcement of perl 6 in July of 2000 - there wasn't another release until 2002... and then the next in 2007... and then the next in 2010.
That decade of stagnation when everyone was waiting for perl 6 shouldn't be underweighed either.
This also coincided with the rise of php and Java with application servers during which there wasn't any significant of perl in a web serving environment. And while there were web application frameworks for Perl (Catalyst in '05, Mojolicious in '08, Dancer in '09)... that was too little, too late.
And the web has become the dominant story for how applications run - not scripts.
Perl lost development mindshare at a time when the "how things work" was undergoing a major shift. Raku remains a language designed for scripts rather than delivering data to other systems. The rise of Docker for serving may give Raku some reprieve - but so much effort has already been focused elsewhere. I don't see Raku with Cro being a compelling alternative for a new developer over Spring Boot or NodeJS.
This is a good "patch the holes" plan, but I think it needs to be followed up in short order by some deeper thinking. And some very painfully honest thinking.
Paul Graham, whom some of you may have heard of, once wrote an essay about "What Languages Fix": http://paulgraham.com/fix.html
I think of it a bit differently, which is that languages have a thesis. (Not quite the same but a lot of overlap.) Paul writes that what Perl fixes is "Shell scripts/awk/sed are not enough like programming languages." I would personally rephrase it to something like "There isn't(/wasn't) a language dedicated enough to Getting It Done."
If you put yourself in the context of the time, this was absolutely true. Most languages for getting things done involved a lot of drama and boilerplate. Popular languages of the day would require you to implement your own hash table for a quick script, if you didn't have one on hand. Libraries for that existed of course, but the Internet wasn't really up and running the way it is now yet, and things were hard to find. Perl came in and provided a great Get It Done languages.
However, landscapes evolve over time and so do language theses. C++ is a great example of something that has changed, going from "C should have great support for object orientation" to something more like "C++ should be the choice for programmers who want zero-cost abstractions". Part of the reason for that change is that the former thesis is no longer a compelling one, on the grounds that "great object orientation support" is now simply table stakes for that sort of language. C++ could not drive forward on that thesis in 2021.
That is also Perl's real problem right now. It lacks a thesis. It has very narrow advantages in text munging still, but for almost anything else, I now have an abundance of languages that "get it done" just as well or better. For context, I've got about 15 years of Perl being my primary language under my belt, so that means something; it's not a secondary or tertiary language for me, and I still have plenty of choices to reach for. (Heck, I've even come to prefer Go for JSON munging quite a lot of the time, because with the right tooling it's really easy to parse JSON straight into objects that I can call methods on meaningfully, which is actually more convenient and useful to me than presenting me with a generic hashtable/array representation that I then have to write a lot of code to crawl over from the "outside".) The world has moved on, and Perl's problem isn't necessarily that it lost but that it won. It has successfully convinced the world that Getting It Done doesn't need to come with all the drama and paperwork and complexity of its late 1990s peers. But that means that just like C++ won and it couldn't continue operating on its "good OO" thesis, Perl needs a new thesis.
Moreover, it's going to have to be brutally honest in the selection of that thesis, because a lot of the obvious ones are already covered by Python, and trying to chase Python on its own turf is going to be a losing game. Perl 6/Raku also has its own thesis, which is now also essentially unavailable to Perl 5. Unfortunately, choosing a thesis successfully isn't necessarily about what the Perl team "wants" so much as where there is space in the programming language market, and in the intervening, gosh, decade or so that Perl 5 has been floating along without a thesis, a lot of the easy or obvious answers have been fairly well covered by other languages.
One thesis option is "Old perl code should degrade gracefully", which is the "declare victory and walk off into the sunset" option. To be honest, it's one that should be seriously considered. I think graceful retirement is a test a lot of language committees fail. Here I'd look for improved refactoring tools to help automatically translate old code into better code to modern standards and other such things being the standard, for instance.
But if the Perl 5/7 team wants a different thesis, it's something I think they need to decide consciously. I don't have a suggestion. But I can offer this word of hope; the space of possible theses is really quite large. The point of view where it looks like every possible language exists already is a point of view that is too narrowly stuck in the details of today. With just a bit of change in perspective, there's a lot of untapped fields.
Tempering that hope a bit, Perl's new thesis really needs to be something that Perl's existing code and community brings something powerful to. If you come up with a possible thesis, but look at it honestly and say "That's probably something better done with a brand new language entirely", it's probably not a functional thesis for Perl. And this does cut the space back somewhat. But some persistent thought may still find something interesting.
Personally, I'd also be looking carefully and honestly at what Perl is still doing and consider shedding old use cases/theses. For example, while Python is not experiencing a popularity crisis, consider a hypothetical world in which the only people still using Python were basically NumPy users. It would be a valid choice to move forward with Python development in a way that privileged such use, at the expense of "general purpose" use going forward. I'm not involved enough with Perl to know what that would be, just offering a meta-option to consider.
And let me close on what I opened with... this is a good "patch the holes" plan that should be all means moved forward with, to give space to breathe. I'm positive on the plan, not critical of it.
Paul Graham, whom some of you may have heard of, once wrote an essay about "What Languages Fix": http://paulgraham.com/fix.html
I think of it a bit differently, which is that languages have a thesis. (Not quite the same but a lot of overlap.) Paul writes that what Perl fixes is "Shell scripts/awk/sed are not enough like programming languages." I would personally rephrase it to something like "There isn't(/wasn't) a language dedicated enough to Getting It Done."
If you put yourself in the context of the time, this was absolutely true. Most languages for getting things done involved a lot of drama and boilerplate. Popular languages of the day would require you to implement your own hash table for a quick script, if you didn't have one on hand. Libraries for that existed of course, but the Internet wasn't really up and running the way it is now yet, and things were hard to find. Perl came in and provided a great Get It Done languages.
However, landscapes evolve over time and so do language theses. C++ is a great example of something that has changed, going from "C should have great support for object orientation" to something more like "C++ should be the choice for programmers who want zero-cost abstractions". Part of the reason for that change is that the former thesis is no longer a compelling one, on the grounds that "great object orientation support" is now simply table stakes for that sort of language. C++ could not drive forward on that thesis in 2021.
That is also Perl's real problem right now. It lacks a thesis. It has very narrow advantages in text munging still, but for almost anything else, I now have an abundance of languages that "get it done" just as well or better. For context, I've got about 15 years of Perl being my primary language under my belt, so that means something; it's not a secondary or tertiary language for me, and I still have plenty of choices to reach for. (Heck, I've even come to prefer Go for JSON munging quite a lot of the time, because with the right tooling it's really easy to parse JSON straight into objects that I can call methods on meaningfully, which is actually more convenient and useful to me than presenting me with a generic hashtable/array representation that I then have to write a lot of code to crawl over from the "outside".) The world has moved on, and Perl's problem isn't necessarily that it lost but that it won. It has successfully convinced the world that Getting It Done doesn't need to come with all the drama and paperwork and complexity of its late 1990s peers. But that means that just like C++ won and it couldn't continue operating on its "good OO" thesis, Perl needs a new thesis.
Moreover, it's going to have to be brutally honest in the selection of that thesis, because a lot of the obvious ones are already covered by Python, and trying to chase Python on its own turf is going to be a losing game. Perl 6/Raku also has its own thesis, which is now also essentially unavailable to Perl 5. Unfortunately, choosing a thesis successfully isn't necessarily about what the Perl team "wants" so much as where there is space in the programming language market, and in the intervening, gosh, decade or so that Perl 5 has been floating along without a thesis, a lot of the easy or obvious answers have been fairly well covered by other languages.
One thesis option is "Old perl code should degrade gracefully", which is the "declare victory and walk off into the sunset" option. To be honest, it's one that should be seriously considered. I think graceful retirement is a test a lot of language committees fail. Here I'd look for improved refactoring tools to help automatically translate old code into better code to modern standards and other such things being the standard, for instance.
But if the Perl 5/7 team wants a different thesis, it's something I think they need to decide consciously. I don't have a suggestion. But I can offer this word of hope; the space of possible theses is really quite large. The point of view where it looks like every possible language exists already is a point of view that is too narrowly stuck in the details of today. With just a bit of change in perspective, there's a lot of untapped fields.
Tempering that hope a bit, Perl's new thesis really needs to be something that Perl's existing code and community brings something powerful to. If you come up with a possible thesis, but look at it honestly and say "That's probably something better done with a brand new language entirely", it's probably not a functional thesis for Perl. And this does cut the space back somewhat. But some persistent thought may still find something interesting.
Personally, I'd also be looking carefully and honestly at what Perl is still doing and consider shedding old use cases/theses. For example, while Python is not experiencing a popularity crisis, consider a hypothetical world in which the only people still using Python were basically NumPy users. It would be a valid choice to move forward with Python development in a way that privileged such use, at the expense of "general purpose" use going forward. I'm not involved enough with Perl to know what that would be, just offering a meta-option to consider.
And let me close on what I opened with... this is a good "patch the holes" plan that should be all means moved forward with, to give space to breathe. I'm positive on the plan, not critical of it.
I actually find Go harder to work with JSON with for exactly those same reasons. With Go if I want to parse JSON into something I can call methods on, the JSON has to conform to something I can build a struct around. If the JSON is complicated in anyway that doesn't line up with Go's sense of structs I'm forced to drop to map[string]interface{} (or something like it). With Perl I can parse into the hashref equivalent of map[string]interface{} and still be able to bless it and call methods on it.
This isn't to say that Perl is better or Go is better, they just have different affordances. Perl is designed for loosely structured data and that causes all kinds of problems when you want to enforce highly structured data. Go is designed to handle strictly structured data and the ramp down is hard when you don't have that.
This isn't to say that Perl is better or Go is better, they just have different affordances. Perl is designed for loosely structured data and that causes all kinds of problems when you want to enforce highly structured data. Go is designed to handle strictly structured data and the ramp down is hard when you don't have that.
You are asking for a "thesis", for a unique proposition.
Well, maybe Perl 5's backwards-compatibility can be marketed, (or will emerge anyway, without any marketing), as a key advantage.
"These 20 year old Perl 5 scripts still run without any modifications on the new machine. Amazing!..."
There are not many languages that have this property of long-term stability. One of them is R , see recent Blogpost "Ode to R stability" by Dirk Eddelbüttel, one of the R authorities (and Debian Maintainer)
http://dirk.eddelbuettel.com/blog/2021/03/20/#ode_to_r_stabi...
Well, maybe Perl 5's backwards-compatibility can be marketed, (or will emerge anyway, without any marketing), as a key advantage.
"These 20 year old Perl 5 scripts still run without any modifications on the new machine. Amazing!..."
There are not many languages that have this property of long-term stability. One of them is R , see recent Blogpost "Ode to R stability" by Dirk Eddelbüttel, one of the R authorities (and Debian Maintainer)
http://dirk.eddelbuettel.com/blog/2021/03/20/#ode_to_r_stabi...
So they explicitly laid out their plan for further destruction. Not that is unknown, they did it since 5.8 days, since perl6.
No plans for explicit improvements as detailed planned in 2002, for perl6. 90% of those goals should be perl5 goals, just not breaking syntax, because it is cool. So their new plan is to follow the perl6 route, breaking syntax, cpan and backwards compatibility, whilst still having not a single clue how to implement those features.
OO? They are still completely clueless. Jit? Not even mentioned. Native types, ffi? Not even mentioned. Abstract the parser for macros and grammars? Not even mentioned. Proper signatures? Only on cpan, not in core. And many such features which I already have implemented for perl5/cperl.
There is no future, they killed it. Long time ago. Everybody with a little bit of competence already left at around 2005. Just leave it alone, until you can promise something and those plans are believable. The more you do, the more destruction.
No plans for explicit improvements as detailed planned in 2002, for perl6. 90% of those goals should be perl5 goals, just not breaking syntax, because it is cool. So their new plan is to follow the perl6 route, breaking syntax, cpan and backwards compatibility, whilst still having not a single clue how to implement those features.
OO? They are still completely clueless. Jit? Not even mentioned. Native types, ffi? Not even mentioned. Abstract the parser for macros and grammars? Not even mentioned. Proper signatures? Only on cpan, not in core. And many such features which I already have implemented for perl5/cperl.
There is no future, they killed it. Long time ago. Everybody with a little bit of competence already left at around 2005. Just leave it alone, until you can promise something and those plans are believable. The more you do, the more destruction.
It was my first programming language I got things done with
- until I discovered ruby. After a ride into lisp/scheme/racket world I'm on ruby again.
I have good memories with it, but I wouldn't jump train again.
I have good memories with it, but I wouldn't jump train again.
Always ignored perl for default *nix toolbox (bash + awk + sed) utilities that were standard and in place 'by default'. These days unless you have python 2 and 3 + 20 python libraries per version on a system you can't count on a developer being productive. Recently I've seen guys drive ssh remote command execution in java - we are falling into fashionable senility.
https://docs.google.com/document/d/1OxeK0ctbBPtNw7UPG5x9iRYM...
... is probably a better link than the random discussion in that horrible JS webapp?
... is probably a better link than the random discussion in that horrible JS webapp?
I ain't sure if replacing a horrible JS webapp with a different horrible JS webapp is much of an improvement ;)
I appreciate the effort. If you don't like webapp bloat consider using pastebin: https://pastebin.com/, or any other text-sharing service.
What exactly is Larry Wall's involvement with Perl anymore? Has he moved entirely to Rakudo (ne Perl 6)?
Larry Wall designed Perl 6 i.e. Raku and created the original parser. I am not sure if he is still actively working on it. The actual implementations, however, were done by others. So like Lisp or C Raku is actually a specification driven language in contrast to languages like Perl 5, Ruby or Python where the most popular interpreter serves as the specification.
Raku is actually a specification driven language
That hasn't been true for a while. The test suite is supposed to be canonical, whereas the 'specification' hasn't been kept up to date with language evolution.
That hasn't been true for a while. The test suite is supposed to be canonical, whereas the 'specification' hasn't been kept up to date with language evolution.
That hasn't been true for a while.
Within minutes of announcing Raku nearly 21 years ago Larry answered a question about it from the audience[1]:
> Question: Will Raku have specs ...?
> Larry: ... develop the real regression tests into a validation test ... then we actually have a machine-readable spec. And to me that’s actually a lot more important than what the verbiage on the human readable thing says.
It took years before folk caught up with Larry's intent, but the regression test suite has been called "roast" (Repository Of All Specification Tests) for something like 15 years and what you're calling "the 'specification'" was renamed to "the 'speculation'" around the same time.
[1] https://www.perl.com/pub/2000/10/23/soto2000.html
Within minutes of announcing Raku nearly 21 years ago Larry answered a question about it from the audience[1]:
> Question: Will Raku have specs ...?
> Larry: ... develop the real regression tests into a validation test ... then we actually have a machine-readable spec. And to me that’s actually a lot more important than what the verbiage on the human readable thing says.
It took years before folk caught up with Larry's intent, but the regression test suite has been called "roast" (Repository Of All Specification Tests) for something like 15 years and what you're calling "the 'specification'" was renamed to "the 'speculation'" around the same time.
[1] https://www.perl.com/pub/2000/10/23/soto2000.html
FWIW, the "specification" now only has historical value, and possibly as an inspiration for implementing features that were once considered. It is nothing more than that, nor has it ever been.
The test-suite is canonical: being able to pass a significant number of tests, allows you to say you've implemented a significant portion of the Raku Programming Language.
The test-suite is canonical: being able to pass a significant number of tests, allows you to say you've implemented a significant portion of the Raku Programming Language.
> The test suite is supposed to be canonical, whereas the 'specification' hasn't been kept up to date with language evolution.
This is so disappointing. Feels like the language over time has lost everything that made it interesting. PUGS for example.
This is so disappointing. Feels like the language over time has lost everything that made it interesting. PUGS for example.
I hear you feel disappointed, but it is presumably due to someone having misled you due to their misinterpretation of Larry's design.
Roast (the Repository Of All Specification Tests) has, for over 20 years in design terms, and 15+ years in reality, been Raku's canonical, machine readable specification that is versionable, branchable, forkable, mergeable, and which is backed by a PL design that envisages its versioning, branching, forking, and merging.
So we now have a suite of approaching 200K tests that provide a principled software engineering way to generate a single boolean True|False that a so-called Raku compiler does or does not precisely implement the machine readable specification.
Features cannot be removed or added without not only being specified in language, and if appropriate subjected to formal analysis, but also openly discussed and debated, implemented in a branch, hammered on for however long with beta testers trying it out to see if it's worth removing/adding, and only then arriving in the official master branch of roast.
This can and has meant there can be up to a 3 year period before changes become official, or, conversely, a 24 hour period for a security patch to become official, and the system guarantees that any risk of breakage is controlled by users. This is a revolutionary level of centralized/distributed digital governance.
Roast (the Repository Of All Specification Tests) has, for over 20 years in design terms, and 15+ years in reality, been Raku's canonical, machine readable specification that is versionable, branchable, forkable, mergeable, and which is backed by a PL design that envisages its versioning, branching, forking, and merging.
So we now have a suite of approaching 200K tests that provide a principled software engineering way to generate a single boolean True|False that a so-called Raku compiler does or does not precisely implement the machine readable specification.
Features cannot be removed or added without not only being specified in language, and if appropriate subjected to formal analysis, but also openly discussed and debated, implemented in a branch, hammered on for however long with beta testers trying it out to see if it's worth removing/adding, and only then arriving in the official master branch of roast.
This can and has meant there can be up to a 3 year period before changes become official, or, conversely, a 24 hour period for a security patch to become official, and the system guarantees that any risk of breakage is controlled by users. This is a revolutionary level of centralized/distributed digital governance.
The specification is the test suite. (Which has been kept up to date.)
A text specification like the one C has is bordering on useless. There are plenty of things that are “implementation defined”.
I think it was C that had to resort to saying that new features wouldn't be added to the specification until at least one implementation supported it, because it turned out some of the new features were impossible.
The thing that cygx was referring to were the Apocalypses, Exegesis, and Synopsys.
They were never intended to be a specification as such. They were more of a way of talking about and thinking about the intended features and how they might look. At no point did anyone try to turn them into something more resembling a text specification.
I would like to point out that they had a lot of inconsistencies. There were features in one that weren't possible without breaking features from another. Things which weren't found until there was a test-suite.
Which is precisely why we don't have a text specification like C, we have a test-suite as the specification. It certainly makes it easier to determine if an implementation follows the specification.
A text specification like the one C has is bordering on useless. There are plenty of things that are “implementation defined”.
I think it was C that had to resort to saying that new features wouldn't be added to the specification until at least one implementation supported it, because it turned out some of the new features were impossible.
The thing that cygx was referring to were the Apocalypses, Exegesis, and Synopsys.
They were never intended to be a specification as such. They were more of a way of talking about and thinking about the intended features and how they might look. At no point did anyone try to turn them into something more resembling a text specification.
I would like to point out that they had a lot of inconsistencies. There were features in one that weren't possible without breaking features from another. Things which weren't found until there was a test-suite.
Which is precisely why we don't have a text specification like C, we have a test-suite as the specification. It certainly makes it easier to determine if an implementation follows the specification.
> whereas the 'specification' hasn't been kept up to date with language evolution
You mean Rakudo added features not listed in Raku's specification? Which ones?
You mean Rakudo added features not listed in Raku's specification? Which ones?
cygx incorrectly thinks that the Apocalypses, Synopsys, Exegesis were the specification.
There is a reason we don't try to keep them up to date [anymore]. They are historical documents that were used to discuss and understand what the language was going to look like.
There is a reason we don't try to keep them up to date [anymore]. They are historical documents that were used to discuss and understand what the language was going to look like.
For the record, the language is called Raku, whereas Rakudo is the compiler.
Larry stepped back from Perl 5 a while ago, but used to actively contribute to Rakudo until 2017 or so. I haven't seen him around as much over the last couple of years, but then again, I also do no longer keep abreast of Raku development and might jsut have missed it...
Larry stepped back from Perl 5 a while ago, but used to actively contribute to Rakudo until 2017 or so. I haven't seen him around as much over the last couple of years, but then again, I also do no longer keep abreast of Raku development and might jsut have missed it...
I had fun with Perl and Tcl back when I was 14 or something. I think they may have been the first "serious" programming languages I have used.
"We're determined to have improved OO syntax in a future release, and we'd love that to be v8, but we don't want to hold up this plan because OO needs time to mature."
I wonder what this means. Especially if signatures are on by default, the OO syntax is pretty straightforward already, with most boilerplate gone. Like:
I wonder what this means. Especially if signatures are on by default, the OO syntax is pretty straightforward already, with most boilerplate gone. Like:
package Some::Object {
sub new ( $class, $args = {} ) {
bless $args, $class;
}
}This is the current proposal (it's a living document). For example it was just decided to drop the CONSTRUCT phaser and likely the common keyword.
https://github.com/Ovid/Cor/wiki/Corinna-Overview
This is an implementation of some of the ideas that is proving out to be faster (execution wise) than hash based objects:
* https://metacpan.org/pod/Object::Pad
https://github.com/Ovid/Cor/wiki/Corinna-Overview
This is an implementation of some of the ideas that is proving out to be faster (execution wise) than hash based objects:
* https://metacpan.org/pod/Object::Pad
> with most boilerplant gone
Boilerplate class variable, boilerplate args variable, both written twice, deliberately cryptic whimsical 'bless' operation that for some reason needs to be done manually. Come on...
Boilerplate class variable, boilerplate args variable, both written twice, deliberately cryptic whimsical 'bless' operation that for some reason needs to be done manually. Come on...
The boilerplate class and args aren't mandatory, @_ still exists. I put them in the example to mean that if you wanted to use them, you don't have to pull them out of @_ with boilerplate.
As for bless(), it's what makes Perl OO work. Getting rid of it is an option, but to me getting rid of it makes things more cryptic.
As for bless(), it's what makes Perl OO work. Getting rid of it is an option, but to me getting rid of it makes things more cryptic.
> As for bless(), it's what makes Perl OO work. Getting rid of it is an option, but to me getting rid of it makes things more cryptic.
Yeah I get it... but it's still boilerplate. Something you have to write out manually each time which you don't need to do in other languages.
Yeah I get it... but it's still boilerplate. Something you have to write out manually each time which you don't need to do in other languages.
Yes, but it is significantly less boilerplate than before.
If you get rid of bless(), you would need to add some equivalent to "package" that is OO specific rather than just namespaces, and/or a magical constructor method name. That (to me) is no less whimsical than bless.
If you get rid of bless(), you would need to add some equivalent to "package" that is OO specific rather than just namespaces, and/or a magical constructor method name. That (to me) is no less whimsical than bless.
I would guess something that allows defining classes in a way that resembles Moo or Moose.
You can build anything in any programming language, even byte code/assembly if you're so inclined. What you end up using is the one that can do the job faster. I built a custom web store yesterday entirely in mod Perl in 2 hours flat ( https://store.poidata.xyz ). If you can beat that in some other programming language, like Python, by all means, stop using Perl.
> What you end up using is the one that can do the job faster.
Not necessarily. Maybe you're interested in:
* Performance optimization.
* Maintainability.
* Accessbility to more programmers (= fashion)
* Conforming to organization policy on the language to use
* Code readability
etc. Different target function -> different considerations.
Not necessarily. Maybe you're interested in:
* Performance optimization.
* Maintainability.
* Accessbility to more programmers (= fashion)
* Conforming to organization policy on the language to use
* Code readability
etc. Different target function -> different considerations.
Agreed. These are fair points of consideration. In my case though, the main one to consider is speed of development.
The future or Perl: Python
The Future of Perl apparently resides on a JavaScript only site. What a weird world.
I work for Fastmail, and helped write Topicbox, the backend of which is entirely written in modern Perl. The frontend obviously uses JavaScript, and talks to the backend using JMAP (RFC 8620), which we helped to develop; Topicbox was using 100% JMAP well before Fastmail itself did.
Why can't the back-end of Topicbox do the JMAP stuff and then serve up some HTML? Beyond "because that's how we built it and it must be thus", it's quite hard to see why the front-end would need so much JavaScript to render nothing more than a chain of emails.
If you're just loading a single page, then yeah - it's pretty useless. If you're spending any time in Topicbox then the benefits of push updates and dynamic preloading pay off, and it's pretty lightweight as Javascript goes.
But yeah, in a perfect world where we had infinite time to develop it, we'd have the backend serve up a non-javascript static version of the content in response to direct links - if nothing else because it makes things a lot nicer for search engines - and then the javascript would load in and take over if enabled to allow you to keep moving through the site like usual.
But yeah, in a perfect world where we had infinite time to develop it, we'd have the backend serve up a non-javascript static version of the content in response to direct links - if nothing else because it makes things a lot nicer for search engines - and then the javascript would load in and take over if enabled to allow you to keep moving through the site like usual.
> and talks to the backend using JMAP (RFC 8620)
FastCGI and mod_perl would have been a better choice.
FastCGI and mod_perl would have been a better choice.
Just because you use Perl doesn't mean you can't use any other languages where appropriate. You don't need to be a zealot about everything.
Believe it or not, I am one of these people hurt daily by the modern web. I rely on accessibility to do my daily tasks, and accessibility is the thing that goes away bit by bit from year to year. I used to do Perl for server-side scripting, the classical CGI stuff. I know the war is over. But calling a disabled person a zealot is probably a bit overshooting, dont you think?
Perl is nothing if not pragmatic.
JavaScript only website (couldn't even load the page without it) with a link to a Google Docs document.
They've lost their way.
They've lost their way.
In case anyone else is unclear on what the objection to the google doc might be, it also requires JavaScript.
[deleted]
Every day I have to parse some new type of text file and Perl is great for that. Everyone else I work with are also in the same age range and everyone already knows Perl. Introducing a new language doesn't seem worth it.