One thing to keep in mind is that this is not actually the first version of perl, it's the first public version of perl. A version 0 did exist at the JPL previously but it's likely lost to the ages at this point. EDIT: For the curious about the history, take a look at the perlhist documentation, https://perldoc.perl.org/perlhist it's got a lot of good info about the history of perl and it's releases.
This doc has no info about perl version 0. Any source on it emerging at JPL? Can't find anything online except forum posts
Apparently my memory on that seems to be faulty, looks oike it was shortly after he was at jpl and left for unisys/system development corp (it changed names), https://www.oreilly.com/pub/au/148
One thing to keep in mind is that this is not actually the first version of perl, it's the first public version of perl. A version 0 did exist at the JPL previously but it's likely lost to the ages at this point. EDIT: For the curious about the history, take a look at the perlhist documentation, https://perldoc.perl.org/perlhist it's got a lot of good info about the history of perl and it's releases.
This doc has no info about perl version 0. Any source on it emerging at JPL? Can't find anything online except forum posts
A while back, I wrote a two-part article highlighting use cases where Perl's rich regular expression engine, built-in functions, extensive ecosystem and portability helps. Includes examples that are easier to do with Perl compared to sed/awk:
I used to kind of unfairly disparage perl, but now I regret never learning it. I've written a lot of scripts for munging text/files that outgrow bash, and when I rewrite in Python they get twice as long. Seems like perl would be a happy medium and let me keep using a lot of the nice bash shortcuts like `baskticks` for shell execution, etc
I've forgotten almost everything about Perl, but one thing I dimly remember is that for just about anything exceeding your one-liner/dirty one-off script (outgrow bash??) you'd use some library anyway, even for purposes like this. Just to make it sane. In other words it came down to more or less what you do in Python post Y2K: run(['blah'], ...) Not necessarily shorter (how?), probably not better (how?), certainly not safer (nope!) and "even" to reproduce everything subprocess can do these days I think you'd rather needed 3 or 4 imports, minimum, and remember this is Perl. So we're not talking standard library. Off to CPAN you were. Not all was great, even in heyday, and eventually people jumped ship for reasons, different reasons. Still, Perl deserved better than a bizarre zombie afterlife or undead pseudo-existence hinging on hardly more than worn out UNIX yarn. Funny how no one ever recalls tcl? Such is true rest. Such is nirvana. Yet tcl got that actual object system that never arrived for Perl. Tcl could do threads when Perl hardly knew there's such a thing! Oh and yes, tcl shipped its own GUI on top, consider that, vanilla Python even comes with it today I think. That's a way to go.
Perl was huge in the early web and first dot-com boom, it was used a lot for CGI scripting.
I probably didn't learn Perl because PHP superseded it for web stuff.
This. PHP was my first "real" programming language (which is a bit scary now that I think about it since it followed me learning QBasic and VB6) and by the time I was messing with it for web dev circa 2003 CGI scripts were on their way out. I suspect that it had something to do with CPanel/WHM-based shared hosting setups being reticent to deal with something as powerful as CGI and preferring to just run PHP in Safe Mode. I could be wrong though as I was also a technically-ignorant punk that fixed phpBB installer filesystem permission issues by 777'ing everything in my hosting directory :-). Good times...
I certainly have, and might have written a few of those myself. But this doesn't make this approach inherently wrong or obsolete. The programmer is wrong for trying to use the tools beyond their capabilities. Where that line is drawn is subjective, as is the concept of maintainability, but if you feel that you're struggling to accomplish something, and that it's becoming a chore to maintain, the path forward is choos…
I think we are actually mostly in agreement there then. Perl was invented because the gap from shell to more capable languages was (and is) really big. Languages like Python and Ruby didn’t exist yet, and Perl had a really, really strong sweet spot in text processing.
> Perl had a really, really strong sweet spot in text processing.
When 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…
> 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.
1980s awk and sed aren't the same as the 2020s version.
They've become much more useful because of the influence of things like perl.
To see what I mean, here's SunOS 4.1.1's man page for awk and sed as grabbed from https://github.com/ambiamber/Run-Sun3-SunOS-4.1.1/blob/main/... and ran through groffer(1) . These are from 1989 and 1987 respectively. The core stuff is there but not much else.
I 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.
Perl still does have the best Unicode support, especially for regex's. In comparison, grep has imitation Unicode support (the -P "Perl" flag helps, but it's still nowhere near as powerful as Perl regex's). Python's standard regex library, re, is better than grep's regex's, but still not as good as Perl. Python also has a non-standard regex library, regex, in PyPi, which I think is as good as Perl.
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.
As far as I know, https://cpantesters.org/ is still unrivaled though. None of those have the level of testing that CPAN Testers provides.
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…
>There is some question whether CTAN (for TeX) or CPAN was the first big library.
I'm not in this space, but the similarity in names made me wonder if these would really have started around the same time, with an unclear "dependency order", so I reached for a search engine, and according to Wikipedia, CPAN (1993) is based on CTAN (1992).