Pre-Modern Perl VS Post-Modern Perl: FIGHT!
Lately we’ve seen a couple of blog posts about “pre-modern Perl.” The core idea seems to be that older Perls (say, 5.6, or perhaps even 5.005) are perfectly good for many jobs. Which, of course, they are. I’m not sure anyone ever said they weren’t.
Although the authors tend to downplay it in the comments, the articles are also leavened with a bit of ... shall we say, dislike? ... of modern Perl (or post-modern Perl, or however you want to style it). Sure, they also contain a fair amount of “hey, if that’s your thing, that’s fine for you—just leave me out of it.” But it’s hard to gloss over statements such as:
You see I don’t love “modern Perl”, in fact I kind of hate it.
On the one hand, the posts really do want to say “this is just my opinion and it’s fine for you to have a different one.” But, on the other, one can’t help but feel a little bit of resentment, just a touch of “stop messing around with my perfectly good language and trying to dress it up with your fancy OO crap.” And that’s absolutely a fair sentiment. Oh, sure, it’s all very fine for us on the other side to say “well, just don’t use those features if you don’t want to.” But that’s a naive position. As newer versions of Perl come out, we will see bug fixes, speed improvements, and new features. And it’s not like you can get the first two without the last one. And when these fellows say that, yes, they won’t use such features because they don’t care for them, but it’s very difficult to make sure the other people on their teams don’t use them—or misuse them—and then they’re stuck with maintaining them ... well, honestly, they have a point.
But that doesn’t mean I agree with these folks. Although I grant all the above points as perfectly valid, there are a couple of other points I have a problem with.
Both posts go on to talk about how there are many shops that are still using these older versions of Perl, and will be doing so for many years, and have strong, solidly built software. Again, I grant that. When I was “growing up” (as a programmer), I heard these exact same arguments ... only at that time, it was COBOL they were talking about.
When I was neophyte programmer, we all knew COBOL was a dying language. Well, all except the people actually writing COBOL. They were well-paid, well-treated, and in demand. They pointed out that you could pick up any newspaper classified section (yes, I can remember a time when looking for a job actually involved paper) and the quantity of ads for COBOL programmers outnumbered those of any other language. They pointed at all the huge firms, many of them Fortune 500 companies, who were using COBOL and had no plans to switch any time soon. They were right about all that stuff. They just forgot (or more likely just conveniently overlooked) one important fact:
No one was writing anything new in COBOL.
These guys were well-paid and well-treated because their numbers were dwindling and they were getting harder and harder to find. The job postings were increasing because people were abandoning COBOL for other languages, and also because a COBOL vacancy was such a big deal that it ended up generating 6 or 7 want ads: one for the company itself, and the rest for all the recruiters hired to try to find a competent COBOL programmer. This was 20-odd years ago, but there are still COBOL jobs out there: a quick check of the Internet (yay for no more paper!) tells me Monster has 47 and Dice has 140. And that wasn’t even trying very hard. Hell, I bet that whatever COBOL programmers there are out there are probably better paid and possibly even better treated than I am. I bet that, if you are a professional COBOL programmer at this point in history, you will have a guaranteed job for the remainder of your life, or as long as you want one, anyway.
There’s a lot to be said for that.
But I don’t really want to program in COBOL. And I don’t want to be programming in today’s equivalent of COBOL, either.
Well, that’s okay, these articles point out. They have a solution for that too:
My first car was a 1969 Red VW Beetle. The heater was busted and perpetually on. The heat came out of a vent in the floor and burned my feet. I had to stuff a big tube sock in the vent. I put in a quart of oil at every fill up too. One day I saw a VW on the road and saw that someone had smacked a Rolls Royce grill on the front. Wow! Cool! Then it hit me. Why not just buy a Rolls Royce?
Well, it’s a fun analogy, but the reason it doesn’t do anything for me is this: I think most rational people will agree that a Rolls Royce is better than a VW Beetle. Oh, sure, there are going to be those diehard Beetle fans out there that will swear they’d rather have their finicky but adorable car over the “too slick” Rolls any day, but I think most people can agree that there are very few real-world situations where the VW is going to be a better choice.
But, when it comes to programming, the reason I don’t switch from Perl to a better language is that I haven’t found one yet.
Oh, sure, other languages have strong points, and they have things that Perl doesn’t, and certain ones even beat out Perl in certain very limited circumstances, but there isn’t a single other language that I have yet discovered that is clearly better, overall, in general-pupose problem-solving—in manipulexity and whipuptitude, to steal a phrase—than Perl. If Ruby has some feature that’s better than Perl, I don’t want to go program in Ruby ... I want the pioneers of Perl—the Larry Walls and the Stevan Littles and the Matt Trouts and the Ricardo Signeses, the Damians and the Miyagawas—to go steal it for me. So I can keep programming in Perl. Because programming Perl is fun. Sure, it’s my job and it’s how I make a living and it’s work, but that doesn’t preclude it being fun. I program in SQL because it’s the best data manipulation language I typically have access to, and I program in Javascript in those situations when there is literally no other choice, but neither of those is really fun. If someone would write a browser that would parse Perl on the client side, or write an extension to Perl that would make SQL expressions work as native code (man, what I wouldn’t give to be able to write insert into companies %company or maybe @ids = select id from departments where name in @dept_list), I would jump on those in a heartbeat. I don’t hate other languages. I just love Perl.
So my Perl has to keep on growing, keep on evolving. As with so many things in life, it’s evolve or die, and I’d prefer it not die. As a programmer (indeed, as a human being), I am constantly evolving, constantly learning, constantly trying new things, constantly looking back on what I did last year and last decade with chagrin, proud that I now know better, happy to be using new techniques, knowing that there are still new things out there that I don’t understand yet—aspect-oriented programming, or inversion of control, or behaviour-driven development—and that maybe those things are passing fads or maybe I’ll suddenly have a light-bulb pop on over my head when I reread them for the thirteenth time and I’ll add them to my toolbox and my software will be that much more elegant, that much more uncluttered, ever so slightly easier to comprehend and maintain. So Perl better keep up, or I’m going to outgrow it. And I don’t want to outgrow it. It’s the best companion I’ve found so far.
Maybe this can help some of you “pre-modern Perl” fans out there see why some of us “post-modern Perl” fans want to see even more “crazy” shit glommed onto our favorite kitchen sink language. Because, in the end, it isn’t that crazy. In some cases we just need to Perl to keep up with us. And, if that means that in other cases it’s going to drag us along for the ride, I’m okay with that.
14 years in California, 25 years in Perl, 34 years in computers, 55 years in bare feet.
Great post as usual Buddy! I want to toss in one more comment, this one about the "militant Modern-Perlers".
I will cop to being one. There I said it. However my militancy doesn't really aim itself at anyone capable of making such an argument. Much as with `use strict` there will probably always be those who prefer not to. I personally wouldn't choose that road, but to each his own ... with one caveat: teach the newcomers the new way. Why? Because it helps them.
Modern Perl, (strict, moo(se)?, etc) helps to prevent common problems, solve repetitive ones, and help write more self-documenting and understandable code. Anyone who has spent enough time on StackOverflow as I have (both as a newbie and an answerer now) will know that there are an endless stream of new perlers who trip over things that strict would have prevented or that moose would have clarified. To THESE people I demand that they use the new tools, both for their sake and mine.
Just go and answer a dozen questions about parsing HTML with regexes (without strict) and see how long you can make it without throwing up your hands and start suggesting the DOM parser you prefer (plug: Mojo::DOM). Perl needs to evolve, not to make your life harder, not to make you learn new things, but to keep up with what will help new programmers.
Many of our favorite Perls like to say "to promote Perl, make cool things". Many of you know that I believe that that isn't sufficient, but if it is, better tools will help you achieve that. And once you do, it will help future contributors be able to jump in and help.
If you don't want modern Perl, then fine. But please stop discouraging its use among those who are one more Perlism question away from jumping to the next language they find easier.
I don't see evidances that "pre-modern" perl, that we talk about, is 5.6/5.005 without use "strict".
I think that people were actually talking about "Core" perl, or Perl without Moose.
And "strict" is core module.
Thanks Buddy! Reading the first few sentences of your post made me think "Ah, someone wrote the post I wanted to write". But it's not quite hitting the bull's eye. At least not the bull's eye I had in mind.
Anyway, I'm glad I'm not the only one irked by those two anti-modern posts and some of the comments they received.
Thanks Buddy, very nice post and i am especially glad that someone was able to articulate why continuously learning is imperative. :)
Every single proponent of high-fructose-perl seems to be united under the banner "Perl Must EVOLVE!".
I just want to remind folks that evolution is not always a good thing - care must be exercised *what* one is evolving into. Platypus-perl anyone?
Whilst I agree with the thrust of the argument, is has been undermined by some of the changes in 5.18, specifically given/when and smart-match. I always considered those to be Modern Perl. OK, they had their issues, but I was confident that would be fixed. Now it looks like they are deprecated, they give warnings, and are rumoured to go in a future release. That does not encourage anyone to pickup and use the new features.
Great Post... totally agree... I want Perl to be my swiss army knife with ALL the options, including the new funny blade with the hooky bit at the end.
I'm already feeling like one of those people with a legacy language when I look around to hire new people.
It's not there yet, but I can see a time when it's better to switch languages than battle with recruitment - case in point, someone I really wanted to hire decided he wanted Python and Scala on his CV so took a job with a company migrating over to those from Perl.
What could anyone possibly have against platypuses?! Platypuses are awesome.
Excellent post, Buddy!
I just want to note that evolution is basically adaptation for survival's sake. If we're talking about surviving the future, Perl (as with any animal) must adapt (or "evolve") to fit the environment.
To write *new* things in Perl, we need to continue making Perl smarter, faster and more capable. There are too many areas where "lagging behind" would be graceful phrasing. :)
Also, two points to Toby for his comment!
Ok, so what truly constitutes Modern Perl?
I'm certainly not stuck in Perl 5.6 land or worse, Perl 5.005. I like the package of improvements I get when I say "use Modern::Perl" at the top of my scripts. "say" was long overdo, as was 'each', 'keys' and 'values' on arrays, for example. I like all the core improvements to Perl so far. (Ok, the given/when kerfluffle is a bit silly...)
But then there's Moose. I spent a good couple years with Moose. By the end, I felt I had a pretty good handle on using it, but looking back I think it was a combination of reflexively avoiding sharp edges (what's broken with fat comma this week; now curly braces need to be on the same line as the method keyword; etc.) and Stockholm syndrome.
There was the awful runtime cost and even worse error messages. But I don't think either of those compare to the real cost. I had gotten over those and was writing actually rather beautiful code in Moose. But...
In the hands of the inept, Moose allows the unskilled to inflict far more damage than plain old perl. And that alone is reason enough to avoid it. No matter how good *I* might have gotten at using Moose effectively, only one other team member even tried to really grok Moose. And lets just say that "maintainable" isn't an appropriate adjective for what resulted.
Don't get me wrong: You can write some seriously unmaintainable Plain Old Perl quite easily. It just seemed like Moose invited certain bad habits and design, and charged you for them with slow run time and inscrutable error messages. Misplace a comma and get rewarded with the War and Peace of error messages. Because the compile-edit-debug cycle gets so painful, you end up "tweaking until it works" rather than doing more fearless refactoring.
Now, if Moose were native with clear error messages, and it didn't give a multi-second startup penalty, I'd consider giving it a spin again. Until then, I'll have to stick to core Perl with strictures and maybe a dash of Critic.
> (what's broken with fat comma this week; now curly braces need to be on the same line as the method keyword; etc.)
You sound like you're confusing source filters with Moose itself.
> Now, if Moose were native with clear error messages, and it didn't give a multi-second startup penalty
Give Moo a try today. When people say Moose, they refer to the style of sugar, not the specific implementation. (And if Moo gives you weird errors, complain in rt or #web-simple on irc.perl.org and we will try our best to make them easy to understand.)
I'm guessing that MrZ had problems with functions as types (MyClass vs 'MyClass') from things like MooseX::Types, in which case yes, it can be hard to keep track of where a fat comma is allowed.
To comment on whether 'use strict' is Modern Perl, I included it because there is still a subset of Perlers who complain that we say "always use strict". I think of strict as earlier than "Modern Perl" myself, but I include it for completeness.
Well, it's always a positive thing when you can get the community talking about something - as long as it all stays positive.
Having said that, I was more than a little disappointed to see Gabor's characterization of the discussion.
> Last week, we saw two people complaining in blog posts about the 'modern Perl' movement. This time you can see how Buddy Burden takes on the nay-sayers barefoot! Is this a real fight? I don't think so. It is 'just' the simple tension between people who accept, and people who dislike changes.
There's a pretty important misunderstanding here and it has to do with the "people who dislike changes" argument.
As one who enjoys a good debate, I tend to focus on the form and substance of arguments in order to understand their validity and ultimately their truthfulness and I find this argument to be essentially another variation of the ad hominem (attack the debater) tactic.
The argument that if you disagree with a change that is made to something, you're afraid of change is just silly and mentally lazy. Rather than analyze carefully what is said, far too often these blog posts are read through the filter of people's own personal biases and commenters tend to take shortcuts in their thinking by attacking the person rather than the argument. Character assassination and creating doubt in the jury's mind regarding someone's credibility may work when defending your self against an accuser in a court room, but it really is not acceptable, nor valid in debates.
Once more:
- I was not "complaining" about Moose/Moo. Only those who work with it daily and have a lot of experience can rightfully "complain". I was simply pointing out that non-Modern Perl programmers are Perl programmers too and we should not feel inferior to Modern Perl Programmers since non-Modern Perl continues to be "damn useful". Additionally, I opined that rather than try to stitch a new bag on Perl, it might be best to consider alternatives. Neither of these points denigrate Moose, nor did I ever utter "I hate Moose". I do hate over engineering as I am a resource manager and over engineering is wasteful on the front end of development and in my experience during the maintenance phase.
- My VW analogy (purposefully designed to be fun) does indeed have a flaw and I wondered when someone would actually point it out. Not withstanding the flaw, I still think the analogy is a good one - rather than pine for a Rolls Royce and satisfy the pining with a griffinesque abomination that is neither a VW nor a Rolls Royce, it might be best to pick one or the other. The analogy of Cobol programmers that don't want to change is also flawed, since while it may be true that some Cobol shops did not feel the need change, folks did not create MooCobol. Most of these developers and shops were innovative enough to move on to languages that offered a different way to think about problems.
My takeaway is that there is a vibrant Moose community. Some have thoughtful arguments and some have sharp teeth that continually looks for things to sharpen them on.
And to those who continue to point me to a slide show in order to enlighten me on Moose are a day late and more than a dollar short. I've read and experimented with Moose and do see how it can help create standards, improve productivity and possibly reduce a lot of common bugs in code. But, I and I hope there isn't too much debate about this - there is always a cost. Learning curve, performance, and dependencies to start. My choice to not promote Moose/Moo for my shop should not be viewed as "unwilling to change", but rather, "unable to justify the cost at this time".
And finally, I wonder why Perl6 isn't all that Moose is? It seems as though the Moose Nation has given up on Perl6 ever being a viable programming language and have instead created MooCobol due to their "unwillingness to change". Unfair, I know. And mentally lazy to boot.
There are probably significant reasons why Perl6 is not acceptable to those using Perl5/Moose and Perl6 is not ready for prime time, however it seems to me that the zealous and clever Moose people might be better served contributing in a major way (I know they already have contributed significantly) to getting Perl6 mainlined rather than putting one more room on the double-wide.
> I was not "complaining" about Moose/Moo.
I'll just say this: If that is truly what you intend, then you need to rework the entirety of your delivery, since you destroy whatever goodwill that sentence generated by following it up with:
> stitch a new bag on Perl
> I do hate over engineering
> satisfy the pining with a griffinesque abomination
"Modern Perl" as I understand it (and as I posted about it) refers to Moo(se). I'll clarify that in any future comments I make about the topic, I apologize, I should have been more clear about that. I do feel the need to clear up a few points that seem to me to have been misunderstood. I have never suggested anyone use an old version of Perl unless you are forced to for some specific reason, an example being that you are stuck with Perl 5.12 if you use mod_perl v1. I am not against OO, in fact that very topic is what I plan to dig into in my next post. Nearly all of my code both personal and professional makes heavy use of Perls OO functionality. use strict, use warnings, unit testing, process and/or code documentation are not optional in my view, I don't think I said anything of that kind but I'll go back and review my post in case I did.
The second half of your post I completely agree with, for what I believe are all the same reasons. I believe in constantly learning, search, growing, expanding my knowledge, view, toolset, understanding, etc.
I have personally found Moo(se) to be something I looked at, and decided against. I then found that if you are not into Moo(se) that there are fewer and fewer public discussions for you to enjoy. For this reason I've decided to start one, it's as simple as that.
I hope this clears up what appears to have been a difference between what I meant to write and what you read.
"Recall that the essence of Modernism is to take one cool idea and drive it into the ground." -- LPW, "Perl, the first postmodern computer language". http://www.wall.org/~larry/pm.html
Mission Accomplished.
I'm one of those Perl developers who recently switched over to Python. And I have to say that I'm a bit sad about it and am currently considering a position in a company that uses Perl.
However, I will only take this position after making sure that they use Moose (or Moo or whatever) in their codebase. I have zero interest in writing blessed hash classes ever again in my life.
In my particular work environment the startup time is irrelevant as it's a extremely tiny piece of the total runtime. Usually the execution of a script takes somewhere between 30 minutes and several hours, so a few seconds of extra startup time just don't matter.
I can't help but comment that some can apparently find in nearly anything apparently and turn it into a reason to bite back. I think a previous poster was correct in characterizing some Moose advocates as "militant".
> you destroy whatever goodwill that sentence generated by following it up with:
> stitch a new bag on Perl
Ok, fair enough. You find the word "bag" to be inflammatory, however adding things to core Perl, to ostensibly create a "better Perl" is indeed stitching a bag on Perl. It might be a Versache handbag or an army duffle bag - I didn't qualify the statement. You did.
> I do hate over engineering
I don't think this statement should generate any ill-will toward anyone, except those who prefer over engineered solutions to clean, simple straight forward solutions to simple problems. Adding the overhead of a framework for a simple problem, is what most professionals I know of would consider over engineering. Keep in mind most business solutions for which Perl is perfect are adhoc, dynamic and/or short lived and I really don't want to pay for the overhead, the extra time, complexity and expense of an over engineered solution. And by the way, I didn't say that all applications of Moose are examples of over engineering. In fact, I readily admit commented that the framework may make sense on some projects - just not the ones I work on.
> satisfy the pining with a griffinesque abomination
That was a reference to my analogy of a VW with a Rolls Royce grill...hyperbole is often used to drive home a point. Be careful not to confuse hyperbole with reality lest you waste your energy addressing the wrong arguments.
Again, take the filters down for a few seconds when you read things. You might actually see things in a different light. As right as you think you are about everything, it's a good exercise to step back and consider the alternative or the fact that there is no right or wrong sometimes.
Preferences and perceptions color most of what people do everyday and while as developer we probably both want truth, facts and logic to win the day, in the end they don't. Worse yet, what we see as truth, facts and logic are always brought to us courtesy of those glasses we wear.
Buddy - great article.
If you want to do something close to
insert %hash into mytable
then have a look at this:
https://metacpan.org/module/DAMI/DBIx-DataModel-2.40/lib/DBIx/DataModel.pm#Insert
This gives you
my $id = $table->insert(%hash);
almost as per your request and with minimal overhead.
@rlauer, I am sorry if my comment in the Perl Weekly felt as a personal attack. I did not mean that way.
It might have felt, that from your post I jumped to conclude something about you - "someone who dislikes change", which I should have not done.
With that said, I don't think that "disliking change" or being a late adopter is a negative personal trait, nor is it necessarily a one-dimensional thing.
I might be a late adopter in one thing but an early adopter in another thing.
Finally, just to comment on the more technical aspect, I think the word "Modern Perl" is a bit overused and has too many different meanings to different people. Dave Cross has a few good articles and presentations on what is Modern Perl. For example
this one published on the Josetteorama.
@Gabor - thank you for chiming in.
For myself, the bits that rile me up (though they shouldn't) are exactly the insinuations that if I don't use Moose then I must dislike change or I am not an early adopter or whatever other negative conclusion is drawn. On the contrary, I want change, I want the next module to be the next big thing, I watch cpan releases and follow blogs. But if I try something out and it doesn't apply or it doesn't work for my case, I ignore it. Moose didn't work out for my use cases. I moved on. Many people have moved on. But the apparent buzz in the perl blogosphere is still here on Moose. And that is fine. It just is wearisome for those have made the conscientious choice not to use Moose.
rlauer and David Schultz have both given very good blog posts about not using Moose. But rather than being approached with any sort of balanced review in their comment sections, instead have received rather beyond-the-mark criticism from some who appear to feel their small-ecosystem-in-a-vast-cosmos-of-ecosystems is threatened by somebody not wanting to enter it.
So please remind people if you can, that while there is no requirement of civility on the internet, there is at the same time no good reason to not be civil, and the perl-community at large will get along much farther and faster if the PDL people get along with the Moose people, and the scripting people, and the functional people, and the dancer people, and the pre-modern people, and the orm people, rather than talking around each others points.
BTW Gabor, thank you for the Perl Weekly!
PS - For those thinking I'm disparaging Moose by referring to it by "small-ecosystem" - take a step back and breath - I'm disparaging pretty much all code and frameworks in all languages - every single one is a small-ecosystem in relation to the world at large. Outside of these tiny worlds we make for ourselves *NOBODY* cares about our ecosystems. They don't.
Paul, no, those were emphatically not good blog posts about not using Moose. Those were blogs posts that both said "I'm sick and tired of hearing about Modern Perl". Both used Moose as examples, but neither was about Moose. Now maybe their mistake was to throw out the baby with the bath water, but that's still a mistake.
Saying "Moose is not for me and I don't really need it" is one thing. Saying "Modern Perl is just another fad and I looked at Moose an it's not for me, so please stop touting Modern Perl" is a completely different thing.
At what point did I say "so please stop touting Modern Perl"? I freely admit (as shown in my first reply to this post) that I used the term "Modern Perl" which was completely in error, I meant Moo(se).
I'll continue apologizing over and over again for the same thing if required, but it does seem a bit off to continually berate me for something I've already admitted was in error.
We've given the dogs a bone...they need to chew on it. I actually expected more civility in these blogs. I'm reconsidering whether to bother to blog here. I'm doubting whether this community of people actually want to hear opinions and different points of view or simply want to scare people off by misinterpreting and assigning meaning in order to grind their axe.
In my first post I noted that the Perl community that has always been inclusive with their mantra of the "there's more that one way to do it" should have a tent big enough for everyone. Apparently, it only holds Moose. ;-)
@David: I'm sorry, I guess I was overgeneralizing. You're right, you never said that.
@rlauer: I'm sick and tired of your vicious cycles of 1) lamenting ad-hominem attacks, 2) ad-hominem attacks, and 3) weaseling out of 2). That's why I will refrain from commenting on your dogs remark. Let me just say, that civility is not something where it is frowned upon to point out glaring mistakes.
@confuseAcat
Civility is more about tone than it is about disagreement. Disagreeing may or may not be civil purely based on tone. Your tone is decidedly not civil.
@paul
I tried to respond but ended up with to much to say so it ended up as a full post