I used a machine with a 9-year-old distro on it for a few months, and all my scripts ran without issue, and I have high confidence that they will continue to run for years down the road without my having to adjust them for breaking changes in the language runtime, which is more than I can say for most other stacks I've used.
Furthermore, ALL the code examples I can google up will work without me having to check if they're for the right version of Perl, because it has near-perfect backwards compatibility going back all the way to 5.000 from 1994.
About the only other thing with a comparable level of stability has been HTML/JS/CSS, which gets a lot of new features all the time, but, for the most part, if I use only minimal features, remains usable for years without modification.
But unfortunately, some Perl devs in recent years keep thinking that what they need to do is break stuff to "modernize". They keep eyeing goals like turning `strict` on by default, and eliminating lesser-used features, which will surely break untold numbers of 20-year-old scripts.
I think there is some low-level anxiety among some of their developers that interest in their language has basically evaporated and they keep reaching for a silver bullet that doesn't exist. I think they are crazy ("perl 7... now 10% more like python!") but it's open-source so in the worst case I'm sure someone will keep a traditional perl from bit-rotting.
edit: I had made a short blog post about playing with perl 1: https://rwtodd.org/2020/Jun/building-perl-1
Not unless you declare a version. Old style perl will continue to work as before.
If you declare something like:
use v5.40;
Your 20 year old script can continue to run just fine.
There was some talk about that a few years back, but those ideas have largely been abandoned. They've also adopted the "steering committee" approach, and they have something like a formal RFC proceedure to talk over new proposals-- in general the project is in very good shape. And backwards compatibility is still the rule, unlike a lot of other projects out there.
Isn't it the whole point of Raku (previously Perl 6)?
The main reason to learn Raku at present is simply that it's profoundly different from most other things out there-- there's no particular "killer app" that's emerged for it, but it's unusual enough that this might happen yet (no one expected Perl would be critical for "Web 1.0" and the Human Genome Project...).
Some Raku features:
(1) it's numeric types include true rational numbers, so there's less chance of being tripped up by floating point approximations (e.g. 2/3 is really 2/3, and if you multiply by 3 later you get precisely 2). It also does big integers by default: you're less likely to have overflow problems.
(2) Raku's regular expressions have been redesigned from scratch, and it ships with expanded capabilities to compose them into larger structures called "grammars": Raku is a uniquely powerful tool for writing special-purpose parsers, ala domain-specific languages. (Note: this is how Raku parses itself-- it's not implemented in the usual lex and yacc style.)
(3) Extremly convenient features for handling CAP (concurrency, asynchrony, parallelism), possibly the easiest to use of any language.
As for Perl (meaning the original, Perl 5), it's vastly superior to traditional bash scripting because all the components were brought into one process where they could be made more consistent and talk to each other easily.
How Perl compares to Python is a little difficult for me to answer: I prefer Perl, but I could be biased on this one, and there's no question Python has quite a bit of momentum at present in a number of areas.
Both of these approaches have their advantages. I have a saying I overuse: "Python helps you think more like the computer does, Perl helps the computer think more like you do". The consequence of this is that python is good at helping people think about tasks that the computer is good at in - like statistical problems. On the other hand perl is good at helping to contain the mess and chaos of the real world in a way that makes it more tractable for the computer - which is why it remains popular in the recruitment industry backends and other less tidy business areas.
Perl's very raw unvarnished object model is in fact based on python's, so it is very similar, but it's also built for flexibility. This means object models like Moo[1] which are really nice flexible and done right make it really easy to write extendable applications. Implementing python's object model in perl (i.e pretty much the exact specification) is easy. However you can't implement perl's object model in python except by messing with the guts of the python interpreter.
I haven't done any commercial python - I only have a passing aquaintance really from messing with sympy and the like. But boy perl has been good to me. I earn a good living in an interesting job and I can maintain interests out of work as well. And I haven't had to look hard for work for years. Of course currently I'm neck deep in recursive SQL queries.
[1] https://metacpan.org/pod/Moo - My favourite job to date was building a back end to spin up network devices, that got one gentle refactor after the initial implementation and was then subsequently extended to three or four completely different network device architectures extremely quickly. Mostly by virtue of making almost every object property read only and memoised on demand (extensions to existing methods would are likewise inlined on complilation - all done with object composition rather than inheritance too for an added layer of sanity)
I use Perl over Python because of the culture/tradition of not introducing breaking changes into the language/runtime, which has also saved me countless hours. I'm also a fan of arbitrary whitespace for formatting.
Perl is ubiquitous in the *nix world. Combined with its stability and my avoidance of third-party libraries, I can run my scripts basically anywhere without struggling with dependencies, version mismatches, etc.
* not grinding a theoretical axe against the user
* language changeable at run-time to some degree, so stealing new ideas from other languages and keeping up with advancements in PLT can be and is done by end users, not only the maintainers
Example: Convert Windows newlines to UNIX newlines: $ ... | perl -p -e 's/\r\n/\n/g' | ...
My brain is too full to remember how to do similar regexy transformations using sed, but I know it can be done.
It depends on what you are trying to do.
Perl excels at processing text particularly if you are familiar with regular expressions.
Perl mainstreamed regular expressions and most programming languages that support regular expressions support some subset of Perl regular expressions.
Perl is faster than both Bash and Python and scales up a bit better than Python as a project starts to grow because 'use strict' and 'use warnings' will catch many errors. Python has a better 'batteries included' standard library, so it tends to be better at prototyping than Perl unless you are pulling in libraries in which case it depends on what you are trying to do.
Perl can be more terse than Python, particularly if you are using built-in variables. However, this impacts legibility which is part of the reason why Perl is the target of 'executable line noise' jokes.
I think people tend to associate it only with a certain era of web dev, but it has remained a good scripting language with a large, consistent, well-documented standard library for a long time now.
Not worth switching off perl since you're very used to that, but iirc ruby was initially conceived as a successor to perl and for me at least it has landed in that role.
I think it's the sysadmin culture. If your scripts are used by thousands of different servers hosting custom web apps and strange databases you'll run into every possible bug fast.
The compatibility really does stretch back all the way to '94.
I'm curious, though, do you have any Perl programs you've worked on recently that are public? I'd love to take a look at how people are writing Perl these days...
template default perl
Which features do you see as esoteric?
I typically write code which I can (and do) copy and paste into PHP almost without changes. (I use PHP as both webserver glue and for duplicating functionality so that I can have two copies of the same code to validate against each other.)
I've also started adding some Python to my project and developed a very similar style in Python, using commented curly braces to reduce the code's brittleness.
> People seem to have forgotten that when Perl evolved from being a better AWK to the paradigm example of the modern "scripting language", Larry Wall explicitly described this as a rejection of the Unix small-tools philosophy. http://www.linux-mag.com/id/322/ ("But Perl was actually much more countercultural than you might think. It was intended to subvert the Unix philosophy. More specifically, it was intended to subvert that part of Unix philosophy that said that every tool should do only one thing and do that one thing well.") http://www.wall.org/~larry/pm.html The fact that getting things done with a Perlesque scripting language is now seen as the height of purist Unix propriety only shows how far gone the original Unix ideal now is. But moving to the scripting-glue model doesn't really get rid of small tools that endeavour to do one thing well, it just reimplements them inside the scripting-language universe as functions/objects, though with a more expressive and less burdensome common language that makes it easier for them to stay small while being correct and effective. The more expressive their shared language, the smaller [the individual tools in] a set of tools can be.
>> Text just isn't a great medium for IPC.
> Yes, in retrospect Unix's determination to know about nothing but binary or plaintext blobs and streams looks like an adolescent rebellion against the (apparently - I haven't used them) clunky record structures of '60s operating systems.
[Extra text] added for clarification.
A lot of projects tried to implement opinionated OSes to the point that the OS was really an application. I'm thinking of Sprite and Amoeba, which attempted to abstract out the network and present a unified interface to accessing resources, and fancy storage systems, but in doing so impose opinionated interfaces on that access.
That's half way between an OS and an application like Hadoop, or Kafka, but you couldn't effectively develop something like Hadoop or Kafka, with your own optimisations and implementation tradeoffs on one of these things because the implementations or access models would clash.
If we're talking parsing and chopping up text files, I can usually whip up something with awk/jq/cut/whatever in far less time than writing an equivalent Python script. There's a threshold where you prefer to switch to the scripting language for maintainability/testing, but the shell won't be going anywhere any time soon.
In Python, the multiplier is much higher, and I could never get the oneliner stuff to work.
Navigational databases had gotten incredibly complicated, allowing the relational people to lap them.
awk has named parameters! Perl was a step backwards!
Now you can write.
use v5.20; use feature 'signatures';
sub print_text( $param1 , $language = "perl", $years = 10 ) { say "I would have loved this $language $param1 more then $years years ago"; }
print_text "feature"
I prefer text. Binary is too early optimisation and record oriented is too restricted.
Perl is very well thought out, in a way that I don't think gets enough credit. For example, the three loop controls (next, last, redo) are four letters long, which makes remembering them easier. In a world where I sometimes have to jump between languages I haven't used in a while, and I'm always forgetting what arbitrary word choice this particular language used for a feature, it's nice to come back to Perl and have a language where the grammar is a little bit less arbitrary.
unless/until can be way more readable in some conditions than if/while.
Postfix conditionals and loops make flatter code, especially in scripts. Love writing "do function() if $condition".
Want to pass me a hashtable of lambdas that return arrays of alternating functions and regexps?
Go ahead. Show me how to invoke it. I'm waitng.
Python (which has all of the type safety and expressivity of perl) allows such abominations to hide behind clean looking syntax.
Sigils also improve readability. Bad Perl looks like serial port noise. Bad Python looks like good python.
(In Python's defense, it has a nice ffi.)
Never used Perl, so I can't really make an honest comparison. I do use Python at work, though, and I can assure you that is FAR from being true.
In fact, I think this is so untrue that I urge you to check out essentially any code written in academia (especially projects involving numeric computation and data science). If you come back and make that same statement with a straight face, I'll eat my hat.
many languages will allow you to succinctly express the concept of "the type of this element is a or b"
e.g. typescript:
https://www.typescriptlang.org/docs/handbook/2/everyday-type...
Rust:
https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html
F# :
https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...
IDK, allowing that kind of type to be declared seems like a good thing to me? Those links have good examples of where it's useful. You'd need a good reason to use actually "function or regexp" in actual code though.
I think that it does not make it less readable.
In some programming languages they will be used to avoid clashes with reserved words, which I think is a good idea.
Some programming languages (such as BASIC) have suffix sigils to indicate data type; some (such as OAA) have both prefix and suffix sigils.
Some programming language may allow multiple sigils together in some cases (e.g. Raku and Free Hero Mesh) (in Raku they called the secondary sigils as "twigils").
The meaning seems to vary depending on programming languages; some are used for similar purposes and sometimes they are used for different purposes.
In Perl, the sigil can indicate scalar vs array (but not numbers vs strings), and in BASIC it can indicate numbers vs strings (but not scalar vs array, which is differently).
`@array` - array of values.
`$array[1]` - get element 1 of the array.
`$array` - What do you think this does? Why can't we just `@array[1]`?
There's a lesson here somewhere that most people don't generally want to understand stuff. So stuff that's the least bit different don't tend to go mainstream, things like Haskell have a hard time. Perl was a bit different but just happened to go mainstream anyway, and that probably coloured people's feelings for it, for better and for worse.
'array' is the variable.
'@array' gives me the list in 'array'.
'$array[1]' gives me the scalar ($) value at array[1].
`@array[3..7]` gives me the list (@) of values at array indexes 3-7, inclusive on both sides. (Why does Python use open ended ranges? <facepalm>) (Why is Python's slicing syntax an inflexible loop? <facepalm again>)
`@array[1]`, by the way gives me the list of values at array index 1, which is the same as `$array[1]`
Because of slices. If you look at the complete table, you will never get confused again.
I think it will throw an error if you declared my @array
> Why can't we just `@array[1]`?
Because that could return an array or a hash if you are dealing with structures likes arrays-of-arrays (AoA) or arrays-of-hashes (AoH).
To my naive take, it makes much more sense to only identify high level objects to put them under one category (arrays, AoA, AoH -> @) then consider everything else as "uncertain" and default to $.
Otherwise, you would have to declare AoA and AoH differently (ex: my @@AoA; my @%AoH;) and then the interpreter could see @AoA[1] and %AoH[1] as valid but %AoA[1] and @AoH[1] as invalid.
I could see that as potentially having value to know at a glance what you are dealing with, but it might break many things, and casting to a new object with my %aoh_1 = %{ $AoH[1] } makes more sense.
Also, if they wouldn't have made it too-weird-for-math-and-physics people, Perl would've probably filled Python's niche too.
And with that kind of resources focused on it, Perl 6 could've actually turned up into a clean nice new language that would've unified us all by also supporting nice compile-to-wasm.
</alternative-reality>
<html><body>
<?php echo 'Hello World'; ?>
</body></html>
#!/usr/local/bin/perl
print "Content-Type: text/html\r\n\r\n";
print "<html><body>";
print "Hello world";
print "</body></html>";
#!/usr/local/bin/perl
use strict;
use warnings;
use CGI;
my $q = CGI->new;
print $q->header('text/html');
print $q->start_html();
print "Hello world";
print $q->end_html();
In other words, there was no standard templating; Template Toolkit eventually became a relatively defacto standard, but PHP had already won - and even then, TT had to be manually invoked rather than just going and freestyling <?php> tags everywhere in your HTML and "it just working".
In every other respect Perl is & was superior to PHP, and it's really sad to see Perl fade, despite (or because of?) its crazy flexibility and power.
I am not sure how much of a standard it was, but Perl Mason was a superb web site templating system.
Amazon and many other websites used it for years because it was flexible, high performance, and had fewer security problems compared to PHP.
Installing any major work built in Perl back then was a nightmare of installing all the underlying dependency modules, often into the system directories. It didn't have a clean, standardized way to package up a script + dependencies easily, and dependency management was hellish, especially with many key modules needing platform-specific C compilation.
At that time commercial "shared" hosting was still common: many customers sharing one linux webhosting box and uploading scripts to via FTP, with no access to or control over the underlying system. If the webhost supported PHP, you could upload a php script and it Just Worked. Not so with Perl!
Perl was by far the superior language, but it just wasn't the superior experience for a beginning web developer who mostly just wanted to embed a tiny amount of CGI functionality in a static HTML page, and then upload and run it pretty much anywhere with no fuss.
PHP really exploded in popularity when web hosting took off. It had a safe mode that made it possible to for several customers to co-exist in the same web server, without having the ability to read each other's files.
As I understand it, PHP became popular before CGI.pm was ready.
I think ColdFusion was briefly popular for the same reason (though I think that one fell out of favor largely because it cost a ton of money).
I started programming web systems in ‘96, with Perl because it was on every machine and every web host. Apache mod_perl was a thing, and it was a bad thing, because it had to be restarted all the time because of memory leaks.
On the other hand, mod_php was much more solid, and additionally, at the time, MySQL was the main thing for many websites. The Perl database bindings were wordy and obtuse, but PHP was a breath of fresh air. I was able to start using it in environments in ‘99 and honestly, I’ve never looked back at Perl as a web application language, just a systems one.
That simple difference was enough to make me fully switch over, and it set me on the path of a career programmer, so I look back on that time very fondly.
One other thing: I don’t recall Perl scripts allowing C-style pre-processing inclusion the way PHP did. I worked at Linux.com around then and we used all sorts of templating and other library reuse via this inclusion.
By that I mean, a mod_perl program was expected to change the execution state for future executions, global variables would remain, etc. There are ways to make that happen in mod_php, but it isn't the default and I don't know if they were available initially. This made it easier to share a mod_php server with many users... A mod_perl really should be suexeced per user (or something) and that's hard. Really, you want to do per user php servers too, but it wasn't obvious back then.
Conversely, PHP was trivial to set up for safe shared hosts.
The end result was that Perl hosting was expensive and had a higher barrier to entry than PHP.
But I do like its Unix feeling. Too bad no one uses it anymore and have to move on.
Rather than looking for killer app or adding modern features, such as the effort of Perl 6, now Raku, Perl should shed features and focus on stability (which it is fighting hard to retain), on ubiquity (which it had and are losing ground), and core performance (which it is slowly degrading due to features). I think it should try to get a core set into POSIX standard. The core Perl can be like POSIX shell, while a distribution always can distribute a fancier, but always compatible Perl.
Perl should replace shell scripting, period. If there is any reason shell scripts is still preferred, then that should be the TOP focus for Perl steering council to address.
It really frustrates me to see people today, me included, are still trying to manage basic software engineering in shell scripts. It really amuses me today to listen to pastors on how to write good shell scripts. It really saddens me today to watch efforts of inventing a better shell for scripting.
Lmao Python has been around since 1991 only three years after Perl appeared. How's it a fad? Sucess of python is a testament to the difference a simple and beginner-friendly syntax can make as well as the "batteries-included" paradigm. Most people don't realize how much of a difference these things make especially in removing the initial barrier to get started with programming. There's a reason Go language creators enforced a rigid formatting requirement. It not only improves readability but helps in creating clever tools for syntax checking and other tasks. Readability is key, the fact that Perl code is compatible with that 20 years before makes no difference as they have such bad readability (especially quickly made scripts for sysadmin tasks which no newbie can understand and maintain now). So even for now Python is the best choice for shell scripting, eventually until Go takes over. At this point unfortunately I don't see any area where Perl can make a difference compared to other languages.
If everyone start wearing pink this year, that's a fad. A fad has nothing to do with when the stuff was invented. It only has to do with people choosing it from the dominant reason being other people chooses it.
> Sucess of python is a testament to the difference a simple and beginner-friendly syntax can make as well as the "batteries-included" paradigm.
So why Python didn't succeed when Perl dominated? As you said, Python was around for quite a while then. "Simple", "beginner-friendly", "batteries-included" are all subjective terms that none of them I think is true compared to Perl. That mostly comes from one's background and culture, not worth to debate.
> the fact that Perl code is compatible with that 20 years before makes no difference as they have such bad readability
Writing Perl the way one writes shell scripts is what gets Perl's write-only rep. Do not write scripts the way we write shell scripts. Write scripts the way we write code -- That is my motivation to replace shell scripts with Perl.
There is no easy way to write readable shell scripts. Perl has all the language features that enables writing readable code. Using bad practitioner as argument for bad language is a bad logic. But if all you saw were bad practitioners (or more likely today, one haven't seen real practitioners by hears about the bad rep and see some bad relics), then it's hard to convince you. Perl has formatter. Perl has strict mode (that should be default). Perl has best practices. The people still using Perl today knows this. People who claim Perl is unreadable are getting that from the 90s.
"I have stolen ideas from every book I have ever read. My principle in researching a novel is 'Read like a butterfly, write like a bee', and if this story contains any honey, it is entirely because of the quality of the nectar I found in the work of better writers."
Philip Pullman
https://perldoc.perl.org/perlfunc#Perl-Functions-by-Category
All the standard library ordered as links, by categories that actually make sense!
Also perl5 used to be very accessible, even the parser error message made actual sense. I think that a lot of care has been put into these details, and that this attention to details did have a role in the success of the language.
"Less is more"—Mies van der Rohe
Postmodernism:
"Less is a bore"—Robert Venturi
—————
Guided by these famous quotes, if I were to call a programming language a "Modernist" language, I'd think of something that prizes elegance. It can't just be a small language, it has to be a small language with a few features powerful enough to actually do more.
I would think of languages like Scheme or Smalltalk or C as fitting that label. But not JavaScript or Java or C++.
And if I were to call a language "Postmodernist," I'd expect a language to incorporate historical motifs, whimsey/surprise, and arresting/attention-grabbing features.
Perl might fit that bill. C++ manages to be "more" without being postmodernist, IMO.
It should be something that:
- Exposes the construction materials
- Implies mass and permanence
- Is usually institutional, e.g. libraries, government buildings, public housing. Only rarely shopping centres or company head offices (which were usually done in the "International" style when Brutalism was a thing).
What fits that bill? How about SQL?
> Exposes the construction materials
Unlike most programming languages, the user has to keep the Stack in mind when programming.
> Implies mass and permanence
Its minimalist design made it extremely small and efficient
> Is usually institutional
I'm not sure how that fits into a programming language. But Forth is often used to write things like bootloaders due to its minimalism.
may i submit https://metacpan.org/pod/Acme::Bleach
On the other hand, what about APL? Although the syntax looks just as much like line noise as Perl’s syntax, it is actually a very elegant language. Is APL also a modernist language?
For almost all languages, Perl included, this onus is mainly on the programmer. You can churn out gritty spaghetti in almost any language. Perl code doesn't have to look like what Perl programmers put out in the 90s. It's an old misconception that people refuse to let go of.
I hate this argument because it doesn't allow for any variation in the intrinsic readability of languages, or the style those languages encourage. Yes, you can write shitty code in any languages, but some languages encourage it, while other languages discourage it. I would say that Perl encourages unreadableness more than any of its peer languages, and the corpus of actual code out there is much more likely to be terse, unreadable noise than what you're likely to find in most python or ruby projects.
But some languages make this much easier than others
And I'd also credit Perl's rise to Lincoln Stein who wrote CGI.pm which was at the time the absolute state of the art for managing web applications with Apache and mod_cgi.
Edit: and Perl 4 had the % sigil.
TL;DR; I would say that you assertion is context sensitive. - For a junior Perl programmer or an outside expert those symbols are stumbling blocks. - For an intermediate Perl programmer and up, those symbols are tools that make the code more readable and expressive.
I got two ways of looking at that. First, I would look at Perl in the context of language. It is a more context sensitive language than some of it's close competitors. When you understand those \ $ % @ & sigils you gain the ability to know at a glance the context in which data is being used. Understanding @_, $_, allows you to write shorter code without sacrificing meaning. Part of the Perl philosophy is TIMTOWTDI. Most of those special variables also have an English equivalent. Instead of using $) which I never remember I can use $EGID, or if I think that's not explicit enough then I can use $EFFECTIVE_GROUP_ID to really spell it out.
The second way is that Perl has a steeper learning curve than it's close competitors. I see this like comparing Vim to Notepad++ and Emacs, or Haskell to well most other functional programming languages. Just because it took longer to learn, that doesn't mean it's better or worse at creating good code. It does mean that armchair pundits are less likely to be correct in their hot takes. They lack experience and understanding.
I believe sigils make string interpolations easy to support in a language. Consider JS that had to introduce an adhoc „${}“ expression to support those eventually.
Edit: a previous HN comment thread on how sigils are derived from practical linguistics: https://news.ycombinator.com/item?id=26659322
1: https://pragprog.com/titles/swperl/modern-perl-fourth-editio...
Ah yes the same snobbery and inability to take criticism that's been the standard since the 90s. And people wonder why Perl is dying (so is Emacs, Vim only survived because a significant part of the community decided to break away, refactor create a community that's more engaing and less snobbish). You forget what Perl was made for. Basically a replacement for awk/sed and so on and writing quick scripts that can be used elsewhere. If a newbie want to invest significant time and effort learning a new language why the hell they will spend it on Perl rather than a real language like C/C++ and in more modern times Rust, Go or Swift that actually creates performant code?
To me Perl it's a better tool for anything better than shell scripting without needing to get dirty with C or Go.
Criticisms of Perl often talk about the sigils and other punctuation characters which appear in normal Perl code, implying that's a big issue, or at least rather old-fashioned. (Although I really like Perl and got to know it intimately, especially the guts of the interpreter, I did feel it would have fared better without the sigils.)
That might be a fair criticism by modern standards, but if so, it annoys me that Perl gets singled out for punctuation while other popular languages don't. PHP has sigils everywhere, and many languages have some sigils. Rust has quite a lot of special punctuation syntax that has to be written often. Aside from sigils, Rust code looks to me like it has a similar amount of punctuation-oriented syntax as most of the Perl code I used to write.
>opposition to epistemic certainty and the stability of meaning
Yep, that's Perl.
> Minimalism describes movements in various forms of art and design, especially visual art and music, wherein artists intend to expose the essence or identity of a subject through eliminating all nonessential forms, features, or concepts. Minimalism is any design or style wherein the simplest and fewest elements are used to create the maximum effect. - wikipedia on Modernism
The current crop of popular languages does it really well. They aren't designed starting from any kind of simple theoretical construct like stacks or lisps or machine code, but they do always watch your back and prevent many unsafe(Unsafe in the sense that they allow common mistakes that are hard to detect automatically) constructs, while providing equally easy constructs.
A lot of the value in moving away from modernist thinking is that you actually have fewer concepts to work with. In programming, the usual goal of minimalism is to let you build exactly what you need.
Since you're building it yourself as you go, the language effectively has every imaginable feature, minus any syntactic sugar for any of them. I suppose that's where the idea that all projects eventually include half of common lisp comes from.
Perl's rich but predefined set of language and syntax features was a wonderful advancement, but other languages have since combined that with a lot more safety and opinionatedness.
Also, TIMTOWDI starts to suck in a team where everyone thinks they can be clever about their style (simpler languages like Golang, which I don't really love, tackle this better). Especially when you have an entire application in the range of 100KLOC written in Perl. My next project after that was in Java, which in all seriousness, felt amazing. Just like Perl felt when I discovered it after having to write tons of shell scripts.
"Look at the big picture. Don't focus in on two or three things to the exclusion of other things. Keep everything in context. Don't go out of your way to justify stuff that's obviously cool. Don't ridicule ideas merely because they're not the latest and greatest. Pick your own fashions. Don't let someone else tell you what you should like. 'Tsall good."
Post-modernism is not so much about picking-and-choosing and going-your-own-way, but it is about looking at the big picture and keeping everything in context. Importantly it's not about the total rejection of assumption and consistency, but about critically challenging and analysing them.
I think a lot of folks unfortunately continue to approach it in this same way, but in 202X we often make the additional mistake of assuming that the "modernism" that "post-modernism" is rebelling against is our contemporary "modern" society. That often gets misrepresented as a rejection of the enlightenment or some other extreme sounding position, but it's much better understood as a challenge of epistemic certainty and an attempt to break down and understand our ideological assumptions.
https://geekfeminism.fandom.com/wiki/Perl_is_my_bitch
>Perl is my bitch was a slogan used by the London Perl Mongers (a Perl user group) and printed on t-shirts ca. 2000.
https://geekfeminism.fandom.com/wiki/Acme::Playmate_talk
>At the Open Source Developers Conference in Melbourne in December 2006, Perl community member Adam Kennedy gave a lightning talk (a short (5 minute) talk for which he didn't have to submit an abstract) on the CPAN Acme::Playmate module, a joke Perl module designed to download the measurements of Playboy magazine Playmates from the Playboy website. (The 'Acme' namespace in Perl is the joke namespace.) During his talk Kennedy showed (twice) a single still photo of a Playboy model.
https://geekfeminism.fandom.com/wiki/Randal_Schwartz
>Schwartz often comes up in discussions of sexism in open source because of his open enthusiasm for Hooters restaurants, which he mentions frequently in professional contexts.
>[...] In 2001, Randal's company, Stonehenge Consulting, ran a Hooters Wings Promotion at LISA, a sysadmin conference (an example of booth babes).
>"Stonehenge ran a Hooters Wings promotion at the booth at LISA 2001. We gave away 1000 wings in about 45 minutes, with the aid of two Hooters girls Sarah and Lacey."
https://web.archive.org/web/20080212061647/https://www.oblom...
>notes on: perl lightning talks, impressionistically rendered» Stumbling into the Perl Lightning Talks now. Randal Schwartz (looks like Randal. Certainly wearing Randal-like clothes. He's the Hooter's guy, right? I always get him and Tom Phoenix confused. Okay, definitely Randal.)
https://geekfeminism.fandom.com/wiki/Stonehenge_OSCON_partie...
>At OSCON, between 2001 and 2009 (several reports during this period, not necessarily every year), Stonehenge Consulting has held parties on one evening of the conference. At these parties, there are usually women present who are not otherwise connected to the conference. They have variously been reported as scantily clad, present to "entertain" the guests, etc. It is unclear whether these women are connected to the venues in which the events are held or are friends of OSCON attendees.
https://geekfeminism.fandom.com/wiki/Michael_Schwern_v._Noir...
>Michael Schwern, prominent Perl developer and keynote speaker at the National Center for Women & Information Technology's 2013 summit, was arrested in Portland, Oregon on Sept 19, 2013 on two counts of misdemeanor domestic violence charges against his then-spouse Nóirín Plunkett -- specifically, harassment and strangulation.
https://arstechnica.com/gadgets/2021/08/the-perl-foundation-...
>The Perl Foundation is fragmenting over Code of Conduct enforcement. "I'm fresh out of ideas with regards to handling toxicity in the Perl community."
>[...] I have personally used and enjoyed the Perl language for nearly 30 years, and it's distressing to see the bigotry and edgelording coming from prominent elements of the community—not to mention the board's failures to respond decisively. The Perl community is not the first to struggle with "culture wars" revolving around a code of conduct, either, which makes it all the more puzzling why its board seems incapable of formulating one.
http://blogs.perl.org/users/sawyer_x/2012/08/this-is-not-tol...
>This is not tolerated. By Sawyer X on August 31, 2012 10:46 PM under Rant.
>There had been several posts recently about disgusting sexist idiotic behavior on PerlMonks. Most people know my opinion on these issues very well, but I don't think that's good enough. I think we need to actually bring it up and discuss it. I want to thank all the people who wrote about it and specifically Joe McMahon who both spoke of it on blogs.perl.org and on Perlmonks here. No, this is not to be taken lightly. And no, I will not shut up about this. And yes, my post is probably gonna be long. I'm sorry, but I need to put it out there.
http://blogs.perl.org/users/joe_mcmahon1/2012/08/why-im-cons...
http://www.modernperlbooks.com/mt/2012/08/you-dont-get-to-ch...
http://blogs.perl.org/users/tinita/2012/08/to-be-or-not-to-b...
http://blogs.perl.org/users/lichtkind/2012/08/to-say-schwern...
http://www.perlmonks.org/?node_id=989181
http://blogs.perl.org/users/joe_mcmahon1/2012/08/why-im-cons...
Perl doesn’t need to be Python. It’s great to be the #20 language.
Ah the good ol days....
On Perl, CPAN was and it's still amazing, and lots of stuff came from that. For example, Mojolicious for the web, BioPerl for bioinformatics and Rivescript to write silly chatbots, among others. Oh, and pkg_* under OpenBSD.
INB4 gen-z's rant on "PeRl It'S UnRead@ble", check the intro from "perldoc perlintro".
EDIT: Unless I'm sure the deleted link it's right, I'd avoid posting it.
Postmodern in this instance means rejecting modernism by remixing eclectic elements from various periods.