by datanut on 6/24/20, 3:57 PM with 562 comments
by py_or_dy on 6/24/20, 8:30 PM
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.
by sumanthvepa on 6/24/20, 4:44 PM
by banana_giraffe on 6/24/20, 4:31 PM
> 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.
by cafard on 6/24/20, 6:13 PM
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.
by Ovid on 6/24/20, 6:09 PM
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.
by CJefferson on 6/24/20, 4:33 PM
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.
by jwr on 6/24/20, 5:55 PM
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.
by Scarblac on 6/24/20, 7:29 PM
print "It worked!\n" unless $error;
print "Item: $_\n" foreach @items;
by ashton314 on 6/24/20, 6:28 PM
perl -e 'print int rand(10);'
Good times. Good times. :)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?
by nchelluri on 6/24/20, 4:34 PM
:D
by richard_todd on 6/24/20, 4:39 PM
by h2odragon on 6/24/20, 4:33 PM
by eruci on 6/24/20, 9:58 PM
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.
by Upvoter33 on 6/24/20, 4:42 PM
by oarla on 6/24/20, 6:39 PM
Regarding Perl's one liners, I feel they are what makes Perl very useful, but my preference is AWK over Perl for that.
by fmakunbound on 6/24/20, 5:07 PM
* Compatibility
* Quality
* Usability
* Scalability
* Availability
by ksaj on 6/24/20, 5:56 PM
by Ovid on 6/24/20, 4:37 PM
by peterwwillis on 6/24/20, 5:28 PM
Those languages kind of exist, but not expressly written as such. C will outlive us all.
by EricRiese on 6/24/20, 7:34 PM
by OakNinja on 6/24/20, 5:41 PM
by p1necone on 6/25/20, 1:07 AM
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?
by gkfasdfasdf on 6/24/20, 7:53 PM
merge-args ()
{
perl -e 'print join ":", grep {!$h{$_}++} split ":", join ":", @ARGV' "$@"
}
And I use as follows: 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 know there are other ways of doing this in other languages and even in bash itself, but to me this is simple and elegant.by henearkr on 6/24/20, 7:47 PM
by rurban on 6/25/20, 5:53 AM
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.
by edw on 6/24/20, 10:22 PM
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.
by tolger on 6/24/20, 8:37 PM
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.
by elchin on 6/24/20, 5:41 PM
by ojosilva on 6/24/20, 10:58 PM
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.
by mrits on 6/24/20, 6:15 PM
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.
by senthilnayagam on 6/24/20, 6:13 PM
will wait for actual release will try on some pet project
by pflanze on 6/24/20, 11:21 PM
by jVinc on 6/24/20, 9:48 PM
*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.
by iso1631 on 6/24/20, 7:10 PM
checks
5.27 pm today.
by Animats on 6/24/20, 8:44 PM
by rad_gruchalski on 6/24/20, 9:35 PM
by jasonhansel on 6/24/20, 11:05 PM
by qalmakka on 6/24/20, 6:32 PM
by rplnt on 6/24/20, 6:18 PM
> 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?
by newshhh on 6/24/20, 7:59 PM
by sabujp on 6/25/20, 12:09 AM
by srathi on 6/24/20, 4:59 PM
by adenozine on 6/24/20, 7:30 PM
by fizixer on 6/24/20, 5:03 PM
by classics2 on 6/25/20, 3:01 AM
by odc on 6/25/20, 6:29 AM
by _____smurf_____ on 6/24/20, 6:31 PM
by qbaqbaqba on 6/24/20, 6:34 PM
by markstos on 6/24/20, 6:35 PM
by frjalex on 6/24/20, 5:19 PM
by rodrigo975 on 6/24/20, 10:03 PM
by r00fus on 6/24/20, 4:44 PM
Perl was great 20 years ago for basic scripts. Where is it still used today who hasn't transitioned to Python/etc?
by foobar_ on 6/24/20, 5:14 PM
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.
by billman on 6/24/20, 5:35 PM
sub foolTwice() { return perl5(); }
by polynomial on 6/24/20, 6:48 PM
by bhaavan on 6/24/20, 4:40 PM