While this does take a stab at refuting some criticisms of Perl I don’t think it achieves its goals.
One of the core issues with Perl is that it’s such a flexible language. This is what its adherents (myself included!) love. But it’s also a net negative when trying to use Perl for large projects where interpersonal communication with regards to coding standards and what’s “idiomatic” is important. What if your resident rock star just can’t stand Moose, and insists you use their own home-grown object system? With Perl, it’s entirely plausible whatever they’ve cooked up will in fact do the job - at least for this project.
I return to my oft-repeated observation: Perl hackers revel in TMTOWTDI, Python hackers fret over what’s idiomatic. It’s a culture thing, there’s nothing wrong with it, but time has shown that bondage and discipline languages have an edge for large projects, and maybe for knowledge diffusion in general.
Yep, I agree. I guess I’d like perl criticism to be channelled into “the language is too big / too man ways to do things” (a la C++) and “the language is too flexible/powerful” (a la lisp/scheme). Rather than “line noise, write only, yadda yadda”.
A corollary of that, is that places which manage to make good on C++ or lisps could also make good on perl with similar external disciplines (style guides etc).
I agree the trend is more towards “simple” + “one way to do it” (I like golang very much).
It’s hard to get anyone new into Perl because it’s kind of a living fossil. Perl considers the callstack and function parameters to be interesting new features which you may want to opt into or not. I mean, that’s cool, but uh, I don’t miss subroutines in the languages I do use day to day. Similarly, it added native support for hashes, which is a big step up from C, but it’s still pretty funky about it, instead of it just being a normal thing, like in Python and JS. And then there are all the weird $whatever magic-fake-globals. If you memorized them, good for you, but I’m just going to use a language where I don’t need them.
The good new is Perl inspired Ruby, and Ruby’s pretty cool.
There’s the fact that it’s a living fossil and there’s the fact that it was carefully designed for maximum flexibility in every situation in every possible way - TMOWTDI rules supreme. I claim this is a thunderously bad idea.
I’m sure someone, somewhere had a situation in which called subroutines really benefited from popping their own arguments off the stack and un-peeling them,, so, great, I’m glad Perl exists for that one person, that one time, but I was a card carrying Perl Monger for YEARS and I never once encountered such a situation.
Optimizing for the 99% case is a good idea. It’s what Python does, and it’s why I consider myself a Pythonista first and foremost these days.
Fun to compare this to What’s bad about Julia?, another post where an expert talks about criticisms to their favorite language. Except in the Julia post, the vibe is less “expert dismissing any criticism about $lang as bonkers” and more “expert openly talking about the pros and cons of $lang.” I know which kind of post I prefer.
It’s not about “are function arguments available (from the package manager)” or “is an object oriented programming model available (from the package manager)”, or even “can shelling out to grep be prevented”. It’s because without a single way for these core systems to work, every way for these things to work ends up used in one module or another. The Perl code I maintained used 2 different ORMs, 3 different class/OO systems, and 5 (five) ways to abort with error/check for error. (one throw-like function was called carp). Half of those below the water line in CPAN modules we needed to use.
Yes, this was long lived codebase with a lot of barnacles. But it would have been a lot easier to understand if there was a single implementation for each or those systems.
I’m with @gerikson - the point the author makes about Perl criticism being a funhouse mirror does have some validity, but then when you get into the meat of the article the ACTUAL argument is “But wait.. We’ve FINALLY embraced code quality tools!!!”
Well done folks, only took you 30 years to come around to the idea :)
More seriously though, I recognize that Perl has an important place in the computing landscape. Much more so than many younger folks give it credit for, but it has not been my tool of first choice for decades, and I do not see that changing anytime soon.
While this does take a stab at refuting some criticisms of Perl I don’t think it achieves its goals.
One of the core issues with Perl is that it’s such a flexible language. This is what its adherents (myself included!) love. But it’s also a net negative when trying to use Perl for large projects where interpersonal communication with regards to coding standards and what’s “idiomatic” is important. What if your resident rock star just can’t stand Moose, and insists you use their own home-grown object system? With Perl, it’s entirely plausible whatever they’ve cooked up will in fact do the job - at least for this project.
I return to my oft-repeated observation: Perl hackers revel in TMTOWTDI, Python hackers fret over what’s idiomatic. It’s a culture thing, there’s nothing wrong with it, but time has shown that bondage and discipline languages have an edge for large projects, and maybe for knowledge diffusion in general.
Similar arguments have been made about why Lisps never became as widespread as many people feel they should be.
Edit: typo
Yep, I agree. I guess I’d like perl criticism to be channelled into “the language is too big / too man ways to do things” (a la C++) and “the language is too flexible/powerful” (a la lisp/scheme). Rather than “line noise, write only, yadda yadda”.
A corollary of that, is that places which manage to make good on C++ or lisps could also make good on perl with similar external disciplines (style guides etc).
I agree the trend is more towards “simple” + “one way to do it” (I like golang very much).
It’s hard to get anyone new into Perl because it’s kind of a living fossil. Perl considers the callstack and function parameters to be interesting new features which you may want to opt into or not. I mean, that’s cool, but uh, I don’t miss subroutines in the languages I do use day to day. Similarly, it added native support for hashes, which is a big step up from C, but it’s still pretty funky about it, instead of it just being a normal thing, like in Python and JS. And then there are all the weird $whatever magic-fake-globals. If you memorized them, good for you, but I’m just going to use a language where I don’t need them.
The good new is Perl inspired Ruby, and Ruby’s pretty cool.
There’s the fact that it’s a living fossil and there’s the fact that it was carefully designed for maximum flexibility in every situation in every possible way - TMOWTDI rules supreme. I claim this is a thunderously bad idea.
I’m sure someone, somewhere had a situation in which called subroutines really benefited from popping their own arguments off the stack and un-peeling them,, so, great, I’m glad Perl exists for that one person, that one time, but I was a card carrying Perl Monger for YEARS and I never once encountered such a situation.
Optimizing for the 99% case is a good idea. It’s what Python does, and it’s why I consider myself a Pythonista first and foremost these days.
Fun to compare this to What’s bad about Julia?, another post where an expert talks about criticisms to their favorite language. Except in the Julia post, the vibe is less “expert dismissing any criticism about $lang as bonkers” and more “expert openly talking about the pros and cons of $lang.” I know which kind of post I prefer.
A response to this post, which got some comments here.
It’s not about “are function arguments available (from the package manager)” or “is an object oriented programming model available (from the package manager)”, or even “can shelling out to grep be prevented”. It’s because without a single way for these core systems to work, every way for these things to work ends up used in one module or another. The Perl code I maintained used 2 different ORMs, 3 different class/OO systems, and 5 (five) ways to abort with error/check for error. (one throw-like function was called
carp). Half of those below the water line in CPAN modules we needed to use.Yes, this was long lived codebase with a lot of barnacles. But it would have been a lot easier to understand if there was a single implementation for each or those systems.
This post feels like it’s from 2003. If Perl works for you, great! But it’s hard to imagine it will ever recapture anything like its former glory.
I’m with @gerikson - the point the author makes about Perl criticism being a funhouse mirror does have some validity, but then when you get into the meat of the article the ACTUAL argument is “But wait.. We’ve FINALLY embraced code quality tools!!!”
Well done folks, only took you 30 years to come around to the idea :)
More seriously though, I recognize that Perl has an important place in the computing landscape. Much more so than many younger folks give it credit for, but it has not been my tool of first choice for decades, and I do not see that changing anytime soon.