Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Rediscovering Hubris

by Leitz (Beadle)
on Jan 17, 2021 at 23:40 UTC ( #11127047=perlmeditation: print w/replies, xml ) Need Help??

A line from perlootut goes, "There's really no good reason to write your classes from scratch in Perl." I beg to differ. There are many reasons we come to Perl; often those reasons are unique to each individual. What brings the perlootut authors to Perl may not be the same as what brings any of us.

Long ago, when the O'Reilly Perl book was much thinner and had a pink spine, hubris was a valued quality in a Perl programmer. Today many are shunned because they use "ancient" Perls, anything less than 5.30 is "EOL". Some of us have to live in the world that doesn't auto-upgrade Perl. We're told to get some collection of modules from CPAN, everything is already done for us. That's a wonderful idea, but it doesn't play out. Many modules depend on XS, or depends on something that depends on XS, yet not every compute node has a compiler. Or the CPAN module depends on something that requires a more recent version of Perl than what we are allowed to code for.

I have actually been told that I should look for another job if work won't upgrade language "X" to a more "modern" version. No real reason, just "more modern". Hubris can have a negative incarnation.

Hubris can help us move forward when the world seems against us. Outside of that one sentence, the perlootut is a wonderfully written and useful document. The perlobj page is also top of the line documentation. In hubris I try to code for Perl 5.8. Not because that version is any better than later versions, quite the contrary! The Perl maintainers do a great job of keeping the language moving forward. In hubris I create objects without Moose, Moo, or any other CPAN OOP module. My good reason is so that I better understand what is going on and how Perl objects work. In hubris, because I dislike the fragility that comes with unnecessary complexity, I seldom use CPAN modules.

Despite my struggles with Perl, and the occasional (more than occasional) muttered curse onto whomever thought 27 layers of sigils is human readable, Perl is its own "killer feature". Solid Perl 5.8 code still works well. If you removed CPAN from the multiverse, Perl could still do more than most of us. Other (dang near all) languages are easier to learn. Some of them have much faster performance, or significantly more hits on job search boards. At the end of the day, though, if it can be done then you can probably do it in Perl.

I currently work in Perl. To push my skills further, my personal projects (toys, really) are in Perl. Despite being a slow learner, and struggling every day, I honor my employer by doing my best. And that is my killer feature.

Chronicler: The Domici War (domiciwar.net)

General Ne'er-do-well (github.com/LeamHall)

Replies are listed 'Best First'.
Re: Rediscovering Hubris
by chromatic (Archbishop) on Jan 18, 2021 at 20:47 UTC
    Today many are shunned because they use "ancient" Perls, anything less than 5.30 is "EOL".

    I think you're missing two things here.

    First, Perl has yearly releases because that's how the core team believes it can best continue to deliver value to Perl users for free. That's a balance of new features, bug fixes, optimizations, and security improvements. You're probably not paying for that. I'm probably not paying for that. No one in my company is writing a check to the Perl core team once a year to get this, so we don't have a lot of say in how the members of the core team spend their time.

    Second, regardless of the success with which the core team has made it possible to run code written for 5.8 on 5.32, there are things you're not getting in 5.8 that you might really need from 5.32. Some of these are security improvements. Some are performance improvements. Some are subtle when you don't know you need them (Unicode improvements), but some are essential when you realize you do (Unicode improvements). Some are really difficult to overcome, such as building an older release on a newer platform.

    No one should shun you for running an older version, but you're taking a lot of risk on yourself that running a newer release would otherwise let you avoid. If that's the right thing for your organization, that's one thing—but making that choice without acknowledging that you're on your own and you shouldn't expect core team support or free community support is another.

    Does that help?

      Some are really difficult to overcome, such as building an older release on a newer platform.

      If the situation here is as I understand it, I believe that it involves older releases installed long ago on older platforms, with no will to install newer releases for whatever reason. Managers can be "funny" that way and I have had to deal with similar situations in the past.

      So the code here needs to run on many Perl versions, from 5.8 to 5.32 or so, whatever the various machines in $WORK's fleet have installed.

        The situation I'm thinking of is where the underlying machine has to upgrade (or is replaced), which is a hassle. If neither of those cases is true, some things are easier and some things are a lot more difficult.

      Why would the community not provide advice when I ask a question that is limited by an older Perl? While I have had people explicitly say they won't help because I'm not running a "supported" version, those people seem few and thankfully far between. Granted, there's a big difference between "must use print instead of say" and "we need the unicode support in version 5.XX". I completely agree that if I want something in 5.20 then gosh, I guess I'm using 5.20 or later.

      Funny story: I was using an old OS based version of a language. Got a lot of flack for it and the whole "we won't support you" junk. I really liked the language, and started pulling daily dev builds. Even found and fixed a bug in the test suite. Then I'd get flack for using a version that was "too new." Can't please some people.

      I haven't read "Modern Perl", but people whose opinion I trust recommend it. When a newbie asks about a good book, I'll recommend it. Vintage is nice in a car, great in a wine, but not so hot in a computer language. On the other hand, I'm finding "Perl Testing: A Developer's Notebook" to be priceless.

      For me, having to use older Perl with minimal CPAN has been a very good thing. I am pushed to actually learn how things work. I can build a robust and portable, if not fancy, codebase. My path isn't how everyone else gets here, I'm okay with that. A friend wants to build something with 5.20 and lots of CPAN; cool.

      The path to learn is difficult enough. Pushing against learners because they use older tools just weakens the community. If they can learn enough then they'll move forward when it works best for them.

      Chronicler: The Domici War (domiciwar.net)

      General Ne'er-do-well (github.com/LeamHall)

        Why would the community not provide advice when I ask a question that is limited by an older Perl?

        I didn't use the word "advice", but I'll address this anyhow.

        From a security perspective, if you ask "How can I harden my 5.8 application against user-input hash DDoS attacks?", the answer is going to be "Upgrade". You're unlikely to get someone to backport a hash seed randomization patch for free.

        From a personal perspective, if you ask "How can I perform task $X, but only on 5.12 or earlier", that means I'd have to install an earlier version of Perl and think really hard about how to write something without regex improvements, signatures, postfix dereferencing, improved capture groups, lexical subs, or any of a dozen other little improvements I've grown accustomed to, not to mention code that only runs on newer releases (anything that relies on pluggable keywords, Mojolicious, etc etc.)

        I don't see a lot of personal value to me in keeping around 30-odd versions of Perl to backport a solution to, so I'll just ignore it and move on.

        That doesn't mean you should or shouldn't use a specific version; just that you should expect you've limited your peer pool when asking these kinds of questions.

        I agree having to use print with a newline instead of say is not a good reason to upgrade ... yet I'm struggling to understand your seemingly blase attitude towards Security. (Oh, and I strongly agree that chromatic's Perl (and agile dev) books are awesome! ;-).

        I suspect you come from a different (smaller?) commercial environment than me. Do you have Security auditors? We do, they use tools (luckily mostly Windows-only for now) and they have the ear of upper management. If you're using a version of Perl open to security exploits (see perlsec ... DoS attacks based on Perl hash algorithmic complexity spring to mind) or any product (including Perl) that is out of official support, they'd be all over you like hair on soap.

        They don't have the time to understand all the nuances of every product running on every computer so they tend to heavily rely on tools and enforce blanket rules, such as "you are not allowed to use a product that is out of support" or "you must regularly check for exploits and patch your software promptly".

        For me, having to use older Perl with minimal CPAN has been a very good thing. I am pushed to actually learn how things work.

        Maybe you'll learn more with a still older perl? I wrote my first Perl 1.0 program in 2017 and learnt that I did not want to learn how it worked. Sorry, couldn't resist. :)

Re: Rediscovering Hubris
by eyepopslikeamosquito (Bishop) on Jan 18, 2021 at 04:02 UTC

    What you're saying sounds reasonable if working solo ... but not if working in a large team for a large organisation. How many developers are in your team at work? How do you organise your teams at work and how do you go about improving teamwork?

    To illustrate where I'm coming from, some points derived from Why Create Coding Standards and Perform Code Reviews? follow.

    Successful software tends to live a long time: bugs are fixed; new features added; new platforms supported; new versions of the language and its libraries are released; the software adapted to new markets. That is, successful software development is a long term activity. Planning for success means planning for your code to be maintained by a succession of many different programmers over a period of many years. Not planning for that is planning to fail.

    Programming is easy, Engineering hard. You need to hire programmers with sound technical skills and domain knowledge, enthusiastic, motivated, get things done, keep the code clean, resilient, innovative, team players ... and then motivate them, train them, keep them happy so they don't want to leave, yet have effective handovers when they do ... a hard problem. Yet to be successful that's what you need to do.

      I'm not seeing how this is a refutation of the OP. Good teamwork doesn't require coding against bleadperl and using all the latest whiz-bang FOTM modules from CPAN. Shunning CPAN is going rather overboard, certainly, but doing good engineering requires building on a solid foundation of proven technologies rather than chasing the "latest and greatest" new shiny. Particularly when you know the proven technologies will still be there in the long term, but the new shinies might not.

        Some of the “latest and greatest” Perl libraries are 15 years old.

        I wrote this up at some point better but here’s the tl;dr: someone could write the most genius library in Perl history but if it comes without full tests, documentation, a ticket queue… it is hurdle riddled nonsense as far as value to other hackers, coworkers, and inheritors. And unless one is a “class A hacker,” as the animes say, the chances of the software being actual genius is basically zero.

        If that sounds like I discourage writing stuff from scratch, I don’t. I have always advocated for as many new libraries and experiments as possible, while also being quite judgemental of low quality releases and output of other paid devs. Hobby, experiment, personal project? Anything goes. Leaving a mess for others? Not cool.

        Fair enough. Yes, it's true you want to be solid, but I also feel it's vital to do more. Here's why.

        If you're successful in the long term, sooner or later you're gonna need to upgrade ... and developing a strong upgrade capability early forces you to implement high automated test coverage early ... which confers many benefits, listed at Effective Automated Testing.

        With high automated test coverage in place, you can confidently test your software with many different versions of Perl and libraries ... which may flush out further bugs (e.g. a test may pass with one version of Perl/library but fail with a different version). In summary then, developing a strong upgrade/autotest capability early improves code quality.

        It also gives a psychological boost - you no longer fear/dread having to upgrade or port to a new platform, you welcome it! You can easily run experiments with different versions of Perl and libraries to verify that everything still works and to see if they run faster or slower and by how much.

        Finally, being able to gracefully move to the latest and greatest may help with recruiting top notch developers (especially younger ones). Admittedly most of my experience here is with C++ programmers but, especially the younger ones, are usually energized by using the latest and greatest features.

        Regarding teamwork, you are right, I was out of line, I was imagining the arguments between Leitz and some of the younger guys at work who love using the latest and greatest. :) I've experienced many heated arguments in teams over the years, as indicated at Conflict in Teams, so have learnt the hard way that it is vitally important to clear the air and get everyone pulling in the same direction.

Re: Rediscovering Hubris
by jcb (Parson) on Jan 18, 2021 at 03:14 UTC

    Hear, hear!

A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://11127047]
Approved by GrandFather
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (2)
As of 2021-02-28 08:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?