The Future of Perl
perl.topicbox.com
perl.topicbox.com
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.
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.
So when I know I'm writing something which is primarily text regex handling, I definitely reach for perl.
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.
[1] example: https://www.bloomberg.com/news/articles/2020-04-13/an-ancien...
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.
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...
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 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.
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.
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.
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...
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!
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...
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.
Welcome to earth! We don't do it that way here.
(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.)
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
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.
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.
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.
Awk and friends are great, but also a bit awkward to write complex applications with, in my non-expert experience.
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.
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.
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.
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]))
Is that the reason why there's a shortage of new NVidia cards? /s
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.
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.
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.
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. perl -e '
sub foo { $x = 42 }
foo;
print "\$x is $x\n";
'
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.
Leading tabs or spaces?
/s
----
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 suffers for the same reason. 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.
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.
$hash->{$key}->%*
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).
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'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.
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 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 don't WANT so-called modernization. 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.
But that's the worst way to deploy a program.
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.
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.
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.
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 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)
> 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
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....
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.
Enjoyed them (the Perl books). But didn't get a chance to use Perl in non-trivial real projects.
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.
Perl was a legit tool in bioinformatics due to its insane text parsing performance. Ruby performance is absolute garbage.
The rich ecosystem of tested Perl modules for file formats along with the testing frameworks made coping with change bearable - not enjoyable, but bearable.
Is anything ever really taken out of /usr/bin once it gets in there? It may be a long long /usr/bin/time.
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)
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
}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"?
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.
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.
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.
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.
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...
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.
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.
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?
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.
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.
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.
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);
}
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.
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.
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.
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.
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.
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
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.
Python, I am looking at you!
Bad idea, imo. Keep the perl binary backwards-compatible (unless 'use v8' is specified), and add a separate perl8 alias that does so implicitly.
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.
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.
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.
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.
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.
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.
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.
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...
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.
I have good memories with it, but I wouldn't jump train again.
... is probably a better link than the random discussion in that horrible JS webapp?
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.
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.
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.
This is so disappointing. Feels like the language over time has lost everything that made it interesting. PUGS for example.
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.
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.
You mean Rakudo added features not listed in Raku's specification? Which ones?
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.
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 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;
}
}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:
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...
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.
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.
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.
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.
FastCGI and mod_perl would have been a better choice.
They've lost their way.