>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
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.
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.
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.
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.
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".
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!
>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.
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.
>Perl is not competing with C++; they're entirely different languages with entirely different usecases.
Yes, I understand that C++ does not compete with Perl. My point is the rejuvenation stories, not the runtime or use case differences.
I use a utility every day called ExifTool[1] that's 100% Perl source code or very close to it. However, ExifTool does not keep Perl at the top of mind the way Tensorflow brings Python relevancy to a new generation of programmers.
Yes, I understand that C++ does not compete with Perl. My point is the rejuvenation stories
Well, the way C++ had new versions released in 2017 and 2014, Perl 5 had new versions released in 2017 and 2016; what stagnation are you demonstrating? You said "updates to C++ via C++14 and C++17 were discussions that turned into reality"; and the same thing happened with updates to Perl 5 (which is the language "Perl" is usually shorthand for). Perl 6 is an entirely different language, it, along with languages like Ruby, compares to Perl 5 the same way C# and Rust compare to C++.
My point was that the fact that C++ (like Perl) has had multiple updates in the past few years, and that Nvidia chose C++ instead of Perl as the primary language for an API are not evidence of Perl's decline. Perl 5 receives more frequent updates than C++, and C++ is being used where it makes sense and where Perl wouldn't have been used even when it was the new hotness. How is that evidence that Perl has fallen off?
I'm not saying that Perl's popularity hasn't greatly declined, I'm just saying that the evidence you're offering for it isn't evidence.
But it's not just quantity of updates. It's perception of the updates and what new things they bring to the table. Surely you're aware that many Perl programmers abandoned the language in between Perl 5 and Perl 6 because they felt it was getting neglected. (There's also a long post from a ~20 year Perl veteran (forgot his name) of one of the famous libraries on HN explaining his reasons for leaving Perl before Perl 6 but I can't find it at the moment.) How do we reconcile why they thought Perl was stagnating even though it was getting frequent updates?
This was the opposite perception of C++11, C++14, C++17 where many programmers were complaining that it was getting too many features and getting too complicated.
>Perl wouldn't have been used even when it was the new hotness.[...], I'm just saying that the evidence you're offering for it isn't evidence.
Ok, I shouldn't have derailed the discussion by giving the impression that NVIDIA SDK could have been Perl. The main idea is that old languages other than Perl are getting in the news for new domains.
Let me be more generic: There is no new rejuvenation stories where <any_domain_where_Perl's_runtime_model_and_scripting_semantics_is_appropriate> was chosen by a new computing domain help keep it relevant and keep it from being "disliked" by programmers. Is that wording more acceptable and suitable evidence of Perl's decline?
I'd also still like to get your opinion of why Perl has declined in mindshare and is one of the most disliked languages in programmer's survey.
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.
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.
>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.
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.
>, I don't think that's a valid point about Perl's trajectory.
Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. I feel you have my comments mixed up with someone else.
>'<' and '>' are not used as sigils in Perl.
I agree and I didn't say they were.
That's 3 cases of nitpicking something I actually didn't claim. I can only assume this over-interpretation of things I didn't write is a result of some underlying irritation that I caused. Let's just stop. Peace.
Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine.
Well, if you just weren't considering Python and Ruby, then aren't they counter-examples to your point? They're terser than Perl in that regard; if that's a major reason people moved away from Perl, then why did so many of them move to those languages?
I agree and I didn't say they were.
Then why did you bring them up in a discussion about sigils?
Again, that wasn't the "regard" I was focused on. It wasn't strlen(Perl_syntax) to strlen(Python_syntax). It's not about counting characters. It was terseness of non-obvious meanings for symbols which reduced readability for many. Yes, "$foo=7" is literally 1 character longer than "foo=7" which seems to violate terseness. (This is the example you seem to always gravitate back to.) For the 2nd time, I'm stressing that I already agree with that definition. However, that wasn't what I was talking about. People unfamiliar with a language that happens to have "ArrayList" spelled out will see as not being as terse as "@". It's a different axis of terseness. This cognitive readability is orthogonal to whether people migrate to Python because it's 1 less character type in front of a variable name.
>Then why did you bring them up in a discussion about sigils?
I wasn't talking about sigils exclusively by that point.
I was talking about overall readability and "line noise" to fill out the C# story.
Yes, "$foo=7" is literally 1 character longer than "foo=7" which seems to violate terseness. (This is the example you seem to always gravitate back to.) For the 2nd time, I'm stressing that I already agree with that definition. However, that wasn't what I was talking about. People unfamiliar with a language that happens to have "ArrayList" spelled out is not as terse as "@".
I gravitate back to sigils because your point, that sigils' terseness contributed majorly to Perl's decline, was all I was objecting to. Python, Ruby, and Javascript don't spell out ArrayList either, yet those languages are now being used in most of the places where Perl used to be used. I ask again, if that was a major reason people left Perl, then why did the people who had that problem move to other languages that are even terser (ie, they don't spell out ArrayList and they don't even use sigils)?
>I gravitate back to sigils because your point, that sigils' terseness contributed majorly to Perl's decline,
I didn't tie sigils to the "decline" -- I tied it to the survey's "dislike". I also didn't claim Perl sigils is what drove Python/Ruby adoption. I never claimed a logical cause and effect between sigils and Perl's decline.
Indeed, the Rust language adds a whole new taxonomy of sigils[1] and it's on the upswing in popularity. (Of course, someone will probably come along and think I claimed that "adding sigils to Rust contributed to its growing popularity".)
The decline of Perl's mindshare for new domains was totally separate from "sigils". The usage decline was a 2nd observation of why Perl topped the charts of "most disliked" languages.
>then why did the people who had that problem move to other languages that are even terser
You're asking that question because you're still focused on only one string length definition of "terse".
Let me try another way:
strlen(Rust_code) > strlen(Python_code)
... and yet... Rust can still be perceived as more terse than Python. Why? Because special non-obvious symbols that "don't explain themselves" are perceived as terse. This leads to the paradox that adding to the text length makes it more terse. Lastly, not all opinions about Perl's reputation for terseness comes from Python/Ruby programmers.
The decline of Perl's mindshare for new domains was totally separate from "sigils".
When you quoted someone saying "how Perl managed to become quite so profoundly disliked" and said "the conspicuous reasons seem to be a combination of: 1) PERL's usage of sigils," I took that to mean you were saying that sigils were a major reason that Perl isn't well-liked by as many people anymore. I'm sorry if that was a misunderstanding.
Because special non-obvious symbols that "don't explain themselves" are perceived as terse.
The Merriam-Webster definition of 'terse' is 'using few words: devoid of superfluity.' It is not a synonym for noisy. 'my @list' is terser than 'List<T> list,' but both are wordier than better-liked-than-Perl languages like Python, Ruby, and Javascript, which is where Perl's mindshare went (I've been taking that last part as a given). I'm not claiming Perl isn't terse, I'm just saying that it was nonsensical to say that 'PERL's usage of sigils [...] makes code compact and terse.' Compared to C#, sure, but Perl was never competing with C#, and most of the mindshare it used to have didn't go to C#, so it's not really relevant. If the extra terseness (not noisiness) afforded by using sigils was a major reason for Perl's unpopularity, then Python, Ruby, and Javascript's popularity is very strange.
print while (<>);
Is definitely terser than
for line in fileinput.input():
print(line)
But you'll notice there aren't even any sigils in the Perl version.
Sigils being ugly and Perl being too terse might both be problems it has, but they're different issues.
You may have made a mistake linking to this page for Rust; as the URL says, it's a backup: the only ones that exist today are *, &, and ', and the former work the same way they do in other systems languages. (With the exception that & is borrow checked but like, it's a pointer inside, same exact deal.)
We in fact removed these sigils from Rust because user feedback was extremely negative about them, and ' still gets a lot of complaints. Nobody has come up with something better though.
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.
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.
Comments
>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)
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.
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.
Citation needed.
Read the rest of my post. If you don't agree, that's fine.
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.
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.
>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".
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!
>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.
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.
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.
>Perl is not competing with C++; they're entirely different languages with entirely different usecases.
Yes, I understand that C++ does not compete with Perl. My point is the rejuvenation stories, not the runtime or use case differences.
I use a utility every day called ExifTool[1] that's 100% Perl source code or very close to it. However, ExifTool does not keep Perl at the top of mind the way Tensorflow brings Python relevancy to a new generation of programmers.
[1] https://www.sno.phy.queensu.ca/~phil/exiftool/
Well, the way C++ had new versions released in 2017 and 2014, Perl 5 had new versions released in 2017 and 2016; what stagnation are you demonstrating? You said "updates to C++ via C++14 and C++17 were discussions that turned into reality"; and the same thing happened with updates to Perl 5 (which is the language "Perl" is usually shorthand for). Perl 6 is an entirely different language, it, along with languages like Ruby, compares to Perl 5 the same way C# and Rust compare to C++.
>what stagnation are you demonstrating?
Mindshare.
I thought it was clear that my rejuvenation examples were not about point releases or size of cpan but rejuvenating the mindshare of programmers.
Instead of my words getting misinterpreted and we keep going around in circles, let's try to bypass that and turn the question around:
What is your explanation of why Perl has declined in mindshare and is one of the most disliked languages in programmer's survey?
My point was that the fact that C++ (like Perl) has had multiple updates in the past few years, and that Nvidia chose C++ instead of Perl as the primary language for an API are not evidence of Perl's decline. Perl 5 receives more frequent updates than C++, and C++ is being used where it makes sense and where Perl wouldn't have been used even when it was the new hotness. How is that evidence that Perl has fallen off?
I'm not saying that Perl's popularity hasn't greatly declined, I'm just saying that the evidence you're offering for it isn't evidence.
>Perl 5 receives more frequent updates than C++,
But it's not just quantity of updates. It's perception of the updates and what new things they bring to the table. Surely you're aware that many Perl programmers abandoned the language in between Perl 5 and Perl 6 because they felt it was getting neglected. (There's also a long post from a ~20 year Perl veteran (forgot his name) of one of the famous libraries on HN explaining his reasons for leaving Perl before Perl 6 but I can't find it at the moment.) How do we reconcile why they thought Perl was stagnating even though it was getting frequent updates?
This was the opposite perception of C++11, C++14, C++17 where many programmers were complaining that it was getting too many features and getting too complicated.
>Perl wouldn't have been used even when it was the new hotness.[...], I'm just saying that the evidence you're offering for it isn't evidence.
Ok, I shouldn't have derailed the discussion by giving the impression that NVIDIA SDK could have been Perl. The main idea is that old languages other than Perl are getting in the news for new domains.
Let me be more generic: There is no new rejuvenation stories where <any_domain_where_Perl's_runtime_model_and_scripting_semantics_is_appropriate> was chosen by a new computing domain help keep it relevant and keep it from being "disliked" by programmers. Is that wording more acceptable and suitable evidence of Perl's decline?
I'd also still like to get your opinion of why Perl has declined in mindshare and is one of the most disliked languages in programmer's survey.
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.
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
The terseness isn't the variable name, it's the notation of the type:
... is more compact than C#... And Perl ... is more compact than C++: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:
Whereas in Perl's popular successors, Python and Ruby, you write: Saying the former lost out because the @ makes it unreadably terse is nonsense.>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.
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 don't even know Perl, I'm just critiquing your logic.
'<' and '>' are not used as sigils in Perl.
>, I don't think that's a valid point about Perl's trajectory.
Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. I feel you have my comments mixed up with someone else.
>'<' and '>' are not used as sigils in Perl.
I agree and I didn't say they were.
That's 3 cases of nitpicking something I actually didn't claim. I can only assume this over-interpretation of things I didn't write is a result of some underlying irritation that I caused. Let's just stop. Peace.
Well, if you just weren't considering Python and Ruby, then aren't they counter-examples to your point? They're terser than Perl in that regard; if that's a major reason people moved away from Perl, then why did so many of them move to those languages?
Then why did you bring them up in a discussion about sigils?
>They're terser than Perl in that regard;
Again, that wasn't the "regard" I was focused on. It wasn't strlen(Perl_syntax) to strlen(Python_syntax). It's not about counting characters. It was terseness of non-obvious meanings for symbols which reduced readability for many. Yes, "$foo=7" is literally 1 character longer than "foo=7" which seems to violate terseness. (This is the example you seem to always gravitate back to.) For the 2nd time, I'm stressing that I already agree with that definition. However, that wasn't what I was talking about. People unfamiliar with a language that happens to have "ArrayList" spelled out will see as not being as terse as "@". It's a different axis of terseness. This cognitive readability is orthogonal to whether people migrate to Python because it's 1 less character type in front of a variable name.
>Then why did you bring them up in a discussion about sigils?
I wasn't talking about sigils exclusively by that point. I was talking about overall readability and "line noise" to fill out the C# story.
I gravitate back to sigils because your point, that sigils' terseness contributed majorly to Perl's decline, was all I was objecting to. Python, Ruby, and Javascript don't spell out ArrayList either, yet those languages are now being used in most of the places where Perl used to be used. I ask again, if that was a major reason people left Perl, then why did the people who had that problem move to other languages that are even terser (ie, they don't spell out ArrayList and they don't even use sigils)?
>I gravitate back to sigils because your point, that sigils' terseness contributed majorly to Perl's decline,
I didn't tie sigils to the "decline" -- I tied it to the survey's "dislike". I also didn't claim Perl sigils is what drove Python/Ruby adoption. I never claimed a logical cause and effect between sigils and Perl's decline.
Indeed, the Rust language adds a whole new taxonomy of sigils[1] and it's on the upswing in popularity. (Of course, someone will probably come along and think I claimed that "adding sigils to Rust contributed to its growing popularity".)
The decline of Perl's mindshare for new domains was totally separate from "sigils". The usage decline was a 2nd observation of why Perl topped the charts of "most disliked" languages.
>then why did the people who had that problem move to other languages that are even terser
You're asking that question because you're still focused on only one string length definition of "terse".
Let me try another way:
... and yet... Rust can still be perceived as more terse than Python. Why? Because special non-obvious symbols that "don't explain themselves" are perceived as terse. This leads to the paradox that adding to the text length makes it more terse. Lastly, not all opinions about Perl's reputation for terseness comes from Python/Ruby programmers.[1] https://github.com/rust-lang/rust-wiki-backup/blob/master/Si...
When you quoted someone saying "how Perl managed to become quite so profoundly disliked" and said "the conspicuous reasons seem to be a combination of: 1) PERL's usage of sigils," I took that to mean you were saying that sigils were a major reason that Perl isn't well-liked by as many people anymore. I'm sorry if that was a misunderstanding.
The Merriam-Webster definition of 'terse' is 'using few words: devoid of superfluity.' It is not a synonym for noisy. 'my @list' is terser than 'List<T> list,' but both are wordier than better-liked-than-Perl languages like Python, Ruby, and Javascript, which is where Perl's mindshare went (I've been taking that last part as a given). I'm not claiming Perl isn't terse, I'm just saying that it was nonsensical to say that 'PERL's usage of sigils [...] makes code compact and terse.' Compared to C#, sure, but Perl was never competing with C#, and most of the mindshare it used to have didn't go to C#, so it's not really relevant. If the extra terseness (not noisiness) afforded by using sigils was a major reason for Perl's unpopularity, then Python, Ruby, and Javascript's popularity is very strange.
Is definitely terser than But you'll notice there aren't even any sigils in the Perl version.Sigils being ugly and Perl being too terse might both be problems it has, but they're different issues.
You may have made a mistake linking to this page for Rust; as the URL says, it's a backup: the only ones that exist today are *, &, and ', and the former work the same way they do in other systems languages. (With the exception that & is borrow checked but like, it's a pointer inside, same exact deal.)
We in fact removed these sigils from Rust because user feedback was extremely negative about them, and ' still gets a lot of complaints. Nobody has come up with something better though.
Why do you write it in all capitals?
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
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.
I thought I was the only person who asked this.