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.