I'm an author on CPAN who pushes one or two releases a month[1]. I'm actually surprised the number of uploads is still as high as it is, and a few thoughts struck me about the graph:
1) Most long time libraries have pretty much reached stability and the (still relatively high) backwards compatibility promise of perl5 means they don't have to be updated to support changes in the language, which still has releases every year.
2) The quality of uploads to CPAN is of the form of solving more complex problems or interfacing with core Unix/network/internet/lower level lib stuff stuff - you don't see so much of the leftpad type modules on CPAN.
3) It definitely feels like the number of authors has shrunk significantly, even though the graph suggests that has stayed relatively level. I suspect there's a long tail of active authors and most signups never actually upload anything
4) The biggest problem now is finding modules for newer APIs - I wrote some, including for more well known services such as GoCardless and Monzo
5) Holy crap, the graph covers almost 24 years of uploads. You will probably see the same pattern in Python, JS, Go, and so on if you come back in an equivalent number of years - the most common problems get solved first, and libraries uploaded for those.
6) The graph covers uploads to CPAN, I'd guess a far more important one would be downloads from CPAN as that will probably give you more information about the relative level of use of the language.
There's so much negativity in this thread. I think that a big part of Perl's decline is exactly because of people's attitudes. I don't actually write any Perl now, but to me it's a beautiful language, I always enjoy working in it. You can abuse it in the wrong way like every other language. If I was to suggest using it in the day job there would be uproar probably. But just because I like Perl doesn't mean I want to write everything in it, use the best tool for the job and sometimes the best tool is Perl.
Yes, thank you. Perl was an absolute earth-shaker back in it's day. Even still it's a fantastic language for string manipulation. Much of Ruby's beauty, expressability, and powerful string processing is thanks to inspiration from Perl. It's disappointing to see people crapping on such a venerable language.
Prel is great and has an important role, even today.
That being said, I'm a professional dev and we own a decent amount of perl. That codebase is by far the most difficult to work in out of anything we own. New hires have trouble with it (nobody learns perl these days). Lots of it is next to unreadable.
I agree that like any other language, perl can be written well and can be written poorly. That being said, perl makes it _really_ easy to write something poorly, in contrast to something like python which is a bit more rigid and tries to have one right way to do things.
I still use perl pretty extensively for little one liners, but at this point we are actively trying to get rid of as much perl that we own as possible. We find that rarely writing anything longer than 10 lines should be done in perl, if only from a readability and maintainability standpoint.
I love perl. It was THE game changer for many many years. But perl is falling out of fashion quick.
I'd have no problem working in the language with some very rigid guidelines and a bunch of experts.
But the reality is that nobody is hiring perl experts, perl experts are becoming more and more scarce, and most new hires have a bit of experience with py or rb. I dont dislike perl, I'd just argue it's almost always the wrong thing tool for the job these days.
In a previous life I worked at a large E commerce company. You've likely ordered from them. Pretty much everything ran on perl/perl Mason for over a decade. At that time perl was the cool new thing that everyone wanted to pick up. Now (or when I left a few years back), most of that code represented a liability if it needed to be changed.
IMO this is just the cycle of a programming language.
I remember reading Spolsky articles where he talks about VB6 like it's some shiny new amazing scripting language, akin to python 10 or so years ago. But alas, time moves on and so do most programmers.
I work on a large, legacy codebase (the oldest modules date from the mid-nineties) that's slowly being rewritten from Perl into Python. A handful of developers have been involved with the project from the beginning. Looking at the long term contributors, readable or un-readable code seems to be more about the person than the language. Unsurprisingly, the person who produced the most unreadable, unmaintainable code is now doing the same in a new Python only project.
I've always tried to look at programming in a similar manner as writing research papers, your ideas are no good if no one understands how they're put to paper. Explicitly stating your intentions is better than assuming the reader knows the subject matter. If something is clever, overly-compact or your reviewer expresses confusion, rewrite it or at least spend an extra line or two in explanation.
At the language level, I miss Perl's handling of regexps and shell commands (which consist of large amounts of this codebase). Python requires a fair amount of overhead to handle both and always feels a little clunky. While I'm far more fluent in Python, I typically reach for Perl when needing to quickly handle log files, automate shell tasks, and prototype ideas. On the flip side, now that Python supports type hinting, function signatures are much more valuable, and overall I feel I can write far more robust tests in Python than Perl. Given that the direction of the project is to move from a collection of one-off scripts that just kept on growing to a tested, maintainable, modular codebase, Python is the better choice.
> Looking at the long term contributors, readable or un-readable code seems to be more about the person than the language. Unsurprisingly, the person who produced the most unreadable, unmaintainable code is now doing the same in a new Python only project.
I would totally agree.
I learned Perl after first learning Basic(and Visual Basic) then Java.
Coming from Java meant that I always tried to use clear variable names, good comments, broke my code into small and simple functions etc. I repeatedly had people say to me "Wow! I didn't know you could do that in Perl!"
A lot of Perl's bad reputation came from sysadmins and other busy folks who either weren't familiar with good syntax or were in a hurry and basically were playing Perl Golf to get things done quickly. This is probably where the line "Perl is a write only language" came from.
I will concede that Python and it's forced indenting leads to much easier to read code for beginners. That being said, trying to understand what's going on with advanced Pandas usage written by Numpy wizards is no walk in the park either.
I also totally agree that the Perl one liner is still my go to even though I do everything else in Python these days.
> Looking at the long term contributors, readable or un-readable code seems to be more about the person than the language.
The biggest problem I have with Perl is like C++, the language is so stupidly big that every single programmer knows a different subset of the language.
I used to bump into this problem when I was interviewing for VLSI jobs and somebody would always do the "Let's talk about Perl" round. I was quite fluent at Perl at the time, and there would ALWAYS be some idiom that would stump me.
I solved this by bringing my own Perl program on a printout with me--I also brought the Python version of the same program with me. Suddenly, the interviewer was in MY subset of Perl and almost always went "Oh, you're a lot better at Perl and programming than I am" instead of dinging me for not knowing weird Perl trivia.
I still use perl for handy one liners on the command line. E.g. I had a 1 GB log file where I wanted to generate a histogram of the intervals between certain log messages. I used a perl one-liner to extract the timestamp via regex (regexs are perl's bread and butter), calculate the diff between the previous timestamp (easy because of auto string => double conversion), use the diff value as a key in a hash of counters (autovivification really handy here), then print the hash at the end with sorted keys using the Data::Dumper module. Took me all of 5 minutes to write. I don't write Perl often but I am thankful that it exists.
I'm an occasional perler myself and I bet that others or myself would find that code you mention to be useful, at least for the black book of snippets. Would you mind pasting?
From a experienced linux sysadmin point of view perl5 is as good as it gets.
I've been searching for alternatives for about 10 years now, at first because my novice self was heaving headaches reading other people code and even my own. I hated perl but I hated everything else even more as I came to know them. No autovivification? Some assignments copy the data and some create references and you need to memorize the conventions of which does what? 3x to 10x lower performance? My program crashes because of white space? Fuck that! Back to perl5.
I'm sorry to say nothing can replace perl5 for me even now in 2019. I wish something would come along even if it takes years. We need alternatives and competition, perl5 will get too old at some point and 6 is... I don't even want to go there.
I've just written a utility I needed in Perl. I tend to think about some things in the long term, and this utility is something I want to be able to run 10 years from now.
[it's a concistency checker (hasher) for file archives, to find out if the bits in your copy are really the ones you put there, important for multi-GB photo archives — see https://github.com/jwr/ccheck]
I do most of my programming in Clojure, which has excellent backwards compatibility and takes a long-term perspective. I still run some unmodified Clojure code from 8 years ago. And yet for really long term stuff, I would much rather write it in Perl. It has been around for a very long time, is very mature, and can be expected to last, even if it isn't the latest fashionable trend.
Take a look at the various programming languages+environments around you: there will be very few where you can expect to be able to run your code even 2-3 years from now, much less decades later.
These are for third-party packages though, Perl might be perfect but the rest of the software world not so much... That dwindling number of submissions not only means that new libraries are not being integrated as fast as they should but also, and perhaps more importantly, existing libraries are not updated.
It's pretty sad too because I distinctly remember that one of the main selling points of Perl when I started using it in the early 2000's was that CPAN was more complete and diverse than any other scripting language out there.
This is exactly the same reason that they stopped updating Microsoft DOS -- they achieved perfection. That or it become obsolete. I guess it depends on to what degree one is nostalgic and to what degree one needs to keep their skills up to date.
No languages are casual. I wrote Perl for about 5 years and was super productive with, but haven't looked it for quite a while. Most energy these days goes into JavaScript/node and it devolves into gibberish really, really quickly. The community really dove into the punctuation-based syntax, preprocessors and meta languages head first and created a real Frankenstein. And they'll complain that Java or C# are too verbose and slow to work with.
I've been writing Pascal and Delphi for more than 25+ years and C and C++ for around 20 years and a bunch of other languages for at least a decade, yet even with the tons of additions that Free Pascal has added over the years i always find Pascal code way more readable than C or (especially) C++ code. It helps that the Free Pascal developers try to keep the syntax for new stuff "Pascal-ish".
I've been coding in Perl for 20 years, I'm a CPAN author [1] and I just published my third CPAN contribution yesterday.
I've written over half a million Perl lines of currently in use enterprise cloud software[2] and I'll keep coding in Perl because I don't like the big snake dictatorship of "There should be one — and preferably only one — obvious way to do it."
I used Perl for a bit but switched to Python because I was finding it harder to work out what some code I'd written a year or so ago did than to write it again, a problem I don't have with Python.
I used Perl for many years, and still do. My bias is now toward Python for scripting, because the young all seem to know Python. But for example to write a script to be run on Linux that will talk to SQL Server, I will use Perl, since DBD:Sybase works, and I don't feel like fussing around to find and configure a Python equivalent.
I miss Perl. I love Perl still and would reach for it for any project I could. That said, I switched to Python because going into recent interviews and doing the white board or online assessment, Perl isn't necessarily an option. At least it's not a popular option. I do miss Perl and will happily without shame admit it.
It's interesting. I started Perl in around 2005, and moved entirely to Python in 2014, exactly when it reached it's peak and started to decline. Seems I wasn't the only one.
I think Perl was fighting on too many fronts at the turn of the century: web, systems automation, data processing, science and a few more. Today these areas are better covered by other languages that have hefty internet buzz and corporate support behind.
Perl also has no shiny features. It's just extremely dynamic and paradigm agnostic, great at shell interactions and natural at text processing (specially with regexes), good enough at binding C/C++ libraries, has package management built-in (CPAN) and an automated testing culture. Perl basically set the baseline for a lot of today's languages.
Perl5 devs put a lot of focus on making Perl even more dynamic during the 2000s, relying on CPAN/community to fix language quirks and plug in novelties. It worked to some extent, Perl got to the point where it could be written like Haskell, Ruby... During that time it also got a powerful but optional class system (Moose) and reinvented itself as a web language (Mojolicious, Plack).
Unfortunately it all came too late, most Perl5 devs moved to something else or maintained Perl5 code frozen in legacy mode. Fewer and fewer started new projects using Perl. For instance, nowadays I tend to pick a language/ecosystem pair based on these concerns first depending on what the job requires:
- asynchronous event processing, specially network related -- I pick JavaScript/Node.
- real parallel processing and highly performant systems, I'd use Go.
- "we got a package for that" -- Python or JS at the forefront here. It depends on what package I'll need for the job, typically it's not going to be in CPAN.
- great code reuse/portability -- to me JS wins here. And still the only single language for both server and browser.
- compiled hard-packaged binaries: Go, but also Rust, Elixir, Nim, and others can fit the bill.
- code style and paradigm -- a very personal choice, I think Typescript and ES2019 are both great here. Golang and others are also great if I feel like staying away away from OO.
Perl would have a hard time competing in any of these fronts, but it still is one of the greatest for practical extraction and reporting, text or database wise and easily available or pre-installed on many servers out there new and old.
> web, systems automation, data processing, science and a few more.
doesn't this apply to python, although now there are additional competitors?
> reinvented itself as a web language (Mojolicious, Plack).
highly opinionated and potentially flame creating , but -
perl was the original web language in the CGI era, PHP pretty much dethroned it due to simplicity of server integration, rails knocked them both out of 'leading edge', then the Node/SPA era arrived.
mojolicious / plack are pretty much things to bring perl up to date w/r/t the 'rails' type
This september 2012 release was kinda huge for me. It brought venv, generator expressions (event loops) a-la nodejs at the time, sped up a lot of things as well. It was a great release and a step in the right direction. Perl6 was still a myth at the time.
I did not start using python3 until last year, but I was aware it was evolving quickly to one day become usable.
Perl is good for a competent coder who doesn't work as a developer,
occasionally has a one-off coding task, and wants to incorporate a
code excerpt from the web and immediately execute it (and then throw
the code away). Languages with whitespace as syntax often fail the
"immediately execute" requirement.
I actually used Perl last week to whip up two scripts (csv2insert and csv2update) to automate converting CSV files to MSSQL-specific SQL insert/update scripts (respectively). Microsoft's own CSV import tools suck, and it was pretty straightforward to use Text::CSV and print() a bunch of SQL lines.
I'd need to do some more polishing before putting it up on GitHub or something (namely: sanitize incoming single-quotes in CSV cells, and possibly break the steps into subroutines), but I was yet again impressed by the ability to automate a bit of text data processing with less than an hour's work.
I assume you already knew and don't wish to change client -which is fair enough- Weechat supports Python and Ruby in addition to Perl.
I remember the time before Irssi, when even CLI clients regularly had remotely exploitable vulnerabilities in them (including the 1337 BitchX). Irssi was programmed with safety in mind. Either way, scripts increase attack surface.
I'm not using IRC clients right now (I quit after realizing more than 50 windows open isn't productive), but I really love both Irssi and Weechat's interface (including default themes) and CLI. Did have to finegrain the configs but the same's true about nearly any application these days.
Perl is a prerequisite for Autoconf as well (not for the generated configure scripts though, thankfully). It would be nice to not have that dependency.
irssi has support for perl, python, js, tcl and lua(very alpha)
https://irssi.org/modules/
None of those other modules are as featureful as the perl module and are looking for people who are interested in developing them further :)
I have a crontab that runs every five minutes: 30 lines that use one CPAN module, no bugs in years. The code has the kind of hackiness that's okay when it fits on one screen, and it fits on one screen precisely because of that hackiness.
Perl more than any other language I know depends on the self-restraint of the programmer to write readable code and not be overly clever with their syntax. I’ve worked on some large Perl codebases in the past that were as readable and maintainable as, say, Python.
I agree that they are terrible, but not all programming is large code-bases. I think Perl is good for its originally intended use as a high-level scripting language.
Perl aims to be an enabler, and is therefore not particularly opinionated ("there is more than one way to do it"). This includes making little to no effort to make it hard to write difficult-to-read code.
Personally, I don't tend to have a hard time reading code I myself wrote, even long after the fact. But I will concede that Perl code _can be_ hard to read if the author has been too clever.
"too clever constructions which feel smart at the time you come up with them"
That's the coder, not the language.
Which is more obvious what's happening.
print ''.join('%(pre)s%(num)s %(bot)s on the wall, %(nul)s %(bot)s,\n%(tak)s\n' % (lambda c,b: {'pre':['','%s %s on the wall.\n\n' % (c,b)][abs(cmp(c,'Ninety-nine'))], 'num':c, 'nul':c.lower(), 'bot':b, 'tak':['Go to the store and buy some more... Ninety-nine %s.' % b,'Take one down, pass it around,'][abs(cmp(x,0))] })((lambda x,o: [(['Twenty','Thirty','Forty','Fifty', 'Sixty','Seventy','Eighty','Ninety'][x/10-2]+'-'+o.lower()).replace('-no more',''), o][int(x<20)])(x, ['No more','One','Two', 'Three','Four','Five','Six','Seven','Eight', 'Nine','Ten','Eleven','Twelve','Thirteen','Fourteen', 'Fifteen','Sixteen','Seventeen','Eighteen','Nineteen'][[x,x%10][int(x>=20)]]),'bottle%s of beer' % ['','s'][abs(cmp(x,1))]) for x in xrange(99,-1,-1))
Or
my $firstline = 1;
my @tens = qw/Ninety Eighty Seventy Sixty Fifty Forty Thirty Twenty/;
my @teens = qw/Nineteen Eighteen Seventeen Sixteen Fifteen Fourteen Thirteen Twelve Eleven Ten/;
my @ones = qw/Nine Eight Seven Six Five Four Three Two One/;
sub go {
my $num = shift;
my $bottles = "bottles";
if ($num eq "One") {
$bottles = "bottle";
}
if ($firstline == 0) {
print "$num $bottles of beer on the wall.\n";
print "\n";
}
$firstline = 0;
print "$num $bottles of beer on the wall, ".lc($num)." $bottles of beer,\n";
print "Take one down, pass it around,\n";
if ($num eq "One") {
print "No more bottles of beer on the wall.\n";
print "\n";
}
}
foreach my $ten (@tens) {
foreach my $one (@ones) {
go("$ten-".lc($one));
}
go($ten);
}
foreach my $teen (@teens) {
go($teen);
}
foreach my $one (@ones) {
go($one);
}
print "No more bottles of beer on the wall, no more bottles of beer,\n";
print "Go to the store and buy some more... Ninety-nine bottles of beer.\n";
print "\n";
People can do clever things in either language, people can write clear code in either language.
leejo|6 years ago
1) Most long time libraries have pretty much reached stability and the (still relatively high) backwards compatibility promise of perl5 means they don't have to be updated to support changes in the language, which still has releases every year.
2) The quality of uploads to CPAN is of the form of solving more complex problems or interfacing with core Unix/network/internet/lower level lib stuff stuff - you don't see so much of the leftpad type modules on CPAN.
3) It definitely feels like the number of authors has shrunk significantly, even though the graph suggests that has stayed relatively level. I suspect there's a long tail of active authors and most signups never actually upload anything
4) The biggest problem now is finding modules for newer APIs - I wrote some, including for more well known services such as GoCardless and Monzo
5) Holy crap, the graph covers almost 24 years of uploads. You will probably see the same pattern in Python, JS, Go, and so on if you come back in an equivalent number of years - the most common problems get solved first, and libraries uploaded for those.
6) The graph covers uploads to CPAN, I'd guess a far more important one would be downloads from CPAN as that will probably give you more information about the relative level of use of the language.
[1] https://metacpan.org/author/LEEJO
roryrjb|6 years ago
freedomben|6 years ago
cheeze|6 years ago
That being said, I'm a professional dev and we own a decent amount of perl. That codebase is by far the most difficult to work in out of anything we own. New hires have trouble with it (nobody learns perl these days). Lots of it is next to unreadable.
I agree that like any other language, perl can be written well and can be written poorly. That being said, perl makes it _really_ easy to write something poorly, in contrast to something like python which is a bit more rigid and tries to have one right way to do things.
I still use perl pretty extensively for little one liners, but at this point we are actively trying to get rid of as much perl that we own as possible. We find that rarely writing anything longer than 10 lines should be done in perl, if only from a readability and maintainability standpoint.
I love perl. It was THE game changer for many many years. But perl is falling out of fashion quick.
I'd have no problem working in the language with some very rigid guidelines and a bunch of experts.
But the reality is that nobody is hiring perl experts, perl experts are becoming more and more scarce, and most new hires have a bit of experience with py or rb. I dont dislike perl, I'd just argue it's almost always the wrong thing tool for the job these days.
In a previous life I worked at a large E commerce company. You've likely ordered from them. Pretty much everything ran on perl/perl Mason for over a decade. At that time perl was the cool new thing that everyone wanted to pick up. Now (or when I left a few years back), most of that code represented a liability if it needed to be changed.
IMO this is just the cycle of a programming language.
I remember reading Spolsky articles where he talks about VB6 like it's some shiny new amazing scripting language, akin to python 10 or so years ago. But alas, time moves on and so do most programmers.
unknown|6 years ago
[deleted]
hobojones|6 years ago
I've always tried to look at programming in a similar manner as writing research papers, your ideas are no good if no one understands how they're put to paper. Explicitly stating your intentions is better than assuming the reader knows the subject matter. If something is clever, overly-compact or your reviewer expresses confusion, rewrite it or at least spend an extra line or two in explanation.
At the language level, I miss Perl's handling of regexps and shell commands (which consist of large amounts of this codebase). Python requires a fair amount of overhead to handle both and always feels a little clunky. While I'm far more fluent in Python, I typically reach for Perl when needing to quickly handle log files, automate shell tasks, and prototype ideas. On the flip side, now that Python supports type hinting, function signatures are much more valuable, and overall I feel I can write far more robust tests in Python than Perl. Given that the direction of the project is to move from a collection of one-off scripts that just kept on growing to a tested, maintainable, modular codebase, Python is the better choice.
alexpotato|6 years ago
I would totally agree.
I learned Perl after first learning Basic(and Visual Basic) then Java.
Coming from Java meant that I always tried to use clear variable names, good comments, broke my code into small and simple functions etc. I repeatedly had people say to me "Wow! I didn't know you could do that in Perl!"
A lot of Perl's bad reputation came from sysadmins and other busy folks who either weren't familiar with good syntax or were in a hurry and basically were playing Perl Golf to get things done quickly. This is probably where the line "Perl is a write only language" came from.
I will concede that Python and it's forced indenting leads to much easier to read code for beginners. That being said, trying to understand what's going on with advanced Pandas usage written by Numpy wizards is no walk in the park either.
I also totally agree that the Perl one liner is still my go to even though I do everything else in Python these days.
daotoad|6 years ago
Recent Perl versions have function signatures.
Have you tried the Test2 test suite? It’s a tremendous improvement over the previous system.
Type::Tiny is an amazing library that provides a rather nice type system.
bsder|6 years ago
The biggest problem I have with Perl is like C++, the language is so stupidly big that every single programmer knows a different subset of the language.
I used to bump into this problem when I was interviewing for VLSI jobs and somebody would always do the "Let's talk about Perl" round. I was quite fluent at Perl at the time, and there would ALWAYS be some idiom that would stump me.
I solved this by bringing my own Perl program on a printout with me--I also brought the Python version of the same program with me. Suddenly, the interviewer was in MY subset of Perl and almost always went "Oh, you're a lot better at Perl and programming than I am" instead of dinging me for not knowing weird Perl trivia.
gkfasdfasdf|6 years ago
markoman|6 years ago
_rrnv|6 years ago
trabant00|6 years ago
I've been searching for alternatives for about 10 years now, at first because my novice self was heaving headaches reading other people code and even my own. I hated perl but I hated everything else even more as I came to know them. No autovivification? Some assignments copy the data and some create references and you need to memorize the conventions of which does what? 3x to 10x lower performance? My program crashes because of white space? Fuck that! Back to perl5.
I'm sorry to say nothing can replace perl5 for me even now in 2019. I wish something would come along even if it takes years. We need alternatives and competition, perl5 will get too old at some point and 6 is... I don't even want to go there.
jwr|6 years ago
I've just written a utility I needed in Perl. I tend to think about some things in the long term, and this utility is something I want to be able to run 10 years from now.
[it's a concistency checker (hasher) for file archives, to find out if the bits in your copy are really the ones you put there, important for multi-GB photo archives — see https://github.com/jwr/ccheck]
I do most of my programming in Clojure, which has excellent backwards compatibility and takes a long-term perspective. I still run some unmodified Clojure code from 8 years ago. And yet for really long term stuff, I would much rather write it in Perl. It has been around for a very long time, is very mature, and can be expected to last, even if it isn't the latest fashionable trend.
Take a look at the various programming languages+environments around you: there will be very few where you can expect to be able to run your code even 2-3 years from now, much less decades later.
simias|6 years ago
It's pretty sad too because I distinctly remember that one of the main selling points of Perl when I started using it in the early 2000's was that CPAN was more complete and diverse than any other scripting language out there.
mirceal|6 years ago
tanilama|6 years ago
bhouston|6 years ago
nkozyra|6 years ago
As a comparison, I peeked at some Delphi/pascal code I'd written and a book a few weeks back and it was still parseable by my brain years later.
tootie|6 years ago
badsectoracula|6 years ago
eruci|6 years ago
I've been coding in Perl for 20 years, I'm a CPAN author [1] and I just published my third CPAN contribution yesterday.
I've written over half a million Perl lines of currently in use enterprise cloud software[2] and I'll keep coding in Perl because I don't like the big snake dictatorship of "There should be one — and preferably only one — obvious way to do it."
[1] https://metacpan.org/author/ERUCI
[2] https://aws.amazon.com/marketplace/seller-profile?id=434e986...
MichaelMoser123|6 years ago
That is a python design principle https://en.wikipedia.org/wiki/Zen_of_Python
Now there are multiple (sometimes very confusing) ways to import stuff in python, so I am not quite sure if this principle is being followed.
https://realpython.com/absolute-vs-relative-python-imports/
iamnotacrook|6 years ago
isostatic|6 years ago
1) Works
2) Is ubiquitous
3) Is stable
4) Is normal (semicolons, braces etc)
cafard|6 years ago
b3b0p|6 years ago
fmajid|6 years ago
[deleted]
tus88|6 years ago
INTPenis|6 years ago
Before that I was a huge Perl fan. I even ran a localized version of perl.cctld in my country. With documentation in our local language.
latchkey|6 years ago
ojosilva|6 years ago
Perl also has no shiny features. It's just extremely dynamic and paradigm agnostic, great at shell interactions and natural at text processing (specially with regexes), good enough at binding C/C++ libraries, has package management built-in (CPAN) and an automated testing culture. Perl basically set the baseline for a lot of today's languages.
Perl5 devs put a lot of focus on making Perl even more dynamic during the 2000s, relying on CPAN/community to fix language quirks and plug in novelties. It worked to some extent, Perl got to the point where it could be written like Haskell, Ruby... During that time it also got a powerful but optional class system (Moose) and reinvented itself as a web language (Mojolicious, Plack).
Unfortunately it all came too late, most Perl5 devs moved to something else or maintained Perl5 code frozen in legacy mode. Fewer and fewer started new projects using Perl. For instance, nowadays I tend to pick a language/ecosystem pair based on these concerns first depending on what the job requires:
- asynchronous event processing, specially network related -- I pick JavaScript/Node.
- real parallel processing and highly performant systems, I'd use Go.
- "we got a package for that" -- Python or JS at the forefront here. It depends on what package I'll need for the job, typically it's not going to be in CPAN.
- great code reuse/portability -- to me JS wins here. And still the only single language for both server and browser.
- compiled hard-packaged binaries: Go, but also Rust, Elixir, Nim, and others can fit the bill.
- code style and paradigm -- a very personal choice, I think Typescript and ES2019 are both great here. Golang and others are also great if I feel like staying away away from OO.
Perl would have a hard time competing in any of these fronts, but it still is one of the greatest for practical extraction and reporting, text or database wise and easily available or pre-installed on many servers out there new and old.
cat199|6 years ago
doesn't this apply to python, although now there are additional competitors?
> reinvented itself as a web language (Mojolicious, Plack).
highly opinionated and potentially flame creating , but -
perl was the original web language in the CGI era, PHP pretty much dethroned it due to simplicity of server integration, rails knocked them both out of 'leading edge', then the Node/SPA era arrived.
mojolicious / plack are pretty much things to bring perl up to date w/r/t the 'rails' type
nurettin|6 years ago
I did not start using python3 until last year, but I was aware it was evolving quickly to one day become usable.
https://docs.python.org/3/whatsnew/3.3.html
rurcliped|6 years ago
TylerE|6 years ago
yellowapple|6 years ago
I'd need to do some more polishing before putting it up on GitHub or something (namely: sanitize incoming single-quotes in CSV cells, and possibly break the steps into subroutines), but I was yet again impressed by the ability to automate a bit of text data processing with less than an hour's work.
gpvos|6 years ago
peteretep|6 years ago
eikenberry|6 years ago
chihuazhang|6 years ago
[deleted]
FranOntanaya|6 years ago
Fnoord|6 years ago
I remember the time before Irssi, when even CLI clients regularly had remotely exploitable vulnerabilities in them (including the 1337 BitchX). Irssi was programmed with safety in mind. Either way, scripts increase attack surface.
I'm not using IRC clients right now (I quit after realizing more than 50 windows open isn't productive), but I really love both Irssi and Weechat's interface (including default themes) and CLI. Did have to finegrain the configs but the same's true about nearly any application these days.
sebcat|6 years ago
vague_irssi|6 years ago
Audiophile65|6 years ago
nopacience|6 years ago
[deleted]
foobar_|6 years ago
mattbillenstein|6 years ago
Arnt|6 years ago
I have a crontab that runs every five minutes: 30 lines that use one CPAN module, no bugs in years. The code has the kind of hackiness that's okay when it fits on one screen, and it fits on one screen precisely because of that hackiness.
avian|6 years ago
gnode|6 years ago
l33tman|6 years ago
(I still believe it - too clever constructions which feel smart at the time you come up with them :)
wastholm|6 years ago
Personally, I don't tend to have a hard time reading code I myself wrote, even long after the fact. But I will concede that Perl code _can be_ hard to read if the author has been too clever.
isostatic|6 years ago
That's the coder, not the language.
Which is more obvious what's happening.
Or People can do clever things in either language, people can write clear code in either language.sigzero|6 years ago