I will always love perl because it got my career off the ground. Anyone who doesn’t just learn it is doing themselves a disservice. It’s similar to SQL in that sense.
Feeling called out that I don't know Perl or SQL :)
Perl first commit: a “replacement” for Awk and sed
71–80 of 261 posts
Re: Perl first commit: a “replacement” for Awk and sed
#72My only real forays with Perl in anger was back with the original camel book and Perl 4. The secret sauce was the ability to persist the associative arrays to a dbm file.
Even though I worked on a lot of Unix boxes doing assorted data processing, Perl was never my goto for the same reason I adopted vi instead of eMacs.
As good as it was, it didn’t come stock on my clients machines, and I could not presume to install it or count on it being there. So, the litany of classic Unix tools prevailed and I simply became adept at working with those.
My few temptations to dip my toes in the modern (at the time) Perl waters just found indecipherable source code (to my ignorant eyes) and disastrous attempts to get whatever it was I was dabbling with out of CPAN. I was never very successful with it.
Re: Perl first commit: a “replacement” for Awk and sed
#73The funny thing is Perl is now arguably more obsolete than sed and awk.
I use Perl all of the time. If I am going to write a bash script that is more than 12 lines long I use Perl or if I need to do read text files and do regex matching things I haven't found anything better.
Re: Perl first commit: a “replacement” for Awk and sed
#74I could never learn it
Re: Perl first commit: a “replacement” for Awk and sed
#75Earlier quoted context omitted.
> Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. For any problem that can't be solved this way you wri…
you probably shouldn't abuse shell scripts to build a complex system, and beyond a certain level of complexity, a programming language is the better tool but the only free programming languages available at the time were C/C++, various shells, and awk. everything else was expensive or not generally usable for other reasons. all the really useful languages to build complex systems didn't really appear or become freely…
I'm not saying that Perl didn't have its time and place. It certainly fulfilled a need at the time for a language more capable than shell scripts, but less cumbersome than C/C++.
But the thing is that today the shell landscape is much more mature for solving simple problems, and we have C/C++ alternatives that are saner and more capable than Perl (e.g. Go). So it arguably has lost its place, as shell tools are still in widespread use, while Perl is mostly underused. Raku is interesting, but it goes in a different direction, and its adoption is practically zero.
Re: Perl first commit: a “replacement” for Awk and sed
#76Earlier quoted context omitted.
Not just the language itself but the whole ecosystem it brought with it was revolutionary. CPAN was incredible. There seemed like there was a module for just about anything! Perldoc and a testing framework were built right in. Regexes, backticks to shell out to the system, reporting built in. It really was the whole package.
Yeah CPAN is easy to take for granted now that every language has its own package manager (npm, cargo, pip), and even for C/C++ you can find what you want on GitHub. At the time though CPAN was revolutionary and no one else had it. To be able to just search for a module, find one that did what you wanted, then download it to your project was pure magic.
There is some question whether CTAN (for TeX) or CPAN was the first big library. It was pretty close. I was involved tangentially with the guys in the UK who were setting up the first pass at CTAN as the administrator of the ymir.claremont.edu archive and I remember one of the things that they came up with back then was that you could do an FTP get of any directory and get back a zip archive of its contents which was pretty fancy in the 90s. That said, both CPAN and CTAN definitely show their age in that they assume a single version of dependencies will be installed on any system which causes untold nightmares when it turns out that there’s a non-backwards compatible update to something three dependencies deep that you weren’t even aware you were using.
Re: Perl first commit: a “replacement” for Awk and sed
#77I know people dump on Perl all the time, I know I do. But it was a critical part of computing history. Perl did a tremendous job of bridging the gap between shell commands and shell scripts and “big languages”. Way back in the early 90’s I took a complicated shell script that took about 2 hours to run this huge text processing job , rewrote it in Perl and it took about 20 seconds, and was more maintainable to boot. I…
During a later period (early 2000's) Perl was the only scripting language with good Unicode support, including inside regular expressions, which was revolutionary at the time. There was so much cool stuff you could only do in Perl, and then like you say it all ran into the brick wall of Perl 6.
The brick wall of Perl 6 was itself a solution to an internal nightmare inside of core Perl development. Particularly around conflicts involving Tom Christensen, which caused no progress to be made on Perl 5.6.1 despite major bugs in 5.6.0. For example:
my $x = 5 + 6;
$x .= "0";
print $x + 5; # 16, not 115.
And it worked, sort of, for a few years.
I was on the Perl Grant Committee at the moment that killed Perl 6 in my opinion. We had a choice of 2 grants from Nicholas Clark that we could fund during 2006. One brought a lot of immediate benefits to Perl (Unicode fixes, reduced memory usage, etc), and the other was to get Ponie to the point where someone other than a core Perl developer could work on Perl 6.
We chose the immediate benefits for Perl 5.
Re: Perl first commit: a “replacement” for Awk and sed
#78When perl came out we were living in horrific times. You had the choice of either Bourne, C or Korn shell. Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. Perl in one stroke collapsed the programming of C, text manipulation, the capabilities of all of the Unix utilities, an…
All software eventually becomes an unmaintainable nightmare.
Re: Perl first commit: a “replacement” for Awk and sed
#79When perl came out we were living in horrific times. You had the choice of either Bourne, C or Korn shell. Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. Perl in one stroke collapsed the programming of C, text manipulation, the capabilities of all of the Unix utilities, an…
> Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. For any problem that can't be solved this way you wri…
csh was a decent interactive tool, but not great for scripting. Bourne shell had the right idea but there were so many bugs in various corners of it (I still sometimes end up writing "test "x$foo" = "xbar" even though shells that need that are long gone).
If you can depend on a recent bash and use shellcheck, then it's actually quite a pleasant programming environment, with fewer footguns than one might think. (I want a @#$@# "set -e" equivalent that returns non-zero from a function if any statement in the function results in non-zero).
There are some things that are more awkward than they should be though (e.g. given a glob, does it match 0, 1, or many files, or the way array expansions work).
Also, there's no builtin way to manage libraries (I don't know about Perl, but Python suffers from this as well). This results in me pasting a few dozen lines of shell at the top of any of my significant shell scripts, for quality-of-life functions. Then I have to use "command -v" to check if the various external programs I'm going to use are present. Say what you will about C, but a statically-linked C program can be dropped in anywhere.
Re: Perl first commit: a “replacement” for Awk and sed
#80Earlier quoted context omitted.
> Yes, awk and sed were replaced by Perl, I still use awk and sed semi regularly. I haven’t used Perl in over a decade.
Agreed. I would turn to Python for anything more involved that couldn’t be done very directly and efficiently using awk/sed. I would never use Perl for anything.
Same, but if there were no Python/Ruby/etc, I would probably be reaching for Perl quite a lot.