It’s been a fine effort, not only on the part of the maintainers, but also on the part of the people who did the political wrangling to give it a consistent release cycle, give it a coherent maintenance policy, and make the job of the maintainer one that people were actually willing to do.
There was a time between about 2006 and 2010 when Perl really was in danger of being as dead as it’s often rumored to be, but instead we got a language that, while very conservative in terms of backward-compatibility guarantees, does make steady improvements.
I think the problem is Perl is fine when you’re cautious, but if you’re not, it can rapidly turn into spaghetti. Most Perl code in its peak was written by i.e. sysadmins under duress, so it didn’t look good for Perl. I have written thoughtful OO Perl, and it was a surprisingly OK experience.
I still remember blessing variables into objects and thinking it strange. When I learned more about the implementation of OO languages, I realized that this “blessing” I had to do manually in Perl was what happened behind the scenes in other languages.
It’s interesting what we think a normal programming language should do and look like.
The Perl way is more powerful because it takes something that most other languages hide away (an object springs into existence, is tagged as being an instance of your class, and then you get to do constructor-y things to it) and makes it explicit and available to the programmer. It enables some genuinely useful stuff. Something similar (albeit with a type-y twist) is suggested as an answer to this recent PLD.SE question.
But it also empowers you to screw up in stupid ways, i.e. a common beginner mistake used to be to write a constructor that blessed into __PACKAGE__ instead of $class, which would sabotage anyone trying to subclass you in the usual way. Luckily there have been options out there for the past 20 or so years that are easier to learn and to teach.
(Another) good release. Slow and steady; not sure if there’s a race to win here, but I keep being positively surprised about every new coming release.
I have plenty of paid Perl work recently (the demand is small, but still there – the supply is nearly nonexistent), and in my experience the market has finally shifted away from the “We’re targetting Perl 5.8 from 1020 years ago” nonsense. I’m yet to use the new classes in production (they could really use a MooseX::NonMoose equivalent, being able to derive from old-style classes), but it’s pleasant to see how much more sensible and ergonomic the language has gotten.
I used the new class stuff (from 5.38) in a data importer project, that was fun. But I guess it will take some (a lot of) time for big projects like Koha to switch. Esp for widely deployed apps (not running in a container on your own server) we’ll probably first have to wait for Linux distributions to upgrade their Perls…
i really like that. multiple times i had to simulate this with bool(x) != bool(y) in python. stuff like this is why i’m still fond of perl, even though i hardly use it for new projects any more.
note that (afaict) this is just new syntax, not a new feature: xor already existed for essentially forever (with different precedence rules).
My most controversial programming opinion is “Perl is fine, actually”, and the core team is diligently making it more fine.
It’s been a fine effort, not only on the part of the maintainers, but also on the part of the people who did the political wrangling to give it a consistent release cycle, give it a coherent maintenance policy, and make the job of the maintainer one that people were actually willing to do.
There was a time between about 2006 and 2010 when Perl really was in danger of being as dead as it’s often rumored to be, but instead we got a language that, while very conservative in terms of backward-compatibility guarantees, does make steady improvements.
I think the problem is Perl is fine when you’re cautious, but if you’re not, it can rapidly turn into spaghetti. Most Perl code in its peak was written by i.e. sysadmins under duress, so it didn’t look good for Perl. I have written thoughtful OO Perl, and it was a surprisingly OK experience.
I still remember
blessing variables into objects and thinking it strange. When I learned more about the implementation of OO languages, I realized that this “blessing” I had to do manually in Perl was what happened behind the scenes in other languages. It’s interesting what we think a normal programming language should do and look like.The Perl way is more powerful because it takes something that most other languages hide away (an object springs into existence, is tagged as being an instance of your class, and then you get to do constructor-y things to it) and makes it explicit and available to the programmer. It enables some genuinely useful stuff. Something similar (albeit with a type-y twist) is suggested as an answer to this recent PLD.SE question.
But it also empowers you to screw up in stupid ways, i.e. a common beginner mistake used to be to write a constructor that blessed into
__PACKAGE__instead of$class, which would sabotage anyone trying to subclass you in the usual way. Luckily there have been options out there for the past 20 or so years that are easier to learn and to teach.(Another) good release. Slow and steady; not sure if there’s a race to win here, but I keep being positively surprised about every new coming release.
I have plenty of paid Perl work recently (the demand is small, but still there – the supply is nearly nonexistent), and in my experience the market has finally shifted away from the “We’re targetting Perl 5.8 from
1020 years ago” nonsense. I’m yet to use the new classes in production (they could really use a MooseX::NonMoose equivalent, being able to derive from old-style classes), but it’s pleasant to see how much more sensible and ergonomic the language has gotten.I’m a full time Perl dev and we are quite busy too.
Not only I use it daily, but we are even starting new projects in Perl.
I used the new class stuff (from 5.38) in a data importer project, that was fun. But I guess it will take some (a lot of) time for big projects like Koha to switch. Esp for widely deployed apps (not running in a container on your own server) we’ll probably first have to wait for Linux distributions to upgrade their Perls…
i really like that. multiple times i had to simulate this with
bool(x) != bool(y)in python. stuff like this is why i’m still fond of perl, even though i hardly use it for new projects any more.note that (afaict) this is just new syntax, not a new feature:
xoralready existed for essentially forever (with different precedence rules).[Comment removed by author]