[grabcocque]

You know there was that recent Stackoverflow analysis that concluded that Perl was the most disliked programming language?

It got me to thinking about how Perl managed to become quite so profoundly disliked, and I remembered these papers and thought that maybe things like this are the reason.

[GuB-42]

Perl is designed to make life easier for the guy who writes the code, not the one who reads it.

The motto "there is more than one way to do it" is telling. It allows beginners to write code the way they are most familiar with and give experts a large toolbox to be most efficient in many situations. The trouble is that while the writer only needs to know a subset of the language, the reader has to know everything in order to read other people code.

This philosophy make it very suitable for quick hacks, and that's its primary use. The problem is that quick hacks have a tendency to stay, and some poor guy need to maintain that mess. And when your experience with the language is to maintain the unmaintainable, hate is totally justified.

Note that is is possible to write clean Perl, but it requires effort, and unless you are writing Perl modules, there are probably better languages for that.

Compiler undecidablity is not a problem. Sure, it is not intellectually satisfying, and it may be troublesome for some application where formal proofs are required, but for a language like Perl that is all about practicality, no one really care.

[falsedan]

> Perl is designed to make life easier for the guy who writes the code

Whenever I write perl, I feel like the binary is actively fighting me, not helping me…

perl is designed to make simple things easy, and hard things possible. Readability is up the the programmer, and writability is up to the editor.

[dozzie]

> The motto "there is more than one way to do it" is telling.

The more telling is you omitting the other half of the motto. TIMTOWTDIBSCINABTE

[virgilp]

> TIMTOWTDIBSCINABTE

That's an apt motto for perl. One doesn't even need to know what it means.

[jwilk]

There's more than one way to do it, but sometimes consistency is not a bad thing either.

[bshimmin]

Has anyone been able to do this for PHP's T_PAAMAYIM_NEKUDOTAYIM yet? (I know it's not an acronym, but I wish it were.)

[mhd]

People don't really care about how hard it is to parse a language, and complex grammers might actually be due to making it easier for humans. One of the bigger differences is IDE support, but more regular languages that compete with Perl had about the same issue here...

Perl derives its dislike from about the same source as BASIC (and arguably PHP): Early errors/preconceptions and plenty of non-programmers writing code (home computer users, sysadmins). Perl4 was used for some pretty hacky jobs, replacing sed/awk/shell combinations (which were horribly fragmented across the unices of that time). Modular Perl5 code had little to do with that, but by then the damage was done. Early CGI scripts didn't exactly help, either.

Modern Perl is a step further than that, but when Moose and the like became popular, people already moved away to PHP or Ruby, both being part of the same family.

[dmytrish]

Perl has a lot of crappy language design decisions (which make it "fun" and a tire fire waiting to happen in any large-ish codebase):

- interpretation of a variable (is it a list, a number, a string, a hash?) depends on the context in which it's used, and the context depends on, um, its context;

- pervasive global state (`$_` and friends);

- you can mess with compile-time operations, patch the language on the fly, e.g. during module imports;

- autovivification: a single read by key from a hash is enough to actually create this key; variables are a number and a string at once, but the number will not be computed until you need this variable in number context. Reading a non-existing key in a hash as a hash actually creates a new subhash.

- ties: you can override access to any variable by your methods;

- the built-in data structures are special, there is no sane way to emulate and extend them (but, as usual, for sure there are insane ways);

- the built-in `sort` takes a code block (not a closure with parameters), that has magic variables `$a` and `$b` appearing out of thin air. It looks like a closure, but it's not.

- features are often added in a convoluted way. E.g. there was a (now deprecated) feature that allowed `push` and `shift` to take a reference to a hash instead of a hash directly. How was it implemented internally? Basically by backpatching the error condition when the existing `push`/`shift` choked on a reference.

- the language design principle is "Do What I Mean" (where the "I" part varies). It's ironic that a language built "for human communication" by a linguist (what could possibly go wrong?) is harder to read and to reason about that programming languages built around logic.

On the other hand, if your business brings enough income to pay good developers with strong discipline, you can still have a big codebase in Perl and sustain it for years: it's better to have a terrible language and good engineers than bad engineers and a good language.

[hoytech]

Most of these design decisions are very useful and pragmatic, and not everyone regards them as "crappy".

Additionally, there are several misleading statements in your post. I expect you are aware of the following but just for the record:

> - pervasive global state (`$_` and friends);

Perl uses dynamic scoping (https://en.wikipedia.org/wiki/Scope_(computer_science)#Dynam...) when setting $_ and friends. For example:

    $ perl -E '$_ = "A"; say; say for ("B", "C"); say;'
    A
    B
    C
    A

For me, dynamic scoping (and, relatedly, RAII) is sorely missed in languages that don't have it. (Although I do agree about $a/$b in sort -- that's a language wart, but not too bad in practice)

> - autovivification: a single read by key from a hash is enough to actually create this key;

Not true:

    $ perl -MData::Dumper -e 'my $h = {}; $h->{a}; print Dumper($h)'
    $VAR1 = {};

You need to read it as a hash or array reference for it to autovivify:

    $ perl -MData::Dumper -e 'my $h = {}; $h->{a}->{b}; print Dumper($h)'
    $VAR1 = {
              'a' => {}
            };

Autovivification is another feature that I miss in languages that lack it.

Your points about the perl5 implementation are definitely accurate, although I suspect a lot of language implementations have their own dirty laundry as well. :)

[carlmr]

>It's ironic that a language built "for human communication" by a linguist (what could possibly go wrong?) is harder to read and to reason about that programming languages built around logic.

It's not like having a fascination with weird language quirks makes you have good taste in languages. Especially because weird quirks are the end of usability.

[daotoad]

Perl is essentially a pigdin or creole language composed of C, shell, awk, sed and POSIX concepts with bits of Lisp thrown in.

If you know Unix, you will already know about 80% of perl. If you know Perl well, you already know a lot of Unix concepts.

Perl is a pain to learn if you don't have a solid Unix background. However, IME, if you acknowledge the sources Perl draws from, look at how they're integrated, and spend some time learning the underlying technical culture, it actually simplifies the learning process.

Interestingly enough, it's also easier to learn a natural language if you spend some time learning the underlying culture.

[carlmr]

>Perl is essentially a pigdin or creole language composed of C, shell, awk, sed and POSIX concepts with bits of Lisp thrown in.

That mixing and matching seems exactly like the quirks a linguist would pick up that lower usability (at least for the general user, Unix users are kind of used to being thrown in the deep end of the usability pool).

[psergeant]

Perl is disliked because it has a very shallow learning curve to do badly, and a high learning curve to do well. Therefore, lots of people see a lot of bad code, but also people don’t understand a lot of good code.

[Ultimatt]

Its the main reason any language is hated. JavaScript now is less hated because the tooling got there and people were educated at university to program in it well. PHP and Ruby are on the list of disliked on the SO analysis. Which is basically nonsense for modern versions of both languages. I really wish these stats would state "Perl 5" too, as Perl 6 is really modern in semantics and syntax and is nice to code in.

[carlmr]

I agree that Perl 6 is the first readable version of Perl. It might actually be considered a nice language. Yet all the tools that are newly rewritten by our Perl guys are in Perl 5 because that's what they know.

[Ultimatt]

Well not just what they know, but what all their existing stuff is written in. Makes sense too. The two Perls aren't really that compatible, far worse than migrating Python 2 to 3 and companies struggled with that manoeuvre. You can run and call each language from the other, with some in memory wrangling between https://github.com/niner/Inline-Perl5 But the same is true for Python and Java objects.

[ionforce]

This is one of the most well-reason and true responses I've ever read about Perl.

Who are you?

[psergeant]

https://perl.careers/

[lazyloop]

Perl being a dead and disliked language has become a meme. But the community is still very much alive and a lot of cool stuff is being built with Modern Perl. http://mojolicious.org

[pjc50]

Perl used to have fans with meetups and so on. I've not heard of these for a long time.

IMO three things killed Perl, leaving it as an unpopular legacy husk:

- loss of ecosystem. The high points for Perl were CGI.pm and its use as a "super awk" by sysadmins. The first was obliterated by other ecosystems, better and worse: PHP, Rails, Node, Go, and so on. The second was obliterated by "servers are cattle not pets": people have moved from meticulous hand-administration to the use of containers, Ansible, etc - or away from systems administration altogether to AWS or "serverless".

- Perl 6 transition. Second-system effect at its highest. The long wait for this to be completed absolutely destroyed incremental improvement because everyone was waiting for a big bang that came very late. Python managed to avoid this level of community damage but has still split into two languages, Python 2 and Python 3.

- the "two Perls" of style; one was the Wall-influenced style that looked a bit like English. The other was sigil-heavy and incomprehensible. Eventually people decided that it was easier to put up with syntactic whitespace than remember all the $? and $| and so on, so a lot of the Perl audience moved to Python.

[dozzie]

> IMO three things killed Perl, leaving it as an unpopular legacy husk [...]

I don't really think it was any of these. There's much simpler mechanics at play here: Perl's competition (Python and Ruby) has about the same expressiveness, but is much easier to learn, so for a long time very few people have chosen Perl to learn. There was simply not enough young blood to replace old timers that were retiring, dying, or migrating to other languages.

[yellowapple]

I find that interesting, since of those three, Perl was the first language that really "clicked" for me (Ruby was almost that language, but it didn't start clicking until after I had learned Perl; Python still ain't really clicking, though it's gotten a bit better lately).

[cestith]

Perl5 is the second system. That's why it seems so bloated. The releases of Perl5 since Perl6 work started actually became larger and more frequent. There's lots of work between, say, 5.8.8 and 5.28.8 including making lots things to do with regexes iterative that used to be recursive. Old features now finally have explicit deprecation schedules. Lots of features in the core and popular libraries are back-ported from Perl6.

If you haven't, I suggest reading through https://pragprog.com/book/swperl/modern-perl-fourth-edition

[oblio]

> Python managed to avoid this level of community damage but has still split into two languages, Python 2 and Python 3.

The fracture is very slowly healing. Outside of some huge corporate hold outs with a lot of Python 2 code (Google & co.), Python 3 will win out.

Perl 6 vs Perl 5, on the other hand, I don't even know if you can call it a fracture. A new start would be more fitting.

[yellowapple]

It's definitely a new start, but both Perl 5 and Perl 6 each have various modules bridging the gap between the two. Yeah, they're definitely separate languages, but (at least in theory) they're very much interoperable.

I don't know much about the Python ecosystem, but my impression is that besides the 2to3 program there wasn't really much of an effort to make them work together.

[cutler]

A big contributor to the demise of Perl, IMHO, was the failure of Catalyst and mod_perl to compete with PHP and Rails. mod_perl security was too risky for most ISPs and Catalyst, with it's clunky subroutine attributes style of routing and hefty CPAN dependencies, was a pain to get up and running. Mojolicious was a big improvement but too late to stop the PHP and Rails defections.

[rurban]

It's more caused by the toxic climate amongst it's maintainers, paired with technical and management incompetence.

When Larry Wall was still the lead a lot of progress was made, but then it reversed course in the last 20 years. Every single competent developer left or was booted, and not a single of the many designed features for Perl6 were properly implemented in perl5. Perl5 is now purely a religion, with the heresy to express of loss of faith in the supreme leaders gets you booted, whilst uncivil name-calling and technical destruction by wannabe middle-managers took over.

The undecidedability problem is caused by the dynamic lexer. It's actually a feature to drive the static parsing rules dynamically.

[Ultimatt]

Given this commentary, its probably worth highlighting you're the developer of an entire fork of the perl codebase... Rather than the average user.

[ceronman]

Perl is a very practical language. But this practicality has been achieved by building features on top of bad design. The result is a big, complex and quirky language. To make this worse, the community decided to "fix" this re designing the whole language from scratch. They created Perl 6 which has a much better design, but it's incompatible. The community now it's broken in two and the future doesn't look that good.

[zbentley]

I think the word "big" above is often overlooked when discussing Perl (5). For a scripting language, there are an incredibly huge number of core language features. Even compared to something like Ruby or a lisp-like language with a true templating/macro system. It's easily up there with c++ in terms of "number of (sometimes crazy) things you can do with the core language/distribution out of the box".

And that's not even a statement about how many ways there are to the same/similar things things; these features all are intended to facilitate different stuff. I think it is the biggest language I've ever programmed in, fighting for top spot with C++.

I think core-language-feature counts are something it's better to have in moderation. JavaScript of ~2010 was far too small a language, so it had crazy library/cargo-cult utility bloat. Lisp is somewhat similar: it's elegance in its small size and simplicity, but that results in a lot of beginners (re)writing a lot of unnecessary code. Perl and C++ have too many core-language features; everything else is somewhere in the middle.

...and all that is without even getting into some of the insane language extensions you can find in third-party libraries. There's an on-after-module-load hook someone wrote that's implemented in terms of a syntax extension to the language, that isn't quite an operator or a statement. There's a coroutine library which is written mostly inside to the fatal-killsignal core dump handler I think (or something similar). And the list goes on.

[kazinator]

> I think core-language-feature counts are something it's better to have in moderation.

If an app needs something, it will either get it from there, or failing that, from add-on packages.

That only matters for fitting into a small embedded system where you can perhaps get a smaller image if you just bundle the exact set of packages that are required.

Due to inter-package dependencies, that plan can easily be foiled.

In the end, it's better to have a big, "batteries included" language. For one thing, it is all released at once. No separate versioning for one hundred different packages. The regression test suite for the language can cover that functionality which would otherwise be in packages. No nonsense of releasing a new version of the language and then relying on field reports about broken packages.

[zbentley]

I agree about batteries-included languages, but that applies more to library-type tools, IMO, than language features. A library-type tool is something like "I need to get an md5 hash; I hope a function to do that is included with the language distribution so I don't need to go find a library!". A language feature is something in response to questions like "How do I express that I'm calling a method on an object? Or that I want to read a key out of a dictionary object? Or automatically generate code for a method when I call something that doesn't exist?". Those are sometimes implemented in terms of libraries, but are instead often implemented in the syntax and behavior of the language/runtime itself. For example, Java has a specific syntax for "call a method on an object instance or class", and that's "thing.methodname()". Sure, it could be implemented in the library style ("call_method(thing, 'methodname', args[])"), but that's typically not what people want. Perl tends to have, in my experience, an outlier surplus of language features and libraries.

I'm only arguing for moderation in the syntactic/language-feature department; I agree with you that a good, curated set of wide-ranging libraries is something that every language should have--ideally as part of the core distribution.

[kazinator]

> but that applies more to library-type tools, IMO, than language features.

I'm a Lisp person of many years, so my perception of this distinction has gradually atrophied, dried and fallen off. But even in this context, I would still rather have a larger language (more stuff which is Just There), even though more kinds of things can be add-on modules in Lisp than in something like Perl.

[hultner]

It's actually quite interesting, from what I've understood it's one of few well adopted programming languages that's designed by a linguist and made primarily to be easily understood and written by humans.

At the time of inception and around the peak of popularity I do believe it was a quite innovative language. But by now we have a much larger set of languages aimed for the same target group, many of which have gained larger adoption among developers of this time.

In a way I can almost see Node as "the new Perl" in the sense that it's a widely used language across platforms praised for it's large set of available libraries and ease of creating "quick n' dirty"-hacks.

[jasode]

>how Perl managed to become quite so profoundly disliked

I'm guessing the reasons are actually more conspicuous than computer science concepts of "undecidability" since most working programmers don't read academic papers to judge whether they like/disklike a programming language.

The conspicuous reasons seem to be a combination of:

1) PERL's usage of sigils.[1] One the one hand, it makes code compact and terse. On the other hand, many perceive the source code as "line noise" or "sigil hell". This is the opposite problem of other disliked languages like Objective-C where people complain it's too verbose.

2) PERL not having a constantly updated ecosystem that keeps up with new trends in computing. PERL was great for text munging (alternative to sed & awk). However, PERL wasn't extended as the driving language for dynamic web pages (Brendan Eich created Javascript instead of embedding Perl interpreter in Netscape browser), or GUI data entry forms programming (Java and C# gained popularity), or machine learning (Google developers designed Python to be 1st class in Tensorflow), etc.

tldr: PERL is perceived as "legacy" with ugly syntax

[1] https://en.wikipedia.org/wiki/Sigil_(computer_programming)

[Ultimatt]

Point 2 is kind of nonsense. The ecosystem is incredibly big and keeps up with most things. Name something then search here https://metacpan.org/ The main missing stuff is anyone marketing heavily their libraries and there being communities around them etc. Like probably no one knows what PDL is, even though it was around long before numpy+scipy etc. Before data science trended in the mind of hipster VCs and coders. The naming was to try and win over people from the IDL language, used mostly in image analysis in physics/geography. A niche crowd to be sure. Perl sort of never caught on to the modern style of advertising what its got. In the same way no one really advertises grep, awk or sed but lots of people still learn and use them.

[zbentley]

The size of the CPAN is certainly impressive. However, past a certain point, a big, multipurpose, monolithic Perl codebase being worked on by a ton of different developers is going to have significant problems caused specifically by the use of different CPAN libraries: many, many quite common libs do not "play well" with each other in quite simple cases. And I'm not talking about "I'm trying to glue together two third-party tools that weren't written with each other in mind", I'm talking "I have a request handler that once, an hour ago had to load and call a function in a given module, and is now issuing cryptic errors on all requests of a certain type because they happen to call a function in a different, totally unrelated module that worked before".

This is largely because of the sheer volume of weird global state inspections/mutations you can do in Perl--or I guess it's more accurate to say that Perl has a conveition of it being "OK" to heavily and frequently inspect and mutate global state. You can monkey patch in many languages, and sometimes it's even encouraged (Ruby), but only in Perl is it not uncommon to see monkeypatch removal or seriously altering replacement of core functionality. I've had modules hackily unload other already modules because the loaded modules' names matched a buggy load-time regex. I've had packages clobber text handling or encoding routines in other packages at compile time, or only after calling a certain function a certain way. I've had modules change the behavior of the core signal handling APIs so that any code that talked to them . . . didn't actually handle signals. And those are just the pithy examples that fit in a single sentence.

Now granted, this isn't a criticism of Perl-the-language but more of (depending on how you choose to interpret it) library authors who don't prioritize or even consider interoperability with other tools, or of Perl-the-community's conventions regarding when it's OK to go mess around in globally-stateful guts of code you don't control. You could also just as easily say that it's a symptom of the big, multipurpose monolith I had to maintain--which is valid, but other not-designed-for-huge-projects languages don't, in my experience, have problems quite this bad when they're forced to scale.

My goal isn't to cast blame, but to point out that CPAN is incredibly bloody far from a high-quality, stable, or usable code repository for certain very common use cases.

[Diederich]

> CPAN is incredibly bloody far from a high-quality, stable, or usable code repository for certain very common use cases.

Citation needed.

[zbentley]

Read the rest of my post. If you don't agree, that's fine.

[Diederich]

I read your post carefully, and I even agree with parts of it. There are major modules/module families that don't work together.

However, that's light-years from the claim that I quoted.

There are a lot of different ways of doing the same things in Perl the language and in the CPAN ecosystem. That's a strength and weakness. But in my experience, the authors of most of the modules care very deeply about doing things in a sustainable way.

[Ultimatt]

I agree there is a lot of dross on CPAN. I've also lived the frustration of seeing two kinds of exception handler TryCatch vs Try::Tiny in the same subdir of a codebase. The issue is really that a lot of basic modern functionality requires CPAN, and the core of Perl 5 is small and mostly not super helpful. Something akin to Moose in core as the new standard way to do OO would have been a good plan 10 years ago.

[jasode]

>ecosystem is incredibly big

I wasn't talking about the size of cpan because it's not relevant to my point. I was talking about Perl not being at the forefront of everyone's minds and being used as a 1st-class environment as computing entered new domains. E.g. instead of Sun or Microsoft taking an existing language like Perl and giving it a canonical IDE to let programmers write data entry GUI applications, they create Java & C# instead. When Google/Android decided on a development language for their smartphone SDK, they chose Java instead of Perl. It doesn't matter if cpan has mobile phone libraries now.

You seem to be taking my observations about Perl as some sort of veiled attack. I'm just reporting why and how Perl got to the state of being "disliked" today in programmer surveys. It's not about the "undecidability".

[Ultimatt]

Ok then your definition is corporate ecosystem then? Perl in general is hardly the stuff of scaled soft eng. in a mega corp. It wasn't designed for that, but to empower an individual to be highly productive quickly. With that in mind the ecosystem is super healthy, even by your definition. I'm more shocked Python has managed to bridge that gap, but so did Pascal at one point so I guess designed to be a teaching language wins out!

[jasode]

>It wasn't designed for that,

And I'm not "penalizing" Perl for that.

>I'm more shocked Python has managed to bridge that gap,

That's more to my point. Old languages like C++ and Python keep getting rejuvenated as 1st class drivers of innovation but Perl (the language -- not the cpan) keep getting ignored.

I was surprised when Google chose Python as one of the 1st class languages for its new Tensorflow instead of a new language like Julia. I do understand why they chose Python but nevertheless was surprised.

Same for C++. It gets rejuvenated in things like graphics programming (NVIDIA's CUDA SDK is C++ not Perl). And when Bitcoin showed up in 2009, it's canonical client was C++ not Perl. Also, updates to C++ via C++14 and C++17 were discussions that turned into reality whereas Perl 6's long development became a running joke about vaporware.

Perl5 and Perl6 don't really have any new stories like that where it gets rejuvenated. Therefore, it keeps dropping off everyone's radar as "legacy".

Whether Perl programmers are highly productive with Perl isn't really the issue.

[kbp]

> Same for C++. It gets rejuvenated in things like graphics programming (NVIDIA's CUDA SDK is C++ not Perl). And when Bitcoin showed up in 2009, it's canonical client was C++ not Perl.

Perl is not competing with C++; they're entirely different languages with entirely different usecases. Comparing it to Python is reasonable; comparing it to C++ is silly.

> Also, updates to C++ via C++14 and C++17 were discussions that turned into reality whereas Perl 6's long development became a running joke about vaporware.

Newer C++ versions are more akin to newer Perl 5 versions like 5.26 (May 2017), 5.24 (May 2016) etc. Perl 6 is a new language using some of the same ideas; comparing Perl 5 and Perl 6 is like comparing C++ and C#, not C++ and C++17.

[kbp]

> 1) PERL's usage of sigils.[1] One the one hand, it makes code compact and terse

Sigils have nothing to do with Perl's terseness; actually, they make code very slightly (one character per variable) more verbose. In Perl 5, $foo is a scalar, @foo is a list, %foo is a hash, etc. $foo[0] is the first element of the list @foo; it gets a $ because the element being accessed is a scalar. This is in contrast to most languages where variables are referred to like 'foo' and that's that.

[zbentley]

Utter and unabashed tangential pedantry: Perl should not be all-caps. The PERL "acronym" is actually a backronym (or "retronym" if you like): https://docstore.mik.ua/orelly/perl3/lperl/ch01_02.htm

[jasode]

The terseness isn't the variable name, it's the notation of the type:

  @foo 

... is more compact than C#...

  ArrayList foo = new ArrayList();  // C# v2
  var foo = new ArrayList();  // C# v3

And Perl

  %foo

... is more compact than C++:

  auto foo = std:map<string>;

[kbp]

But when you talk about Perl stagnating and losing out to other languages, the languages it lost out to were Python and Ruby, which don't require any type notation. It also lost out to PHP, which has sigils, but they don't carry as much information: $foo just means foo is a variable. Perl didn't lose out to C++ and C#; they were never really competing in the same domain.

In Perl, you write:

    my @list = (1, 2, 3);

Whereas in Perl's popular successors, Python and Ruby, you write:

    list = [1, 2, 3]

Saying the former lost out because the @ makes it unreadably terse is nonsense.

[jasode]

>Saying the former lost out because the @ makes it unreadably terse is nonsense.

Well, that's not what I claimed. I also wasn't really focused on "@%$" specifically but you had brought it up so went with it. (I get this weird feeling that I'm discussing with someone who's emotionally invested in Perl and he feels like I'm bashing Perl. Please let's us both stop this and make sure we're talking about Perl in a detached manner.)

Yes, strlen("my @list = (1, 2, 3)") is greater than strlen("list = [1, 2, 3]"). I wasn't talking about that. I was talking about things like strlen("@") < strlen("arraylist"). But... "C# doesn't compete with Perl!". Yes, that's true.

A realistic scenario where perceptions of "@" and "Arraylist" is compared would be a C# programmer working on an ASP.NET website or Javascript programmer working on Nodejs and then the company needs him to go fix an old website that was written in Perl ~15 years ago. The old Perl programmer left and C# programmer is stuck looking at Perl's "line noise". That irritated C# programmer then fills the Stackoverflow survey expressing his "dislike" of Perl. The C# and Javascript looked "readable" but Perl syntax such as "<>" looked like gibberish.

[kbp]

> I also wasn't really focused on "@%$" specifically but you had brought it up

My involvement in this conversation started with quoting you saying that one of the major reasons for Perl becoming disliked was "PERL's usage of sigils.[1] One the one hand, it makes code compact and terse". Perl's use of sigils has nothing to do with terseness, and since Perl lost its mindshare to Ruby and Python which to the tiny extent that sigils contribute to terseness/verbosity are more terse, I don't think that's a valid point about Perl's trajectory.

> I get this weird feeling that I'm discussing with someone who's emotionally invested in Perl and he feels like I'm bashing Perl.

I don't even know Perl, I'm just critiquing your logic.

> Perl syntax such as "<>"

'<' and '>' are not used as sigils in Perl.

[psergeant]

Why do you write it in all capitals?

[jasode]

No good reason. Purely muscle memory that I picked up decades ago. Maybe I saw someone else do it[1] and just picked up a bad habit. I'll stop the all caps and write Perl from now on.

[1] http://www.perlmonks.org/index.pl?node_id=511722

[Ultimatt]

Because they don't know much about contemporary Perl. It's actually a really good indicator of if someone actually knows anything about the language post the 90s. I used it as a soft hiring filter on CVs. You knew almost as matter of fact any dev putting that on their CV was self taught from monster nests of legacy.

[ionforce]

I thought I was the only person who asked this.