Is the pro/con "Modern Perl" divide a symptom of Steve Yegge's "software political axis"?
I haven't followed all of it, but the discussions about whether or not the "Modern Perl" tools like Moose are a good thing reminds me of Steve Yegge's essay about the "software political axis." If you haven't read it, I'll give you the super short summary: he says that a major source of tension between developers is their differences in risk tolerance, as seen in attitudes toward such things as type checking, adding new syntax to a language on the fly, well-defined schemas vs NoSQL, QA cycles before code rollout, etc.
With this framing, embracing Modern Perl is indicative of a lower risk-tolerance and a desire for more safety in software development, while objecting to it shows a willingness to accept more risk in exchange for lower overhead.
What do you think? Do you agree with this analysis? Have you seen any other interesting writing on this subject beyond Yegge's essay?
I blog about Perl.
That is a great article, in my case I would say it doesn't strictly apply. Namely while I prefer an alternative to Moo(se) for object management I have been using everything "use Modern::Perl" provides for far longer then said module or the popularity of the phrase has existed.
I believe the divide was mislabeled (by myself among others) as "Modern Perl" vs non "Modern Perl", when it is much more closely a divide about using Moo(se) vs. using alternatives for object management and code re-use methodologies.
As another data point. I personally do not use Moose or other accessor generators or fields pragma or pseudo hashes. I personally do not use ORMs but I believe very much in a rigorous relational schema definition and love DBI and do have some SQL::Abstract style query generators. However, I do use strict, and warnings, and unicode, and objects, and roles, and perl daemons, and unit tests, and higher order functions, and event loops, and pod, and type checkers (when it makes sense), and exceptions as objects. And I've been using them all since pre-modern-perl times. And I love new perl code features and I think cpanm and perlbrew are awesome.
While the pre/post debate may very well center around risk avoidance for many, for me personally it is not.
Thanks for your comment, Paul. FYI, for anyone reading this, pseudo hashes have been removed from Perl starting with 5.10, but the fields pragma does still exist with a different implementation.
I disagree about Mo* is lower risk. With given long dependency tail of Mo* and number of opened bugs, it's practical impossible to be sure
that the code will be deployed to any machine and will work without bugs with all versions of dependencies (including future).
Also it's pretty risky to code without knowing what's exactly happening one level below your code (unless this level is pretty good tested and documented).
This is only about Mo* - i.e. frameworks. Not related to use strict, unit tests, etc.
For me, modern Perl starts with the question of "What should a novice know about programming Perl well in 2013?" For example, maybe Moose makes sense in that novice's environment and maybe it doesn't, but at least he or she knows that it exists and is an option.
And good riddance, those things were ugly!
Here here, they should know about Moo(se), and they should also know about other options. I think part of the issue here is that when myself and others stated they didn't like Moo(se) we were told that either we were mistaken and should look again, or to please be quiet about it so as not to send newbies in the wrong direction. There is no wrong way to do something, that is a long standing very public opinion about Perl.
Interesting point. I'm not really in agreement about the dependencies being such a problem, but I see how trusting other people's code (in the form of frameworks) could be seen as accepting more risk. The difference between trusting widely used frameworks and trusting the CORE modules seems a little arbitrary to me though.
Yes, Modern Perl is a poor description of what the argument has been about. Most of the stuff in your Modern Perl book is totally uncontroversial at this point.
"With this framing, embracing Modern Perl is indicative of a lower risk-tolerance and a desire for more safety in software development, while objecting to it shows a willingness to accept more risk in exchange for lower overhead."
Do you have that backwards? Objectors to Modern Perl want the Devil They Know, while embracers prefer to try something else. More like conservatives vs. liberals. Both may think they are going down the low risk path, but have different risk profiles. A safe approach for one is not a safe approach for the other.
True, you could read it that way. Avoiding change is a way of avoiding risk. However, the change in this case is all about increasing safety in software terms. Some people would view it as giving up some liberty in exchange for more safety, and how you feel about that depends on how unsafe things look to you without it.
This may just mean that the analogy doesn't fit the situation though.