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.

Some--not all--of the people working on perl really want so-called "cruft" to disappear. I'm not a fan of that attitude for such an old language with such a rich history of backwards-compatibility, and I definitely don't think it's going to accomplish some kind of perl renaissance. I think it would be better to double down on what makes perl unique. When I watch Signes giving a talk like https://www.youtube.com/watch?v=FlGpiS39NMY where he shakes his head at variables like `$;` or `$,` (29:20 in the video) ... it looks like the leaders of perl hate how strange it is. That worries people like me, who love perl _because_ of its quirkiness, not in spite of it. Surely people who want something more consistent have moved to Ruby long ago.

Personally, so long as all that stuff's behind a feature bundle I'm all in favour of it.

A little nitpick: it's not about "multidimensional hashes", but rather "multidimensional array emulation". Steer clear of it, if you can.

I personally don't mind using variables like $; or whatever. Some prefer to "use English" and use longer variables name for the same effect. More power to them.

I just wrap the call with the proper "## no critic (...)" and off I go.

I have a feeling you're reading Richardo Signes wrong, by the way-- he likes to play up what a negative kind-of-guy he is, and makes critical remarks about the state-of-perl in public that some people take a little too seriously. Perl-haters gotta hate, and they really loved to link to his talk with the title about how perl is an "Ongoing Disaster" or some such.

Feature bundles don't bother me, but if I read between the lines (possibly too much), comments they make seem like they are still looking for an opening to remove some of these features entirely. I hope I'm wrong.

(I remember the Ongoing Disaster talk, I personally thought it was fun)

https://gist.github.com/Grinnz/be5db6b1d54b22d8e21c975d68d7a...

https://github.com/Perl/perl5/wiki/Perl7-FAQ

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.

I am surprised you didn't mention Perl 11 which is try to mash Perl 5 and 6/Raku together. Is that still happening? Or do I have it wrong?

"How Perl compares to Python": The first thing I tell Perl programmers who are starting to learn Python: There are Perl-style references in Python. (If you are not familiar with Perl: These are a roughly pointers, and can be 'undefined' / null.) In short: You cannot create a reference to a scalar in Python. Perl hackers then scratch their head and ask, "Well then, how do I build XYZ data structure without...?" The easy workaround is a single element tuple or list. "Aha!" Otherwise, Perl programmers can adapt very quickly to Python.

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.

Perl is a more expressive, "cleverer" language. But I noticed when I moved to Python that I write better code. Too often in Perl I would try something clever and terse, then two days later it would bite me in the bum and cause more problems than it solved.

I would still pull out Perl for some quick bash replacement type script, regular expressions are so much nicer in Perl, but for larger scale long term projects where maintenance is important, I would go for Python.

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"

    use v5.36;

Point is. As soon as I tell someone "you have to use tarball/cpan/cpanplus/cpanminus to install the feature "named parameters" they leave.

But now it's here

I prefer text. Binary is too early optimisation and record oriented is too restricted.

In "Windows Powershell in Action", Bruce Payette (one of the co-designers of Powershell) states:

"NOTE PowerShell uses the at symbol (@) in a few places, has $_ as a default variable, and uses & as the function call operator. These elements lead people to say that PowerShell looks like Perl."

"In practice, at one point, we did use Perl as a root language, and these elements stem from that period. Later on, the syntax was changed to align more with C#, but we kept these elements because they worked well. In Perl terminology, they contributed significantly to the 'whipupitude quotient' of the language."

https://perldoc.perl.org/Win32

https://metacpan.org/search?size=20&q=win32

RAS, OLE, COM, ODBC. Perl did magick on NT/2K/XP.

That's an axis, not a quotient. See page 2/slide 3&4: <https://www.shlomifish.org/lecture/Perl/Newbies/vhll-slides....>

Powershell: 2006

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.

In Python, that heuristic wouldn't work nearly as well.

...and people endlessly complain about it to this day.

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.

Alternating functions and regexps looks like this:

    [\&some_function, qr/some_regex/, \&another_function, qr/another_regex/]

So the design as stated is very contrived, to the point where it doesn't make sense, but existing constructs can be used to make sense of it with a change one way or the other.

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.

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

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.

@array[1] returns a single-element list-like thing. It mostly works, but you get a warning:

https://perldoc.perl.org/perldiag#Scalar-value-@%25s%5B%25s%...

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.

http://www.masonhq.com/sites

https://masonbook.houseabsolute.com/book/

The biggest problem for Perl was that PHP was almost built for the web, while Perl was "just a normal programming language."

I wonder where Perl would have been if there had been a packaged and easy to install version of Apache with Perl, mod_perl, HTML::Mason etc. pre-installed in some way in late 90s.

The big thing for PHP was how easy it was to go from "I've got a static HTML document that looks like what I want!" to "I've just added a tiny bit of dynamic content by sprinkling in a special tag!" on the majority of unix-based hosts. Deployment was uploading via FTP, just like it was with HTML. There's just so little conceptual distance or friction between static HTML and dynamic document/app, the pit of success is right there to fall into (granted, the peak of further success has some rocky roads out of that pit, but by then you've got momentum!).

On commodity hosting, Perl got typecast as a CGI tool instead. Which had its own power (CGI is kinda the OG serverless)... but not as easy a jumping off spot for anybody who was doing HTML.

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.

CGI.pm was created long (...) before PHP was released.

You could even get modules that would allow you to inline Python just like PHP, although the interaction between that and mandatory indentation could get a bit "interesting".

Also perhaps ironically, this style of mixing code and HTML has generally come to be regarded as an antipattern. PHP may still be able to do that, but woe unto the project that wants to write tons of code that way. But it's still the foothold PHP used to wedge its way into at least the B tier of languages.

Tell that to the React world :P

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.

If that's your interpretation of a fad then you're still wrong. The dominant reason why people choose Python is the strong ecosystems that have been built around it - everything from scientific computing, data analysis, machine learning, web frameworks and so on. This happened over decades. And it's no coincidence why so many good libraries have been written in Python. All of their creators have publicly admitted they loved Python syntax, wanted to code in Python and nothing else in their jobs even if it means having to write a whole different library. And because Python has so low threshold for beginners, these caught on fairly quickly and took over. Python core developers listend to the community and quickly adapted to their needs. Meanwhile Perl gods buried their heads in their pursuit of the most perfect programming language ever - and we all know how that turned out.

> So why Python didn't succeed when Perl dominated?

Who said it didn't succeed? It's growth was just slower than Perl. It was slowly building up steam. While Perl exploded and ran out of fuel in 10 years.

> Do not write scripts the way we write shell scripts.

This has nothing to do with writing new scripts. Read my comment again. This is about maintaining/adapting legacy code from 10-20 years back. In 90% of the cases for Perl that means a complete rewrite because there's no point spending time understanding the gibberish. I can't really go back in time and tell those people to write good code or be "good practitioners". And if I have to do a rewrite now, there's absolutely no reason to choose Perl, that ship sailed in early 2000s.

I can see stability as a knock against Python, but outside of 2 vs 3 the only breaking changes I've really had to deal with were relatively short term issues with third party libs.

A few examples:

Perl (flexible/optional function call interface)

    print "hello world\n";

    print("hello world")

    print "Hello $name\n";

    print("Hello %s\n" % name);

    if (!-d $dir) {
        mkdir $dir;
    }
    chdir $dir;
    foreach my $f (glob("*.txt")) {
        ...
    }

    import os
    import glob
    # google for usages

    if ($do_A) {
        my $x = "A";
        work_with($x);
    } else {
        my $x = "B";
        work_with($b);
    }

    if do_A:
        x = "something" # did I changed x for somewhere else?
        ...

    my %opts;
    while (<In>) {
        if (/(\w+):\s*(.+)/) {
            $opts{$1} = $2;
        }
    }

    import ...
    ...
        m = re.match(r'...', line, re_flags)
        if m:
             opts[m.group(1)] = m.group(2)

Python's philosophy is "There should be one-- and preferably only one --obvious way to do it", but obviousness is subjective to some, and for the rest, you need learn/search/train the "one" way.

I agree scope leakage is a major stumbling block with Python for sure, but it only occurs with control-flow so rarely causes actual issues once you're aware of it. Aside from that my biggest qualms with Python are the typesystem and whitespace for scoping, but those two don't cause much trouble for typical scripting purposes.

And, for what it's worth, Python's f-strings have been the go-to string formatting approach since 2016 so your example becomes something like:

  print(f"Hello {name}")

  >>> f"The current year is {datetime.now().year} and the value of pi is approximately: {22/7:.2f}"
  'The current year is 2022 and the value of pi is approximately: 3.14'

"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?

That's like postmodern furniture design. "This couch was_a giant pair of lips," meaning that although it is implemented as a pair of lips, we'll treat it as type couch.

Same for, "This chair was_a giant baseball glove."

> 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?

https://www.youtube.com/watch?v=a9xAKttWgP4

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.

I don't understand what you mean by this. How ever does that argument mute Perl's dynamic expressiveness - which lends equally to unreadable syntax as much as clean syntax - or the commonly encouraged patterns in Python?

> "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"

Because Perl saw in its infancy back in the 90s much higher use than Python and Ruby did. It's the same with PHP, which looked like shit in the 90s even if it didn't need to. Incidentally, PHP, too, suffers from stubbornly outdated criticism.

I think you're too hung-up on the languages themselves, and forgetting that programmers, and software development and engineering as a process and as an art, evolved a lot the past 20 years - much has happened also with how people write C today compared to the 80s and 90s.

OK, so Perl isn't assembler. Still, it's a lot easier to write unreadable code in Perl than it is in some of its contemporary languages. You don't have to, sure. You could write clean, pretty Perl code. I know, because I've seen it. But in my experience, that definitely wasn't the common case.

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.

It's also clearly not an anagram of REPL. I wonder if anyone ever figured out how to write REPL with a keyboard. I'd like to learn it some day.

(REPL was written in a crazy character set and relied on custom printed punch cards. I think it was the perl of its day.)

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.

That is why we send any code that cannot be read by a fresh CS grad back for rework. It turns out you can solve everything with very basic and straightforward syntax.

But then we also don't use perl.

It's also why I'm not really all that sympathetic to "but $NEWLANG doesn't let me write something that extracts from a hash and then map all the elements with an inline anonymous function, filter the results, and then invoke them all and put the results in a single array all in one line!". I worked for decades, plural, in languages that did permit that, and what I learned is that the more professional the code gets, the less you should be doing that. By the time you've broken it out in a way that won't confuse everyone, giving all the intermediate values professional-quality names and adding a few comments, it turns out the delta between Perl and things like Java or Go or other such "stodgy" languages has closed a lot. Not 100%, by any means, but closer, and in the meantime those stodgier languages have been steadily closing the gap from their end too. In the meantime I get a lot of value from the static guarantees those languages have.

Isn’t this what APL/J/Q are for?

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...

https://perlmonks.org/?node_id=989879

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.

Also, https://www.youtube.com/watch?v=0jK0ytvjv-E

The badly written stuff needs more "maintenance", and the people who need to work on it are more likely to complain (and I think you're stuck on confirmation bias).

In the late-90s, the early web gold rush was on, and a lot of amateurs started writing perl in a hurry as their first language. The fact that they could do anything at all is actually pretty amazing, and I'd say that's a point in perl's favor.

So my aversion to Perl could be considered a pragmatic solution to that problem. :-)

Can’t really be a comment without a aside-from-the-point slurring

I tought that because most of the books are outdated (15 years on IT it's an epoch), albeit the sed/awk/perl/*sh and Sendmail books are still godly useful.

If you want these books very cheaply, the Perl CD Bookshelf usually sells for about $5 used. You get Perl in a Nutshell in print and a bunch of the other books on CD.

A better introduction to Perl these days is Modern Perl, which is available to read online for free or you can pay for a print book. http://modernperlbooks.com/

Also, there are legal issues over promotion of pirated content.

Also, there are ethical concerns over pirating content that is easily and cheaply available legally.

Also, I said "Please" and didn't force anything on anyone.

Also, under a strict interpretation posting directly to pirated material is likely a violation of the Terms of Use for HN. https://www.ycombinator.com/legal/#tou

Postmodern in this instance means rejecting modernism by remixing eclectic elements from various periods.

Damian Conway highly recommends using the combo of 'xms' his Perl Best Practices Book ( https://www.oreilly.com/library/view/perl-best-practices/059... ).

The revised and considerably newer "Modern Perl Best Practices" video series on O'Reilly's learning platform is particularly good also ( https://www.oreilly.com/library/view/modern-perl-best/978149... ) - with lots of discussion of regexes.

I imagine asm programmers feel the same way

fwiw I think this world needs less "it's too hard for me" and more "let me roll up my sleeves and dig into this"

I’m gonna need a hell of a lot more of my time back for that.

Dated pop-culture references in something that's ~25 years old is hardly surprising.