Exactly.

I remember someone telling me to RTFM when I posted a question on IRC back in the 90s. Luckily, I explicitly asked if they were serious. They responded of course not-- they were kidding!

Then they PM'd me with hidden link that had an image map of Perl wizards with whom I could schedule a free meeting and coffee to get started as a newbie. I was skeptical-- who cares about some random noob from the interwebs?!? Well, Perl, apparently. That face-to-face meeting left me with goosebumps that I feel to this day when I think back on it. It turned out to be an important confidence booster and my chief way into programming.

I don't think it's an exaggeration to say that without Perl's focus on outreach I would never have served as president of Software Local 2142.

Like my wizard mentor told me when I tried to pay for the coffee that afternoon: Perl it forward!

I wrote a lot of Perl 3 and Perl 4 to date my experience.

Rails was designed to be a luxury hand-holding experience using a language that was intended - as a design goal - to make programming fun. There was even for a while in the late 2000s the culture of _why and MINSWAN.

PHP was fast, easy, forgiving. It also led to such awful code that several companies banned it. I think nearly all of us who got to deploy code with nothing more than FTP miss that. Of course today it runs more of the web than any other language.

Perl on the other hand wasn't interested in any of that, so many people just left because they were pulled by better ecosystems that took the web seriously, or pushed by a culture that believed the priesthood was real.

For me, Rails and Ruby were genuinely joyful discoveries after spending a couple of years wrestling J2EE and .NET apps in the ~2002-2005 era, and the Perl community felt crusty and unwelcome and immature by comparison.

Today I'm no fan of come of the politics of people being some popular Ruby frameworks cough, but I enjoy Ruby and I'm enjoying my dive back into systems programming via re-learning C and taking a long look at Zig. I'm not sure I'll ever write "production" Perl again.

The syntax, full of @ and %, was convoluted and made you have to think about more things compared to Ruby or Python without giving you that much apparent power or benefit (as opposed to when you'd need to think about types more in Java or a C-family language).

Neither Ruby, Python, nor Perl were in my first three languages (Pascal, C/C++, Java were those). Ruby, Python, Matlab, R, and Perl all came later for me, within a few years of each other. Perl did not have anything like the approachability of Ruby and Python coming from that Pascal/C/Java background.

(IMO Python is losing some of that now, especially like in the last project I encountered in a professional capacity in Python where optional type hinting was used but wasn't always accurate which was a special sort of hell.)

EDIT: the article even touches on this some in its description of Ruby: "Ruby is a language for programmers, and is at this point an sensible candidate for building something like Rails with - a relatively blank canvas for dynamic programming, with many of the same qualities as Perl, with less legacy cruft, and more modern niceties, like an integrated object system, exceptions, straightforward data structures." Ruby was newer, and wasn't something that grew out of sysadmin tools, but was always a full fledged OO application programming language first. So my disagreement with the article is that the culture then doesn't matter because no perl culture changes would've been able to reinvent the language as a nicer, newer language like Ruby because it never would've been perl anymore at that point.

I still find the occasional Perl script in my current job, usually going through someone's legacy infrastructure, and I always have the same reaction, "phew I'm glad I switched to Python".

That reaction has nothing to do with the culture, it's 100% technical.

Just a few of the main points, I don't know why Perl coders were so adverse to comments, it's almost like some of us took a perverse pleasure in producing the most illegible piece of code.

It's like a stream of someone's consciousness.

I used to take pride in being fluent in PCRE, as well as some other dialects, and looking through an old Perl script you easily see why, it's used on every 10th line. And it always strikes me with a sense of relief when I realize all those instances of Regex are solved in a more OOP/Pythonic way today. Regex is something I reserve for edge cases.

The mentality described here has always galled me. Half the reason I’m willing to scramble up these hills is to gain the perspective to look for an easier way up the next time. It’s my reward for slogging through, not for the gathering of sycophants.

I’m not sure you’ve mastered a thing until you’ve changed the recipe to make it a little bit better anyway. My favorite pumpkin pie recipe, isn’t. As written the order of operation creates clumps, which can only be cured with an electric mixer. You shouldn’t need an electric mixer to mix pumpkin pie filling. If you mix all the dry ingredients first, you get no clumps. And it’s too soupy. Needs jumbo eggs, not large. So that is my favorite recipe.

But maybe this is why I end up writing so many tools and so much documentation, instead of hoarding.

There are tons of quirks that are interesting that influenced language development today, for me the spaceship operator "<=>" was a fun one. You can have a flip through the camel book to see what kind of stunts were common in its era.

It is an auteur language that was not really done the way languages are today.

Perl 6 did massive damage to the community mainly because it was so different that it looked like a fantasy language. That along with Parrot really lost the plot for me, I had mostly stopped doing that kind of work and moved on to R for my bioinformatics things. Bioconductor was the bees knees.

I'm surprised at all the haterade, probably you're either <30, and/or being overly critical of a very nascent tech era. Perl was pre and post .bomb, and had one of the first online communities that I remember that shared tips and tricks at scale at perlmonks.org. It predated stackoverflow! It was a very different time to now.

This was also from a time when people still paid for compilers(!)

I am deeply biased, as I wrote a 3d distance calculator in Perl for small molecule drugs. We were looking for disulfiram analogs doing biopanning and then simulations. There was a great PDB library for structures at that time that saved me tons of time. This was circa 2005~, ages from now.

Nowhere in that decision-making process is there the consideration of if it's actually a good language, more efficient, more flexible, more powerful, faster, etc. It was ease of use and "the cool kids are using it".

This kind of ubiquitous availablility (from early popularity) combined with the huge drop-off in popularity due to raku/etc, lead to a unique and very valuable situation unmatched by any other comparable language. Perl just works everywhere. No containers, no dep hell, no specific versions of the language needed. Perl is Perl and it does what it always has reliably.

I love it. The decline was a savior.

I wonder how common my experience was and why the next gen (at the time) I was part of never learned it

A classmate who introduced me to Linux in the early 2000’s was a Perl enthusiast who completely embodied the RTFM mindset. If someone didn’t already know something they were mocked. We ceased to be friends after a number of these interactions.

Not my experience at all, FWIW. For me, and the vast majority of Perl devs I’ve worked with over the past 30 years, TIMTOWTDI absolutely means some of the “ways to do it” don’t involve Perl, and that’s not only OK but expected. Of course Perl isn’t the be all/end all. It’s a lot of fun though!

(I’m a majority Perl coder to this day, it’s my favourite language by far. Hell, I even find it readable and easy/fun to debug)

A shift to Python or Ruby is fundamentally a shift to a different set of core cognitive patterns. This influences how problems are solved and how sense is made of the world, with the programming languages being tools to facilitate and, more often than not, shepherd thought processes.

The culture shift we have seen with corporations and socialized practices for collaboration, coding conventions, and more coincides with the decline of a language that does in fact have a culture that demands you RTFM. Now, the dominant culture in tech is one that either centralizes solutions to extract and rent seek or that pretends that complexity and nuance does not exist so as to move as quickly as possible, externalizing the consequences until later.

If you've been on this forum for a while, what I am saying should seem familiar, because the foundations have already been laid out in "The Pervert's Guide to Computer Programming", which applies Lacanian psychoanalysis to cognitive patterns present in various languages[1][2]. This explains the so-called decline of Perl—many people still quietly use it in the background. It also explains the conflict between Rust and C culture.

As an aside, I created a tool that can use this analysis to help companies hire devs even if they use unorthodox languages like Zig or Nim. I also briefly explored exposing it as a SaaS to help HR make sense of this (since most HR generalists don't code and so have to go with their gut on interviews, which requires them to repeat what they have already seen). With that stated, I don't believe there is a large enough market for such a tool in this hiring economy. I could be wrong.

[1] [PDF] -- "The Pervert's Guide to Computer Programming" https://s3-us-west-2.amazonaws.com/vulk-blog/ThePervertsGuid...

[2] [YouTube Vulc Coop]-- https://www.youtube.com/watch?v=mZyvIHYn2zk

I still remember spending time with my coworkers on bench outside of building trying to figure out #@$%$^&$%@something = []sd[dsd]@$#!&lala lines written by previous developers

If Perl had had a good culture, then conserving it would have been good!

Perl was my first language because I wanted to make interactive websites and that was the most common way to do it in the late 90s. Shortly after, everyone switched to PHP because mod_php was much faster than Perl CGI scripts.

Python 3 almost killed Python.

It's normal. Once a community loses faith, it's hard to stop them from leaving.

Also, PERL allows you to write the most unmaintainable code I've ever seen. I ran across a single line of PERL that would read a buffer, do some simple data transformations, add framing information (some of it derived from the data like length, data type, and checksum), and then write out the completed buffer.

It was beautiful. And also completely unmaintainable. Even the guy who wrote it didn't remember how it worked and had to fiddle with it for twenty minutes before he remembered a variable he used was getting set as a side effect of something else later in the line. That's great for a programming contest, but not so much for production code you may be tasking a newly minted software developer with maintaining.

Granted, you can write maintainable PERL code. But over the years the PERL has been hands down the least maintainable in different jobs and projects.

In my recollection perl6 helped kill it by making perl5 stagnate, but hopefully it would have died regardless.

But once you get it, its pretty intuitive to use.

The worst part about it was the syntax for object oriented programming, which in raku (perl 6) is a lot better and intuitive.

Raku has some great ideas like grammars, but has a lot of new magic symbology and lost what i thought was an intuitive way of regular expressions in Perl 5.

=~ vs ~~

PHP emerged as a separate language and community and "ate Perl's lunch" when it came to the dominant growing app style of the Aughties... web pages and apps. Had PHP instead been a Rails-like extension of Perl for the web, sigils would have reigned for many years more. But there was never a WordPress, Drupal, or similar in Perl, and no reason for anyone who wasn't already highly connected to the Unix / sysadmin community to really give Perl another look.

By 2005 if you weren't already deep into Perl, you were likely being pulled away to other communities. If you were into Perl, you were constantly lamenting why newbies and web devs weren't using your language, just like the DECUS and VMS crowd did a decade earlier as Unix and Windows consumed all the oxygen and growth opportunities in the room.

Python is pretty good too for this and because modern computers are so fast it doesn't matter that it's much slower than perl, but if you're doing something like processing terabytes of files, it's probably worth your time to find or vibe code a one-liner in perl and torture it into working for your task.

It doesn't feel like I've missed out.

[^1]: https://news.ycombinator.com/item?id=44790671

Perl was horrible to build, IMO, and seemed to require 100s of options to be selected which would mean that some script would or would not run with that particular build of Perl depending on what you chose.

Python had a more clunky but still excellent regexp package, it was a doddle to build and most of the things that affected compatibility were things you could install after the python executable was built and installed - i.e. users could get their code to work more reliably.

I can speculate a lot about what killed Perl, or at least what called the schism, and in general what was the cause of the schism had roots in what Perl failed to innovate on. The cultural stuff was a side-effect of it.

But then also - Perl has huuuge impact on so many other languages, including JavaScript, that its place in the hall of fame cannot ever be disputed.

There were various greybeards who kept telling me that Perl was a perfectly fine language and was fast enough for most purposes. I didn't argue with them and just backed away slowly.

Regarding Perl as a language, it seemed fine in the 1990s as a slightly more advanced alternative to Unix shells. But for me, what made it a failure as a language is that in order to have an array of hashes, or a hash of arrays, you needed to use references. That may have been a nice hack to enable some things in the 1990s, but even in 2005 that sounds pretty primitive and outdated to me. Plus the reliance on using magical variables consisting of $ and every non-letter ASCII character for all kinds of random stuff, like $_ and $# and so on. That may have been cool in 1992, but it's not 1992 any more.

Overall, Perl was pretty neat for little scripts up to 20 lines, but a bad idea for building an entire company on (like ZipRecruiter.) That's more of an indictment of ZipRecruiter than Perl.

This was not the best when it came to others (or even yourself 6 months later) reading the code. But it was great for cranking stuff out that was simply too tedious in other languages.

To me it seems that some in the Rust community in particular, perhaps because they're just the most vocal, are tightly coupled to progressive, social activism.

I guess in general I just find myself wishing that political and social issues could be entirely left out of technical communities.

As things became more homogeneous, and furthermore as other languages also could do that “one weird trick” of cross platform support, the shortcomings of both Perl and its community came to the fore.

Perl wasn't arcane on purpose, the bar for being a programmer was just that much higher, born through necessity as we didn't have as much material to easily turn someone into a capable engineer, so to make anything work you had to -really- be motivated to learn, and that extended to the entire skill tree of things that happen before learning to code, like simply navigating the machine and being able to reach the realization that you needed to write something on your own.

Perl evolved to suit the needs of those that used it at the time, and it reflected their interests, skills, and abilities.

These days everything is so abstracted, so available, so easy, all of the material to learn literally anything is free and at your fingertips, programmers don't need to be that knowledgeable to identify a need and generate some code that mostly addresses that need.

I feel it only gained any web traction in the sense that it was widely available and already there in the early cgi-bin approach.

On the last comment, I've taken to using Deno/TS for most of my shell scripting type tasks these days. In general it's worked very well for me.

In late 80s and early 90s professional knowledge was way harder to get. Learning required significant devotion, and often was obtainable through experience only, and at the same time computer-related work wasn't as well-paid as it will become later. And had controversial social standing. Like, my brother said "It will hurt your chances with girls, bro!" when I told him I want to be a programmer, and with typical sibling-love added "This, and your ugly face of course".

RTFM emerged naturally with all of these: people paid with their time and social life for this knowledge, and wrote down what they found in manuals, most often for free, and you can't just bother to read them?

FWIW most BOFH types in my memory were C programmers, and early Linux UGs. Perlists in comparison were mild, and way more open (Perl community included biologists, linguists, and other non stereotypically computer people).

Perl decline was to some extent a cultural thing. But absolutely not the culture the author means. In Perl Larry Wall promoted a sort of expressive style of writing code where you can chose between several compiler-equivalent ways to implement logic: There is More Than One Way To Do It (aka Tim Toady) principle. The alleged reason is that the choice you make conveys some subtle nuances of your thinking which 1) gives you more comfort while coding, 2) gives potentially more information to someone who will read your code. This was outrageously contrary to the mainstream tendency of commoditization of software development (and software developers) which started to gain the steam at those times. Managers wanted (and I guess still want though to the date the idea mostly failed) THE one and only right way to code each task, peferrably with the only one language (with Java as the main contender), standard training programs, and certifications - all across all domains, and as a result replaceable and transferrable coders. Perl was clearly unfit for this perfect future with its proud selection of 4 or 5 implementations of OOP, and it hurt the language promotion a lot. And then there was disastrously optimistic declaration about soon-to-be major uprgade to Perl 6 which in reality will take 15+ years, all while lots of interesting things happening outside.

People were still amazed that you could do X in 1 line rather than 100 lines. Some people couldn't have done those 100 lines.

So the idea of recipes/spells/hacks was an intentional parallel.

It became a cultural thing. New people wanted to be respected for compact code that impressed people the same way they were impressed.

However, I used Perl and stopped using it without knowing anything about its internal politics or community. PHP, ASP, Java JSP and later Rails were much better than Perl for web development.

* I know that for some the mention of JSP will be rare, as it was ugly… However in the 2000s it was the state of the art

Regardless of the culture issues, it was effective!

The only thing I kept using Perl for over a decade was RADIUS (we ran Radiator, which was arguably the most insanely flexible AAA server for ISPs)

As such, is likely to be around for a long, long time

Python is sometimes required for compiling software, too, but projects like the ones mentioned above requiring Perl have not switched to Python

Why did it have to take over the world anyway?

But at the time, that elite and esoteric language drew me and many others to it in much the same way that *BSD and arguably even Linux did. The way that programming computers in general did.

It wasn't a pleasant vibe that anyone should strive to recreate, but Perl was something that felt cool to many nerds back then. Perl's decline being cultural is a good thing: it's because the industry grew and matured.

Its main achievement is being there first, before everyone else, to run server-side code in a scripting/interpreted language.

The rest wasn't neither cultural nor technical. From a purely business perspective, having to fight against an idiosyncratic tool half the time doesn't really make much sense.

> [...]

> Cultural conservatism as a first principle.

Counterpoint to this: Rust. Rust has a similar RTFM/"wizards" culture, but is not culturally conservative (in any sense of the word).

My two cents: Perl's "culture" had little to do with its fall. I think Perl's problems run much deeper. Perl is built on rotten foundations. It's fundamentally a scripting language (albeit with bolted on additions to make it kinda-OOP), and it therefore has all the problems that scripting languages have for building large software projects.

Those problems have no quick fix, and indeed fixing them would require throwing the language out entirely -- at which point, why not simply switch to another language entirely (which is exactly what happened...).

What Killed Perl?

https://news.ycombinator.com/item?id=45977900

Python says you know nothing, but want to automate a small task. The community will help you. More so than any other language.

Then again, Python 2 and Python 3 are two different languages.

Very few projects are willing to have such a massive migration.

There was something about scaling usage in large teams that felt awkward and high friction.

I'm a bit sceptical about this:

> (Pause a second and ask yourself about the sort of social culture that both allows this kind of behaviour at public events, and then chooses to embrace it as a key piece of cultural lore)

Is it really so terrible that someone throws a coffee cup or two at a wall to make a point? Sounds a bit pearl-clutching.

A good article, but there is nothing new about asynchronous I/O

This is a good article, but Golly, that was a faux pas!

Hey me too exactly! I wrote the CMS for mlb.com in 2003 entirely in mod_perl.

This post is indeed a little walk down memory lane of the Perliness of the 1990s. I spent most of the 1990s enforcing everyone in my team (yes, by 1998 they made me in charge, totally inappropriately) use Perl on awkward environments like Windows NT because giving in to horrendous systems like Active Server Pages or...shudder...Cold Fusion represented the heat death of the profession. Microsoft was determined to to murder the whole "RTFM / TMTOWTDI" culture and replace it with their own brand of corporate mediocrity (remember, there was no XBox at this time. Github? no, source control was in Visual Source Safe [narrator: your source code was, in fact, not very safe!]. MSFT was 1000% uncool and evil).

But ultimately mod_perl's decline was technical! It's syntax, organization and operation were enough to get us through the 90's but were at the same time doing violence to one's cognitive facilities. Python came along and fixed everything that was wrong with Perl. I started in Python porting things from Perl, like HTML::Mason, because I was not yet enlightened enough. But I got there eventually.

maybe its painful for guys to admit that languages could be a lot better designed, and when such langauges appeared, everyone flocked to them.

I enjoyed the article but it was a nightmare to read on my phone’s browser