I am not a professional programmer. I don't work with or for any professional programmers ... The thing that attracted me to Perl was the extensive library of modules. Lego blocks that I could join together to get things done. Not a new concept. I was using Coral66 back in the 1980's ...

Interesting to learn your programming history! Hadn't heard of Coral 66 before.

Queen Elizabeth II sent the first email from a head of state from the Royal Signals and Radar Establishment over the ARPANET on March 26, 1976. The message read "This message to all ARPANET users announces the availability on ARPANET of the Coral 66 compiler provided by the GEC 4080 computer at the Royal Signals and Radar Establishment, Malvern, England, ... Coral 66 is the standard real-time high level language adopted by the Ministry of Defence"

-- CORAL (wikipedia)

Notwithstanding Coral66 being a fine language for its time -- even endorsed by Her Majesty Elizabeth II I see (rare for a programming language) -- I don't agree with your expectation that programming with Perl and its vast CPAN library is as easy as playing with Lego blocks (besides, it's Jenga not Lego ;).

Update: In addition to endorsing Coral 66, Her Majesty Elizabeth II adores the Perl programming language - which she subtly reveals by wearing a pearl necklace time and time again (as in her wikipedia photo).

Though using CPAN modules may seem "free", there are many pitfalls for the unwary (as noted at Writing Solid CPAN Modules):

• What if the CPAN module has a security vulnerability? What if the author abandons it? How quickly can you isolate/troubleshoot a bug in its code? Does its license restrict what you can do with your code? If it requires Perl 5.20+ so do you. If it's Linux-only, so are you.
• It's usually best to use popular, quality CPAN modules in complex domains (e.g. DBI and XML) rather than roll your own. Doing so allows you to leverage the work of experts in fields that you are probably not expert in. Moreover, widely used CPAN modules tend to be robust and have fewer bugs than code you write yourself because they are tested by more users and in many different environments.
• For small and simple modules, on the other hand, such as slurping a file, I prefer to roll my own code rather than pay the dependency cost of an external module.
• Before introducing a dependency, it's worth checking CPAN ratings, Kwalitee score, author, doco, popularity, PM nodes discussing it, community, dependencies (especially unnecessary ones), test results, code coverage, bug counts, how quickly bugs are fixed, ...

Note that many of the points above apply not just to the module you are using but to all of its dependencies too. See also Dependency hell (wikipedia).

So, if faced with your problem, I would roll my own code (without using the dreaded Switch! ;). I would probably roll my own code even if a CPAN module were available, to avoid paying the dependency costs described above.

As already discussed to death, I'd focus on Maintainability, tybalt89 on Conciseness, you on Readability. TMTOWTDI! :)

Updated: expanded last bullet point based on Perl Monks poll: I am most likely to install a new module from CPAN if:

Before introducing a dependency, it's worth checking CPAN ratings, Kwalitee score, bug counts, how quickly are bugs fixed etc.

There was some lively discussion on the I am most likely to install a new module from CPAN if: poll about this a couple of years ago which essentially boiled down to "choose your own metrics". It was interesting to read which metrics were treated as positives by some monks, negatives by others and irrelevant by yet others.

As already discussed to death, I'd focus on Maintainability, tybalt89 on Conciseness, you on Readability. TMTOWTDI! :)

Just so. (++)

---

🦛

Hi
Coral66 was years ahead of its time. The key argument against Coral66 was that it required 10x the processing capacity and memory compared to other languages. This was at a time when hardened military computer systems still used core memory and bit-slice processors at huge $$$.

Roll forward a few decades and the "cost" of including modules is still a topic, even though processing power and memory is a fractional cost.

Interesting.



Dazz

Try not to get hung up on the "switch" issue. In my view given/when is a fine addition to the language, but it came bundled with the smart match operator. It turned out the smart match operator was a bad idea (much too powerful and arcane) and unfortunately, because it was bundled with given/when, given/when acquired the same bad rep. As eyepopslikeamosquito suggests, there are other ways to do it - and that is really a cornerstone of Perl: there are many ways to do most things so you can play around and see what works best for you and the task at hand.

Perl is a great language for this sort of task where you are munging files. But tricky stuff is tricky stuff and all a good language can do is make it easier to think about the key parts of the problem while it hides the boring stuff away. If someone else hasn't already done the job for you (or you can't find it) and you don't want to pay someone to do it, ya just gotta do the tricky stuff.

Hi

I think the problem is mine. I know my knowledge of the language is wafer thin. I recognised that my coding was poor, which is why I came here for advice. Although professionally I direct IT based projects, I haven't seen code, or coded, as part of my job for decades. My last major IT project was for a bank where the application compiled to 22GB in size. It wasn't written in perl. I never met either the vendor or bank programmers. Too many layers of management between them and I. So I only get to actually touch code as a hobby in isolation. The absence of contact with professional programers does nothing to improve my own coding.

I get a little testy when software doesn't match the claims on the brochure and simply doesn't work when it should. I can see that perl is good for getting down in the weeds and gluing systems together. I can also see that modules are a great way of creating Lego blocks that get the job done without reinventing wheels. I was a little frustrated to find language defects and only half built Lego blocks (modules) for a task as simple as updating a Linux/Unix config file. Something I suspect is a routine part of a perl programmers role. It is what it is and I am who I am.



Dazz

I get a little testy when software doesn't match the claims on the brochure and simply doesn't work when it should

While I understand your frustration, and I feel it too (especially in lockdown), I have to ask: given you're not paying for Perl, and to the best of my knowledge have never contributed a single Perl patch or CPAN module, do you feel you have a moral right to complain?

I too get frustrated at times but (like Your Mother) I refuse to criticize devs willing to do things I am not.

Anyways, you've already demonstrated the talent to write useful, working programs, you just need a bit more patience and time (oops, ten years according to the first link below ;) and hard work to reach a level where it starts to become enjoyable.

Some links you might find useful or interesting:

• Teach Yourself Programming in 10 years by Peter Norvig
• The rookie drama recent node by hrcerq
• Conflict in Teams (on the importance of vulnerability and trust)
• Re: Online Tutorial To Get Started (Learning Perl References) (many links on learning Perl)

We'd all like to use a language that provides all the applications we'd ever need or want already encapsulated and available to us via some sort of module mechanism. If you ever find such a language, please, please let me know about it! Until then, I'm afraid we're all stuck with the necessity of knowing how to program in our language(s) of choice. So it goes...