Re^6: Yet another config file editing programme : Tell me how to make it better !

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:

Comment on Re^6: Yet another config file editing programme : Tell me how to make it better !

Replies are listed 'Best First'.
Re^7: Yet another config file editing programme : Tell me how to make it better ! by hippo (Archbishop) on Sep 06, 2021 at 10:22 UTC
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. (++) 🦛	[reply]
Re^7: Yet another config file editing programme : Tell me how to make it better ! by dazz (Beadle) on Sep 07, 2021 at 23:45 UTC
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	[reply]