I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.
They last line of the article summarizes it well:
> Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year.
Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.
I have used Perl since the Perl 4 days.
One can write bad Perl, and I've written a lot.
One can write good Perl, and I've written some. It has saved me and others quite a lot of time on assorted projects.
These days I tend to use Python where once I'd have used Perl. This is mostly because I find that the young are far more likely to know Python than to know Perl. I will be retiring one of these days, after all.
As a short summary about Perl 7:
If your Perl is old-school, that's OK. Use Perl 5 and we'll keeping supporting you.
If you your Perl isn't old-school, use Perl 7 and get new features.
If you're not sure, ask us and we'll hold your hand to help you understand.
We're here to make sure you're OK.
Once this is out, I'll be interested in any well written guides or books, it has always felt like "the one that got away" to me.
Back in 2002 I had to choose between learning between Python and Perl for a project, but "everybody knew" Perl 5 was soon going to be replaced by a new shiny different Perl 6, so I chose Python.
It will be interesting to see where Perl can live and gain new users nowadays. Python has so much become the "default scripting language", and has so many bindings and libraries.
Much as people complain about Perl, it is the language which I use when I want to have something which will run 10-20 years from now.
I recently wrote a consistency checker for file archives (so that I know when bitrot sets in) in Perl, precisely because I want it to be usable for a long time (https://github.com/jwr/ccheck).
Very happy to see a path forward for Perl 5.32.
Perl has these tiny neat features that I still miss in other languages. Like unless (opposite of if), and postfix syntax.
print "It worked!\n" unless $error;
print "Item: $_\n" foreach @items;My very first program was:
perl -e 'print int rand(10);'
I wrote a lot of Perl. I even wrote a small LISP interpreter entirely in Perl! These days I write more Racket and Elixir, but there's still a soft spot in my heart for Perl. I hope this will breath some fresh life into the language. I think it has a lot of interesting ideas about language design that new languages would do well to copy.
Perl is (in)famous for all the shortcuts possible in the language. While this does steepen the learning curve, I think there are some valuable ideas worth exploring. The implicit topic variable (`$_`) is super nice when throwing together a little script. The semantics are well laid-out in its documentation. I think an improvement would be to somehow make it more clear directly in the language itself where the topic variable is used. Maybe that's what I'll end up looking at in some research. :)
Lots of languages, I feel, optimize for readability for beginners. (I'm thinking about Python and Go here.) Perl is optimized for people familiar with the language. I think that can be a good thing, if done right. What do you guys think?
> PHP went directly from 5 to 7, and isn’t it time to steal something from that community?
:D
I love perl, so I’ll definitely spend some time tonight trying to find out more about the plans. From just this article, it’s hard to see how this is different than just making ‘use v5.34;’ flip some switches. That’s just business as usual in modern perl, even if it changed more things than normal. Still, if bumping the major version gets people to take another look at it, it will be a good thing. And maybe there are bigger plans post-7.0 and this is just to ease the initial move.
Great. Perl is not my favorite language, but the things its good at and the body of nifty code out there deserve more recognition than they get. Hopefully this will remove some of the discouragements to curiosity that have kept people from looking harder at perl to see if it fits their problems or their mind better than other tools.
I write perl professionally as of June 2020 (and I have been writing software in Perl since 1999). Never felt the need to use Python, or any other language for anything I do.
People who use my (mostly) Perl based software on AWS and GCP Marketplaces today are somewhat surprised and/or even taken aback when they find out it is written in Perl. So, I try not to mention that.
There used to be a big Python/Perl debate. I'm not sure I could have predicted how well that would turn out for Python, and how poorly for Perl. Readability and ease of use matters?
I worked on Perl for a while, liked it. Back in 2008/9, the only option for Perl on Windows was Activestate Perl, whose community version was missing lot of features that would have made it much less painful(I am thinking of PPM particularly). That was one of the biggest gripes I had with Perl. We moved everything to Python as soon as we could get comfortable with it and haven't looked back since.
Regarding Perl's one liners, I feel they are what makes Perl very useful, but my preference is AWK over Perl for that.
According to the Modern Perl author, Five things Perl (Still) Gets Right:
* Compatibility
* Quality
* Usability
* Scalability
* Availability
Are they still renaming Perl 6? I think it is a tad confusing to have 5 and 7 being so similar, and the 6 in between so radically different. I can't be the only one.
Just to be clear to everyone: this doesn't break anything. If you continue to use Perl version 5, you're fine. If you want to upgrade your major version of Perl, then of course you need to know what that means.
This is possibly a stupid comment, but I'd love a modern language whose expected lifetime is 100 years. A language whose specification details how it can be run for 100 years on changing hardware + operating systems, and is built with the least amount of, and easiest to perform, maintenance in mind.
Those languages kind of exist, but not expressly written as such. C will outlive us all.
You guys are just now getting to Perl 7? I'm already on Perl 11. http://perl11.org/
Developers in their forties wrote Perl. Developers in their thirties replaced Perl. Developers in their twenties say “What’s Perl?”
I'm trying to work this out but not having much luck - Perl 6 was a "lets make a bunch of breaking changes and modernize Perl a bit", and now that's branched off as a new language called Raku.
Now there's Perl 7, which is sort of the same idea as Perl 6 was, but less radical with the changes? Are the same people working on both? Is Larry involved with both?
I still use Perl every now and again for powerful one-liners and I'm really glad it's around. Here is a bash function I use which takes args and merges and deduplicates PATH-like expressions:
merge-args ()
{
perl -e 'print join ":", grep {!$h{$_}++} split ":", join ":", @ARGV' "$@"
}
export PATH="$(merge-args "${SCRIPT_DIR}"/clang-tidy-ex /usr/local/opt/llvm/bin "${INSTALL_DIR}"/{,samples/}bin "${PATH}")"
ASAN_OPTIONS="$(merge-args "${ASAN_OPTIONS}" detect_leaks=1 check_initialization_order=1 detect_stack_use_after_return=1 strict_init_order=1 strict_string_checks=1 detect_odr_violation=0)"
I had hope there would be a merging (with some compatibility layers and wrapper binaries) allowing to use Raku the same way Perl 5 was used (should not have been _that_ hard, just adding familiar options and special variables)... Now I'm seeing this goes in a total different direction.
To be on topic:
Perl7 is basically the idea to modernize saner settings by default. And breaking backcompat where it hurts. But it's far off a modern perl, like cperl is. They failed to fix the worst historical design mistakes. The hashes, the OO, types, @_, attrs before signatures (which was a major breaking change, but they excused themselves by claiming it was experimental), and many more.
https://github.com/perl11/cperl/issues/414
Instead they are breaking indirect method calls. Thanksfully this will be not POSIX, so nobody will use it.
This article touches on something that I really enjoyed about (the early days) of Perl 5, and I think it may body well for the future of the language.
You could write Perl 5 like it was just a better Perl 4. All of the craziness with modules and references was hidden to you if you wanted to write a Perl 4-esque script that needed to talk to a database or do something else that you could find a module in for in CPAN.
The people would wrote those modules, God help them, I don't know how they managed to write the executable line noise that was in the source, but I didn't care. I could get my job done with a few simple `use` statements.
This is great news! I was really excited about Perl 6, until I realized it was a different language, and it never quite jelled into a usable thing. So I kept using Perl 5. I write mostly modern Perl code, so this is exactly what I wanted.
I learned Perl back in the late 90's when it was the best way to do web programming. As a C programmer, it was a breath of fresh air. It was a higher-level C for me and I used it for prototyping all kinds of things before writing the production level C code. Nowadays, I still use it for system maintenance and prototyping. It's a great language and very powerful tool.
What project, if you were starting now from the scratch, would you use Perl for?
The proposed defaults are a good idea, and I hope some or most of 5.32 long standing experimental features become core features (or just go away entirely).
But I'm afraid that the badly needed core C code refactoring and restructuring is being left out, and that will make it very hard to introduce new features into the language.
I also had this secret hope that Perl 7 would be a tidier, simplified Perl 5 with little or no relation to Perl 6. Less confusing syntax would go in sync with the refactoring of the core to create a smaller language that could perform better and be easier for beginners to learn.
I've had to write some Perl in my latest project. Coming back to a language 20 years later at 37 years old was very interesting. I'm not a fan of the language but I can see why people like it.
The largest issue I've had is that even though the ecosystem gives you the ability to write code resembling best practices, I don't see a lot of Perl programmers that do it. Coming onto a project it didn't make sense to catch a whole team up on 20 years of best practices. So I went about writing code that would never be accepted on most of my other teams.
Perl 6 with parrot VM was expecting release in 2004, we had some portion of our code in perl. other portions were in php4. chose ruby due to rails announcement in 2004.
will wait for actual release will try on some pet project
Maybe someone here is the right person interested in this: I've been working on making Perl more suitable for functional programming[1]. This project still needs a lot of manpower to become something good. I need people to work with me on this, I won't continue alone. Please give me feedback about where I should be going with it, or tell me if you're interested in joining the effort.
I'm sorry if this offends. But a complete laypersons* perspective from someone who hasn't been keeping up on the current perl ecosystem is this: perl6 failed to the degree that perl 5 became perl 7, while all the perl programmers switched to ruby or python. Am I wrong?
*ok, not completely layperson, I used perl a lot a decade ago an have spent a week playing with raku at one point, but nothing in my professional life even has a slight smell of perl anymore, which is strange seeing as 90% of our company codebase was perl 15 years ago.
Wow, I haven't written any perl since
checks
5.27 pm today.
Thus the embarrassment of Perl 6 is erased from history.
Perl 5 was great. Written so many things in it. Looking forward to 7. Maybe time to start doing new things in perl?
Why does this happen so often to certain language version numbers? ECMAScript 4, PHP 6, and now Perl 6.
Perl is the swiss army knife of the shell. Works the same everywhere, it has always been reliable and superuseful for simple to medium scripts. It's the glue that keeps a lot of stuff together, and I'm happy it got back to its tracks after the v6 faux pas.
> > use utf8;
> there’s still much to be done to make Unicode the default
Why's that? If that's something someone with zero Perl experience can easily understand. Isn't this only about the source code? Or does this mean all strings are unicode?
People just keep wasting their precious lives on archaic stuff that has no future. Perl is dead. If these smart minds want to contribute to humanity, they should abandon this sunken ship and move to something more meaningful.
Perl5 was the first language in which I actually did some substantial projects. It was also heavily used in scientific computing (esp. genetics) until python came along.
Perl readability is rivaled only by c++ template code!
What is there to gain in calling it Perl 7? It seems needlessly disruptive, rather than just calling it 5.34 or whatever is next.
Need a comprehensive, up-to-date, yet brief, status of what happened to Perl 6 and where it stands in today's s/w tech.
Glad to hear it. Perl 6 was some kind of twisted complexity pornography.
This is fantastic news! I'm glad perl 5 is evolving again.
In some companies, they have huge projects written in Perl
Reasonable since "perl6" issue is solved. Everyone may move forward.
Perl is alive!
After a million years, it is finally out!
Finally!
tl;dr - Perl 7.0 is going to be v5.32 but with different, saner, more modern defaults.
Perl was great 20 years ago for basic scripts. Where is it still used today who hasn't transitioned to Python/etc?
This is just bad maintenance. Just pick all the stuff people are complaining about and fix it!
1. Improve threads
2. Improve C API support
3. Give local::lib, cpanm by default ... multiple perl versions by default
4. Give direct support for coroutines / async await
5. Mark experimental features as non-experimental (attributes, signatures)
6. Pick an OO system, package system
7. Make switch cool again
8. Get more core modules or remove some. Give more visibility to cool perl modules. like PDL or something.
9. Improve GUI toolkit, Web Deployment and Web Assembly support
10. Improve look and feel of community sites
Heck break some backwards compatibility with Perl4, get rid of format.
sub foolOnce() { return raku(); }
sub foolTwice() { return perl5(); }
Amazing. I literally first installed this on my laptop over 10 years ago. (Using Parrot)
This feels like a last ditch attempt to save a dying language. (https://i.imgflip.com/4676mf.jpg) I wonder what exactly does Perl bring to the table as a language, why would one consider choosing it over other languages.
I've been a perl zealot since 2005. I didn't even know "python" existed until around 2008 when I found a script file with a ".py" file ending in a fresh ubuntu install. I started going to perl conferences sometime after 2010 when someone on irc informed be about them. I learned so much in those conferences, mainly about the alternatives to cgi and the modern OOP "framework" named "moose". I thought I was in heaven.
I landed my first devops position around the 2010 era as well and being the only one on the team that really knew how to "program", I spammed out tons of perl scripts and web apps. A few years later one of the newer employees on the customer support team started spouting off about "python" and how it was so easy to learn. He was always blabbing about terms I'd never heard of like "generators", "list comprehensions", "decorators", etc. I looked them up and learned they were just abstract constructs with fancy names that are supported in most any language. So I just figured he was some idiot that didn't really know anything. Otherwise, why would you be blabbing about abstract constructs? He quickly landed a job at google and I left and started freelancing only picking up perl jobs. Because perl was "dying" and this being after 2012, there were several companies with large perl bases that couldn't find local employees so were forced to allow remote workers.
This is where stuff started going wrong. I went through many jobs/gigs my first couple of years. I quickly noticed that companies that had large perl code bases were all founded pre-2005. This meant it was crap perl, in most cases not even using CPAN but having home grown ORM's and web frameworks and a scrict hate of javascript. So it mostly sucked and was slow going. In one case I was literally fired after a couple of months from this one company that specialized in phone billing accounting software (all perl powered) because I was "too slow". The owner told me he should have never hired someone with less than fifteen years experience with perl and bid me farewell. I almost busted out laughing as for the entire two months I was only doing javascript front end work since the other perl guys there hate javascript. Even the owner of the company had no clue how his own software worked. This was a theme that repeated it self else where as well.
Fast forward a few more years and I had landed a good remote job, still in perl but offered more freedom in the dev cycle. I got good with react and vue.js as it greatly speed up the dev time for all the heavy interactive apps I was tasked with. But I continued to struggle against others in the perl community. I can understand how a 50 year old perl dev (the typical age) would hate javascript and instead put as much code in the back end using all kinds of horrid html templates and never ending form post/refresh/repopulate cycles... I can see the "why should I learn javascript if i know perl" ideology, but what blew me away is a constant "why should I learn SQL if I know perl" ideology. Yes I'm serious. In so many other cases devs were fine with just doing "select *" on tons of tables and stuffing all that in a hash/dictionary of column name matching keys. Databases were big, scripts and page load times would grow to minutes or even hours. Sometimes exhausting the machine's ram and crashing everything. Everyone was fine with it, management just acted like it's how things work. Meanwhile as a co-worker, I'm left digging through pages of perl code that could have just been a single SQL query trying to figure out why some numbers are wrong in an invoice report. It was a continual issue.
Another issue is just the bit rot of cpan. The ORM and drivers for both postgresql and sqlite don't even support most of the features added in those systems since 2014. So even though postgresql is the most advanced DB out there, you are stuck with no ability to use any of the fancy native array or json types or even the "natural" join syntax (and many other things), neither good support for foreign keys in sqlite either.
I've thrown my hands up and jumped ship. It's sad too. I liked many in the community and like Larry Wall as well and have had dinner with him on several occasions. But I can't keep my sanity and stay with perl. I can read perl fine, it is not the notorious "write only" language that many troll it to be. But the issue is the community and those using perl daily are fine with being stuck in 1995. Larry Wall stopped adding features to perl in 2002 (?) and moved to perl 6 which.... well how do you even describe that? The point is, perl has been the same since 2002, mean while python has had continual development and features added every year since then. I'm just done.