Having said that, I think this might be too fine-grained.
First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing your valuable beta testers beyond that with a second line that’s entirely redundant with the first one.
The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then begin a new (hopefully long) era of backwards compatibility. That makes it easier for users to maintain their code, is probably easier to implement, and also easier for users to learn, since there are fewer sets of rules.
Lastly, I hope they also focus on tooling around installation. One paradoxical problem with modernizing Perl is its historic success: every variant of Linux or Unix already comes with an ancient version of it. I know many experienced Unix people hate this trend, but there’s a reason some of the most actively evolving language ecosystems install more and more of their binaries into the user’s home directory. Maybe that’s already the case for Perl, I wouldn’t know.
All that said, I’m not following Perl that closely anymore. These are just some really quick observations about very complex topics. I don’t claim to know nearly as much as the people who made these decisions, and it’s great to see that things are happening.
But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it?
> I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then have a new (hopefully long) era of backwards compatibility.
How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)? Making piecemeal (if needed) changes is much easier than having to update a ton of code and that is even more important when that code wasn't touched for a long time.
EDIT (i put it here since i already got three replies on the same thing): i understand that you can mix two different files with different "editions" but it still makes it hard to update these files themselves.
AFAIUI you can mix Rust 2015, 2018, and 2021 crates; so a developer can update their own crate to 2021, while not having to completely re-write the dependencies which are still Rust 2015. With Python 2 -> 3, my understanding was that everything had to be updated recursively.
That said...
> I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then have a new (hopefully long) era of backwards compatibility.
What they describe actually sounds somewhat similar:
> At some point in the future, the PSC may decide that the set of features, taken together, represent a big enough step forward to justify a new baseline for Perl. If that happens, then the version will be bumped to 7.0. If this happens, Perl 7 will still be backwards compatible with Perl 5 by default – you'll have to put use v7; at the top of your code to use all the new features. Think of use v7 like Modern::Perl and similar modules.
So the 'use <feature>' is going to be similar to Rust's "nightly unstable features", but actually being stable; and 'use vN' is going to be like Rust's Editions.
It's just that they don't think they've accumulated enough features to release a new Edition yet.
It does not, though? You have to update the entire file (really crate) at once, but that’s really not much of a challenge as it’s near exclusively syntactic, and syntactic changes are easy to make, just fix compiler errors.
I feel like you didn’t go through the Python migration yourself and just go off of the echoes you got from it, but the issues in the Python migration were not “updating code is hard”. It was really the easiest part, and could mostly be done mechanically (which incidentally `cargo fix` provides for when migrating between editions).
The challenges of the Python migration was:
- You had to wait for all your dependencies to be updated before you could migrate yourself, commonly this was mixed with API updates while at it especially at the start, this is not an issue in Rust because there is no dependency between crate editions, I can use edition 2018 and depend simultanously on edition 2015 and edition 2021 crates.
- Many changes were semantic in nature, there was no way to check them statically, instead they were runtime changes (in types or behaviour), which made ensuring they were correct a lot more challenging; editions do not cover or allow for this.
The Python migration wilfully included fixes to long-standing semantics issues of the language (though whether all were improvements, or whether they went far enough remains a matter of debate), and this as well as the incompatibility are what made it an issue.
If it had been entirely syntactic and a per-package or per-file thing it would have been much less of an issue (not an entirely non-issue as things like library contents are a runtime concern in python, but still…). And that’s what rust editions are.
What this gives you is high confidence that when inserting a few lines somewhere, that fancy new for loop simply works. No need to scroll to the top if the file and remember which exact release of the 27 in the last year introduced the feature.
A 2018 edition project (declared in the project config) is pinned to that version forever. You would have to switch to a new edition explicitly.
Well that was easy.
Perl already had python2->python 3000 fiasco before python: PERL6
This exists since 2013. https://metacpan.org/pod/experimental
> Probably not much of a problem currently, but might be if releases get more frequent.
Very unlikely. Perl switched to a yearly release in 2010, it has been in use since and there is no indication for this to change. https://lwn.net/Articles/485569/#:~:text=a%20%22timeboxed%22...
> focus on tooling around installation […] install more and more of their binaries into the user’s home directory
Exists. Wouldn't be Perl if one hadn't the choice between multiple solutions.
https://metacpan.org/pod/local::lib https://perlbrew.pl https://github.com/tokuhirom/plenv https://metacpan.org/pod/perlall https://metacpan.org/pod/App::plx https://github.com/stevieb9/berrybrew
> I’m not following Perl that closely anymore
It is evident.
Good to know, but maybe it’s not my fault that I assumed an official post by the Perl Steering Committee on perl.org would show the best solution.
> Exists. Wouldn't be Perl if one hadn't the choice between multiple solutions.
That’s great, but you might notice that you’ve given me, who is new to these approaches in Perl, exactly no information on where to start.
> It is evident.
Yes, I was very transparent about the extent and recency of my experience. Luckily, that combative attitude to a mostly interested/positive comment isn’t representative of the Perl community as a whole, or there really wouldn’t be any users left.
It is. "use experimental 'try';" works already.
> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features.
This is intentional. The largest strength of Perl is that, barring significant security-type issues, a script written in 1995 will still run with the version of Perl you've installed. If you write a script with "use v5.36", you would change that version only if you intend to modernize the script with features from a newer version, and determine that such features don't break the script. This is harder to determine for some features than others, for example applying the 'unicode_strings' feature to an existing script written without it is rather perilous.
A "use v5.36" directive is going to be very opaque for many users, but it doesn't need to be understood to serve the purpose of determining the minimum Perl version to install in order to run a certain script very effectively.
The future is containers, which is basically increasingly thin images tailored to your application.
These days I struggle to find Perl on many EC2 instance I work on. Its always good to have something like Perl in your installation for some quick scripting work. But most don't have Perl installed.
There's https://perlbrew.pl/ and there's cpanm with "use lib".
I doubt anyone would write a greenfield project in Perl when numerous other platforms are available. Raku is there if you like the design philosophy of Perl but don't need to worry about backwards compatibility.
I wrote a static site builder using Perl along with a very rudimentary templating system (https://soft.thran.uk for the curious). I've also found it very convenient for any sort of data shunting I find myself doing, it can easily manipulate and convert XLS, Json, other formats I encounter in my work.
I hope it doesn't go away. There's a mindset to Perl that clicks with me and just isn't present in many other languages.
It's ugly for all the reasons that people complain about it for but those are largely complaints and the rest of us have work to get done.
Oh yeah, and if you liked perl - I highly recommend learning AWK/SED. Even lower on the execution overhead (Can do shit in the processor cache and avoid memory allocation bottlenecks on enormous hundreds of gigabyte CSV datasets with a crappy processor in milliseconds kind of stuff)
It is built to work with pipes, it's fast, concise, stable, and easy to extend. The REGEX integration is superb.
It seems to me that we have a couple of generations of programmers who turn up their nose at anything that isn't Python notation and then repeat vague arguments about Python's superiority. But like all dogmatic systems, there is no agreement among the zealots.
Python is far from perfect; I see many problems in the Python ecosystem. There remains much to be said for concision and expressivity in other languages. In any case, by the time one has written enough Python, one sees that the "purity of notation" is a myth. And the DSLs within Python (Pandas, Numpy) offer their own pain.
awk, sed, grep, C, C++, Java, and Perl are excellent tools.
That makes collaboration hard. The freedom I have in putting my thoughts into code, uninhibited by syntax, types and conventions makes it nearly impossible for others to understand and modify my work.
The perl coding team I was on made readability our #1 priority. We didn't use tricky or out of the ordinary syntax unless it was absolutely necessary (like unusual regex, etc), and in those cases we would document what was happening with comments and maybe a reference to the appropriate man page. We had a style guide, for a consistent look and feel. We paid attention to naming and commented blocks of code, so the reader would not need to run an interpreter in their head while skimming through the code. We'd seek feedback from each other. It worked out well. We had no problems reading our code.
We used the flexibility and expressiveness of perl to make our code more readable. We had the freedom to tailor the code to what we were doing, instead of the other way around.
Perl has no problem from flexibility not shared by C, Common Lisp, JavaScript, Ruby, or Ada.
The blog post seems to indicate that the steering council simply wants to to avoid being bitten by Zawinski's "CADT" model.
And who could blame them after seeing the kind of stunts pulled in other language communities?
I don't think rewrites were on the map for Perl, except arguably for Raku (Perl 6 as was) and I don't think Raku's developers were intending to throw away bug reports and just begin over next year, indeed even though Perl 6 failed in its original goals Raku seems to still be going.
I wouldn't classify any of the spectrum of language evolution strategies for popular languages as CADT, even Python where Python 3 was needlessly incompatible this wasn't part of some larger plan it just fell out from what they wanted to do and was then mismanaged. Getting to a place where strings aren't just "some bytes, who knows if they're human text, good luck" is difficult enough to justify a lot of pain on the route there, notice how C++ has tried and failed several times already.
Jamie was thinking mostly of things like GNOME where this was (is?) a big problem.
They're being bitten by the bikeshedding model instead, actively encouraging the use of the language like it's 1998. You want to live in 2022? Fine, just type
use v5.36;
I find that the ideal place for Perl (for me) is smaller one-offs. When used for a huge site it can get really messy.
"Pathologically Eclectic Rubbish Lister" was one acronym I remember.
It only appears to have been skipped when looking from today's point of view, since many references to Perl 6 have been scrubbed from the web and replaced with its new name. But for those who were following the saga back then, starting with the announcement that the next major release of Perl would be Perl 6, followed by the many announcements of cool new features that next major release of Perl would have, culminating with its long-awaited Christmas release, it's hard to say that it never existed under that name.
I'm still confused about what happened to Perl 6! "replaced with it's new name" -- googling, that's "raku". So... what was going to be Perl 6 is considered a different language, and not particularly compatible with Perl. But "Perl 7" is meant to be less of a departure?
It is weird OP left Perl 6 out of the story of "what happened to Perl 7". I guess it's just too painful?
GNOME jump from 3.x to 40 could be added: https://www.omgubuntu.co.uk/2020/09/gnome-40-version-number-...
Or Microsoft Edge from from 44 to 79: https://en.wikipedia.org/wiki/Microsoft_Edge
At some level that's what I think has happened to Perl in general. I never liked Python much, until I got forced to use it on a new team. Now I'm convinced that it has a really distinct advantage -- there aren't too many ways to write Python, so an experienced Python developer can figure out code pretty quickly. But Perl programs are frequently art pieces that take a lot of effort to truly grok.
We all get this when we encounter jargon-crazy groups, but somehow forget it when it comes to code.
I think for non-trivial programs it is not avoidable to have to learn first the terminology of the domain and the terminology of the program (how things were named when it was not dictated by the language of the domain).
However, hacking the syntax of the language is a whole different story, and perhaps that's where DSL-ready languages go wrong. That's ironic coming from someone that just quoted the author of a language that has no syntax to speak of, and macro powers that are sometimes compared to Lisp macros. Just use them wisely, one would say, but that kind of wisdom comes with experience.
The folks responsible for that are still growing and improving their own ecosystem. It's a Perl-family language but it's different enough that they stepped away from the name so both Perl and Raku can flourish.
'There's more than one way to do it' and the whimsical, deliberately slightly obtuse design of Perl used to be what people valued.
Then something happened (perhaps it was how people started building much larger apps in 'scripting' languages, to use an out-dated term) and I think to most people under 35 deliberately having 'more than one way to do it' sounds like an atrocious idea and something they don't want anything to do with. Same with linguistic whimsy in their language design - they don't want to have to look up why a method to do with objects is called 'bless' for example.
Look at the success of languages like Go, which are the polar opposite of Perl's philosophy.
A guy who is an expert lets say C# 2.0, would have no way to just read code for C# 9 that took advantage of new features and syntax.
It can be procedural, object oriented, functional, in a limited way aspect oriented, it can be data oriented in a way and all of those at the same time.
This is why I picked up Python many years ago. I had been using Perl 5 for my scripting and system administration needs. While it worked just fine any project larger than a few hundred lines needed a lot of discipline to keep maintainable. Perl encouraged too many line noise shortcuts, reading unfamiliar code was too often an exercise in looking up uncommon operators.
It's elegant when writing but frustrating when reading. Python not only read a bit more like it executed but didn't lend itself to unreadable shortcuts. If your code is elegant to write it tends to be straightforward to read.
When Perl 6 was still Perl 6 the DSL stuff sounded interesting until like you I realized it would just turn large projects into unreadable messes. It wouldn't help the small Perl scripts be more readable nor would it help the large projects be more maintainable.
As a person who used to use Perl 5 rather extensively back in the day for all sorts of things, I fondly remember the joke that Perl is a "write-only language" :)
Features that make a language expressive in a consistent way are very valuable though. Python is a good example of this, even people who don't know anything about Python can generally read a Python program.
The syntax noise is too great and it has too many ways for people to be too clever with it.
Without syntactic abstraction (function and data only), things are worse, because those abstractions have to be coordinated together into proper usage scenarios, and those are written by hand in multiple places. So you're looking at eye-glazing repetitions.
Oh, and just because a language doesn't have macros doesn't mean you won't see any syntax-level DSL. You may find textual code generation in a project in any language. C++, Go, Java, you name it.
Understanding a large amount of unfamiliar code is a challenge no matter how it is organized. Whether it uses syntactic abstraction is a minor factor, and it is not an iron clad truth one way or the other whether that helps or hurts. If you can learn a complex API where you have to take several kinds of objects through a multi-step workflow, you can probably learn a syntactic construct that does it for you; especially if it is documented and has test cases.
You will never hire anyone who is experienced in the vocabulary of your code base, unless it was someone who was previously laid off.
Above that sticking with standard languages really is useful. I remember seeing a "DSL cycle" somewhere - http://mikehadlow.blogspot.com/2012/05/configuration-complex...
The old friend, you can always rely on to do quick scripting work. I've written non-trivial quantities of Perl in the past, and maintained other people's Perl code too. Contrary to popular opinion, I've always found it easy to maintain.
I still call upon Perl to do
open(FILEHANDLE, $file) or die;
while(<FILEHANDLE>){
....
}
close(FILEHANDLE)
These days I do good deal of work in Python. Python itself has been heavily Perlified over the years, especially Python3. Its fame seems to have come moving away from Pythonic principles, to Perlic principles. They add lots of features, even syntactic features, libraries and even things like typing. Python isn't the small, minimal core of ecosystem anymore.
Every single release of Python gives me the Perl feel from the old days.
So I kind of don't miss Perl at all, after all we managed to turn Python into Perl.
Long live Python, Long live Perl.
(I showed my co-workers `perl -d`, they later discovered and showed me `python -mpdb`)
Nowadays instead of `perl -lne` oneliners I usually make `ruby -lne` oneliners, just for a chance my coworkers could make sense of them.
let's celebrate perl at least for native support of utf-8 strings before it was cool.
Each line of the Zen of Python is the negation of one of the Perl's architectural principles. And when your entire identity is denying something, you can't be anything but similar to that thing.
I've heard that Python (and maybe some others) are slowly replacing Perl as a "subsystem" of Linux, but I doubt that will happen before I retire. So, until then, TIMTOWTDI!
in the meantime I've implemented that, plus types, plus proper signatures, plus unchecked arrays when safe, plus an integrated ffi plus tons more features.
their is no development, only maintainance. plus lot of internal fights. plus a CoC, which was used to eliminate the only remaining developer, because he dared to critice the stakeholders which blocked progress, and still continue to make the codebase worse.
the less the work, the more the fights.
I was extremely frustrated with existing projects having dependency issues and frequent breakage and wanted to avoid that at all costs.
Perl's flexibility has allowed me to develop my own coding style, which is basically Java-like, and I rarely have trouble figuring out what something does, even months later.
I think Perl is vastly underrated as a language, and its suffers from repeat-speak of people who have only seen poorly written Perl or have never seen a well-managed Perl project.
One of my favorite things about Perl is that there are 20 years of code samples on the Web for it and they ALL WORK because Perl has not introduced breaking changes since 5.000.
It's even worse for anything that interacts with libraries or APIs -- those change over time, and often nobody does the work to repair compatibility.
So I think at this point it's fair to say it's dead. Even if the core language is technically functional, the ecosystem is rotting.
I was curious and you made me check. There's a number of releases with incompatible changes listed if you google for it. For example a whole list at https://perldoc.perl.org/5.12.0/perldelta#Other-potentially-... So no, there's been quite a few.
I'll note that if you use a strict subset of Perl, and write it well, with lots of unit tests, it's bearable to use. But it falls massively short when it comes to anything concurrent or async. And if you stray into the "clever" subset of Perl, frankly it becomes hell. The ecosystem is also pretty much dead, it's not unusual to find bugs in packages where the issue tracker hasn't been responded to in 10 years, and the issue for the bug you're interested in has been languishing for literally years.
Yes. Very much this. Anecdotally, I'd estimate that, outside of the big, well-known modules, about 25% of the CPAN modules I try to use have bugs that render them unusable and unresponsive maintainers.
Here's a description of an example I found last year - https://dev.to/davorg/failing-to-get-product-information-fro... (my project to write a replacement module has stalled).
Yeah, this is the thing... it's very very easy to go down a one-way street to an endless hell of incomprehensible line-noise code and "clever" tricks that are incomprehensible and unmaintainable.
On the plus side, having dealt with the hell of "clever" perl early in my career (and, ahem, maybe having been guilty of writing some), it has beaten into me the absolute necessity of writing the simplest, clearest, not-clever code possible. In some other language.
Perl has some decent CPAN modules for handling multi-process applications-- it is true that it's very weak for threaded applications.
(Raku on the other hand has some extremly convenient CAP features in general.)
Nonsense, there's AnyEvent, EV, IO::Async, Mojo::IOLoop. If you need parallelism, yes, you'd better use Go or something else.
And the 10 years old bugs are to a large extent an exageration, because those modules are probably abandoned and you shouldn't use them anyway.
Compare this long-term approach with the fires in Python or (heaven forbid) Node ecosystems, where things break all the time.
I disagree. Perl still works fine for large systems. I understand why people choose other languages. It depends on what your needs are and what skillset works best for you and those you work with.
What about Docker and Virtualenv? Both make it possible to keep running code until the end of times.
Until four or five years ago, there was still plenty of maintenance work to be had, but even that has pretty much dried up now.
[1] http://www.masonhq.com/sites
Edit: I left in 2013 so I don't know if it's still the case.
a) iCalendar and timezone pre-processing for an Arduino alarm clock; Arduino libraries aren't up to the task (and neither am I! recurring events with recurring exceptions is kind of complex), but cpan iCal libraries and timezone libraries seem to work.
b) personally monitoring script, checks a bunch of stuff and sends email (well, cron sends the email, really) if problems persist for long enough
c) something to fetch my DSL sync speed and status (uses Net::Telnet), which feeds into the monitor script, but also used to adjust bandwidth limits for fq_codel to reduce bufferbloat.
I would kind of prefer the features be enabled by default if you use a high enough version and if a module breaks you just fix it or dial back the version number at the top of your script until it is fixed.
But I'd also run all of the test suites on CPAN against every new feature that comes out and fixing or at least tagging anything that breaks. Maybe even list a "maximum tested version number" for each module and emit a warning if you exceed it.
- https://web.archive.org/web/20100214124540/http://www.wall.o...
- http://www.wall.org/~larry/perl.html
That butterfly was the worst. Perl would have been better served having an animal like the honeybadger as its logo.
Agree completely. Larry Wall is pretty brilliant, but he shouldn't be doing graphics design.
Actually, I tend to dislike cutsey-poo cartoon icons, in general. If you want to pick an animal totem, there are plenty of public domain photos of actual animals courtesy of the NSF and such...
It does require having a litany of switches at the top of each source code but it beats having old code break (though i do think that in some cases the FPC devs go a bit too overboard - e.g. attributes would be a syntax error anyway).
The amount of time spent on this seems absurd and could have been spent getting a perl 7 release candidate ready. It's sad to see OSS eat itself alive so often over a desire to keep something that people just assume is desired.
Perl 6 was designed to be the successor language to Perl 5.
The only technical grounds for Perl 6 being metaphorically sidelined was because Perl 6 lacked the startup and runtime performance characteristics of Perl 5 — fixable problems.
Proponents of Perl 5 often contend Perl could’ve escaped developer mindshare loss without Perl 6 in the picture. But to claim Python, Ruby on Rails, Clojure, Go, Rust and JS/TS never would’ve gained serious developer mindshare had _Perl 6_ not existed seems very myopic to me. All the brilliant new languages and web frameworks launching were bound to erode Perl’s early established dominance regardless.
Things would be different now if Perl 6 was at least as performant as Perl 5. Perhaps then it would’ve become popular years ago amongst Perl users to switch all greenfield Perl code to Perl 6. Then “Perl” would’ve become synonymous with modern language features.
Perl 6 was treated as the successor of Perl 5 -- and that was the mistake. It meant Perl 5 started dying, since people assumed that Perl 5 would be soon dead, and Perl 6 had a new different syntax. And then it took 15 years to happen, during which Python and others ate its lunch.
I think a more successful strategy would have been to make it clear very early on that Perl 6 would be some sort of long term experimental project, and that Perl 5 would be expected to be a thing for a long time still.
If in 2015 Perl 5 still had a thriving ecosystem, and there was a demand of Perl-like but better, then Perl 6 could have been more successful. But in the current timeline it's a successor to an almost defunct language, and isn't such an attractive proposition.
In 2000, for all intents and purposes, Perl 6 was the successor of Perl 5. And one of the reasons the project was started, was because Perl 5 was already dying at that point. Not only losing the web server competition to PHP, but also from internal battles, close to civil war.
The internal battles ceased for a while when the Perl 6 process was started. But around 2008, it became a war between Perl 5 and Perl 6. To squelch that, the sister language meme was born. But that just meant a cease-fire, rather than peace, and the dissent and resentments continued to fester under the blanket of the sister language meme.
Until 2019, when the rename of Perl 6 to the Raku Programming Language happened. Factions within Perl 5 lost their common enemy, and fighting could start all over again. Which caused at least one pumpking to resign.
To mark Perl 6 as the cause for Perl 5's demise, is incorrect. Perl 6 was one of the effects of Perl 5's demise.
Meanwhile the Raku Programming Language continues to build a programming language of the future. You can check out the Rakudo Weekly News if you want to stay up-to-date on developments https://rakudoweekly.blog
Raku’s built-in grammars make parsers trivial to write. I effortlessly created two [2] — one for reordering fstab entries, and the other for converting human-readable LUKS offsets into cryptsetup sectors — on a lazy afternoon. Grammars in Raku make this second nature.
Then you have Raku’s multi-dispatch. It is more capable than Erlang/Elixir pattern matching:
# a list with at least one element, extracting the head and tail
multi sub tail(*@list ($head, *@tail)) { @tail }
multi sub tail(*@list) { @list }
[3]
==> tail()
==> say(); # []
[3, 4]
==> tail()
==> say(); # [4]
# pattern matching with arbitrary guards
multi sub user($name where { is-valid-user($_) }) { $name.say }
multi sub user($name) { "invalid name: $name".say }
sub is-valid-user($name)
{
# notice the additive character class in this regex: “letters plus digits”
# fail the match if $name is root
try with $name ~~ /(<+:Letter +digit>+)/ { $0 ne 'root' or fail }; $!.not
}
user('name'); # name
user('1234'); # 1234
user('root'); # invalid name: root
class Coordinates
{
has $.latitude is required;
has $.longitude is required;
}
class City
{
has Str:D $.name is required;
has Str:D $.state is required;
has Str:D $.country is required;
has Coordinates:D $.coordinates is required;
}
my $latitude = -37.840935;
my $longitude = 144.946457;
my Coordinates $coordinates .= new(:$latitude, :$longitude);
my Str:D $name = 'Melbourne';
my Str:D $state = 'Victoria';
my Str:D $country = 'Australia';
my City $melbourne .= new(:$name, :$state, :$country, :$coordinates);
my City:D $sydney = do {
my Coordinates:D $coordinates = do {
my $latitude = -33.86514;
my $longitude = 151.209900;
Coordinates.new(:$latitude, :$longitude);
};
my Str:D $name = 'Sydney';
my Str:D $state = 'New South Wales';
my Str:D $country = 'Australia';
City.new(:$name, :$state, :$country, :$coordinates);
};
# deeply nested argument deconstruction
multi sub melbourne-or-bust(
City:D $city (
Str:D :$name where 'Melbourne',
Str:D :$state,
Str:D :$country,
:$coordinates (
:$latitude,
:$longitude
)
)
)
{
my $gist = qq:to/EOF/.trim;
Welcome to the city of $name. It’s located in $state, $country.
GPS coordinates: $latitude, $longitude
EOF
$gist.say;
}
multi sub melbourne-or-bust(City:D $city)
{
'This isn’t Melbourne.'.say;
}
melbourne-or-bust($melbourne); # Welcome to the city of Melbourne ...
melbourne-or-bust($sydney); # This isn’t Melbourne
Perl 6 took a long time to make, but how much did that matter? What was Perl going to do about Rails, Clojure, Go, Rust, JS/TS, and more? The world of programming languages used to be a lot smaller than it is today.
> Perl 6 had a new different syntax.
Inline::Perl5 [3] allows running legacy Perl 5 code in Perl 6 codebases.
[1]: https://docs.raku.org/language/5to6-nutshell#Regular_express...
It is also great at stability (ie. code written 20+ years ago, still works on modern systems).
So for me, something that I'll write, put in some cron somewhere and forget, is all written in perl... at the same time, my colleagues are rewriting old python2 stuff, because modern distros come with python3 only. Some of them had to fix stuff even for 2.6->2.7 python versions.
On the flip side, I would never get a Perl script and rewrite it in Bash.
Perl <3
The coloring of strings as dirty or clean on I/O.
The object model of Moose.
In general, Perl tends to be much faster than the competing scripting languages (which is why you never see people talk about benchmark numbers, they'd give you the wrong answer).
What happened with Perl is that, effectively, the “pumpking” held that power but when Sawyer X actually used his discretion to announce Perl 7 there was a mutiny by jealous and bitter collaborators. They felt they should have some say in the matter and formed this Perl Steering Committee. As the brilliant Reini Urban has pointed out elsewhere in the comments, this group are fairly mediocre talent wise and mostly just spend their time sniping at each other.
Reini’s cperl or Will Braswell’s rperl are both worthy projects that in a more perfect universe would have long ago supplanted the now rudderless mainline perl interpreter.
Look, I hate to harsh on Sawyer X-- he's done a bunch of good stuff for perl over the years, and I hope to see him around again-- but his Perl 7 push was just a mess. He was getting frustrated about things, and tried to plan and push through some big changes before anyone could complain, but he wasn't really that clear on what the big changes were supposed to be-- he left a couple of weeks to figure it out after that big announcement, and even the inner cabal he had talked to about this stuff first seemed more than a little surprised.
One of the major things we got out of all this is it made it clear we needed some work on improved processes and transparency and such, and that's actually happened. There's a steering committee that makes a point of publishing its minutes, and an RFC process to talk over proposed changes. Some of these changes are in fact actually happening, and a number of them are discussed in this v5.36 annoucement (e.g. subroutine signatures are no longer experimental).
This actually seems like a really bright crew in charge, and they're making very sane decisions.
There's really no reason to think that there's some great benefit to breakage-on-upgrade: its a solution in search of a problem.
I guess nothing beats a good flame war... Emacs v. Vi anyone?
And Perl was the opposite of this anecdote: the most brilliant engineers I've met in my career were Perl monks, as they would call themselves. I respect Perl for that :)