I started in the catalog department at Amazon in 1997, right as Glennf left. It took me an embarrassingly long time to realize that the desks were made out of doors. It just seemed like giant clunky desk to me.
One thing I do remember distinctly about Glenn's time in the catalog department was this terrifying 60k Perl script I inherited from him called sitecounts.pl. This script examined all the various catalogs (books, reviews, etc) and attempted to generate some interesting stats about them. One day it just broke, and since it was used in the catalog build process to verify that things were sane, it needed to get fixed pronto. The code was plenty confusing, but what was the worst part was the extent of the right margin creep, I'm talking 150+ character lines -- not exactly easy reading on my crappy 15" X-terminal. I felt like a character in a HP Lovecraft story, slowly descending into madness as I learned more about the horrors of this script.
I ended up maintaining and adding to this script my entire first stint at Amazon. Eventually as I added features and changed things, it slowly got made sane over time, save for a little bit of madness that I kept in there just so I'd have a reminder of what it was like.
Unfortunately I don't have much to add to the OP, but I wanted to comment on this. Everyone I know that hates Perl had some sort of experience where they inherited some legacy Perl script that broke all the time and yet performed business critical functions. I started my first full-time job in 2004, and whenever I get together with my old co-workers we'll STILL talk about the battle scars we had trying to bubble gum and tape together a particular script called cc_processing.pl (yep, just as critical as the name implies), that seemingly broke every other day and went so far down the rabbit hole you had no idea how it ever ran successfully. $a{$a} = $a->{$a}? Sure, why not.
I wonder how much of Perl's reputation is based on these kinds of formative experiences. I love Perl, but I'm realizing that everyone had their nemesis in sitecounts.pl, or traffic_reports.pl, or partnerpayments.pl, or wtf-how-did-this-ever-work.pl, and unfortunately didn't draw the same conclusions about Perl that I did.
I can tell you that people are still creating these monstrosities today, now more likely with Python than Perl in my experience. I saw one in particular in an academic research project, a true "kitchen sink" script that did all kinds of loosely related administrative things in a massive construction of argument parsing and if-then blocks.
For me the problem with Perl isn't the language but the mindset the goes with it.
It's like it triggers some primitive release of testosterone which results in developers competing to fit the most functionality in one regex filled line of craziness. Hilarious to watch. Hell to debug.
Massive perl scripts that still lurk in our memories of the 90s were not the result of testosterone fueled one-up-manship brogrammer culture. They are the result of needing-to-get-the-report-generated-yesterday one-man-in-the-"computers"-department every-programmer-was-a-sysadmin and-every-sysadmin-knew-perl4-because-that's-all-that-shipped-with-HP-UX/Solaris/AIX (and you had to pay extra for the compiler to build something more modern) culture -- if a single person working in isolation can define a "culture", that is.
It's scripts like these that spawned the meme of replacing people with scripts; because that's what these massive scripts did: automated away entire departments, or negated the need to hire for a department all together. Which is important when you're a two man company and all of a sudden you've discovered you need to process $100k of credit card transactions from yesterday, and you better get started on it because there's already another $300k in transactions generated today. It's only one script, so there's no need for revision control. Damn, there's only one guy working on it, it can run out of his home directory. And of course, it was so successful, successfully a blackbox, he's asked to automate some other task, which is only related because there's some slight dependency, and, well, it's a dependency, so let's just put it in the same script we already run. Rinse, repeat.
Were these scripts terrible? Of course. But they were the work horses of the Internet and any company with two CPUs to rub together in the 90s. There's a reason that "perl is the duct tape of the Internet" was a saying in the mid- to late- 90s: because it was.
These scripts work perfectly fine if the person who wrote them and fully understand them runs them, yet inexplicably fall apart when someone who didn't write them run them (similar to [0]). These scripts can smell the fear of the new guy put in charge to maintain them. This is where heisenbugs roost and schroedinbugs become the stuff nightmares are made of, despite that they had most likely been running without issue for months or years since the guy who wrote them left.
Don't blame the language either. It just is what it is. But there is value in the things you can learn about the code, the people, and the times by taking an anthropological view of it.
In fifteen or twenty years we'll be reading rants from people who had to cut their teeth on some overly designed, needlessly abstracted, difficult-to-build-all the-dependencies-for rails app.
Along those lines, reading Programming Perl is a pleasure in good part because Larry et al. spend time explaining not just the language but also where some of it comes from and its rationale (or not so rational ;-).
Note that I'm referring to the first or second edition (maybe the third); I understand that the fourth edition is just recently out.
If folks have enough programming experience with other languages, it's easy to write Perl that looks more like those other languages, but unfortunately the moment a developer gets overworked or wants to show off (opposite extremes, really), Perl can devolve faster than some other languages because so many tricks are possible when vigilance is not maintained.
I've had decent success with making one-class-per-file with MooseX::Declare and Method::Signatures::Simple, but you really have to have a good code review process and rock solid developers to make it happen.
I don't think it's the languages fault, as this can happen just as quick in (say) Ruby code, and you can write extremely bad code in any language. Those other languages tend to be slightly faster to develop in though, as you can forget all of the need to write things like "my" and the reference syntax. Things like Python and Java have some resistance to "having fun with syntax games", but fall into other traps where interesting syntax (or architecture games) become fun or quick shortcuts.
On one end, part of Perl's problem is not Perl at all, just that it was historically the first thing people learned after Bash, and often those folks really didn't learn to program yet. On the other end, it is easy to go crazy with it.
Incidentally, the same mindset goes with pretty much every other programming language I've seen. The long regexes exist because a short one was "debugged" and "enhanced" into the long one. The same goes with full programs; that five line Java class is now 1000 because all of the bugs were fixed and features were added. You can't blame Perl for the programmer that won't way "we're not shipping that feature today, we're going to split this regex into its own module."
(There is also a skill level issue; regexes are much easier to understand than parser generators, so a lot of people try to implement a parser with regexes.)
Haha. Glenn's perl was legendary at AMZN, even 10 years later. My team ended up 'maintaining' GPOS (for non-AMZN folks, the G stands for Glenn - you can figure the rest out...)
I work for a small company (not a software/tech one) as a sysadmin and programmer and sometimes I feel almost ashamed of scripts or pieces of software because I know that they could be implemented much better or cleaner or this or that. I have some delusion that programmers working at other companies make better design decisions, better code, better tests, etc.
I love to read other programmer's battle stories! (I am currently reading "Coders at Work" and really enjoying it).
its easy to look at code out of context ... was the coder under duress, was he being asked to do a million things at the same time. Was he being paid enough to care ... i'm not making apologies, I think one of the worst things that can happen to a coder is you lower your own personal quality bar; but its easy to do if in the wrong set of context. I always recommend quitting before getting to that point.
Addressing some of the other comments; Perl and the Perl community itself is so far removed from macho ... its still one of the kindest, most intelligent and beneficial public communities online .... if someone feels emasculated by just reading someone's code; don't mistake that for the original coder's intent was to emasculate.
Perl is the programming language that I would want with me if the world was coming to an end (asteroids of course) and somehow I could help save it with getting the damn lasers to work to blow up the asteroids ... if it takes a 150 char regex then so be it.
One thing I do remember distinctly about Glenn's time in the catalog department was this terrifying 60k Perl script I inherited from him called sitecounts.pl. This script examined all the various catalogs (books, reviews, etc) and attempted to generate some interesting stats about them. One day it just broke, and since it was used in the catalog build process to verify that things were sane, it needed to get fixed pronto. The code was plenty confusing, but what was the worst part was the extent of the right margin creep, I'm talking 150+ character lines -- not exactly easy reading on my crappy 15" X-terminal. I felt like a character in a HP Lovecraft story, slowly descending into madness as I learned more about the horrors of this script.
I ended up maintaining and adding to this script my entire first stint at Amazon. Eventually as I added features and changed things, it slowly got made sane over time, save for a little bit of madness that I kept in there just so I'd have a reminder of what it was like.
Ah the 90s. Good times.