in reply to Re^3: Yet another config file editing programme : Tell me how to make it better !
in thread Yet another config file editing programme : Tell me how to make it better !

dazz, let me preface my reply by quoting Larry Wall from Programming Perl.

You can use Perl however you see fit ... People feel like they can be creative in Perl because they have freedom of expression: they get to choose what to optimize for, whether that's computer speed or programmer speed, verbosity or concisenness, readability or maintainability or reusability or portability or learnability or teachability. You can even optimize for obscurity, if you're entering an Obfuscated Perl Contest. Any level of language proficiency is acceptable in Perl culture. We won't send the language police after you. A Perl script is "correct" if it gets the job done before your boss fires you.

You've made it clear you're an occasional Perl programmer who values readability highly. I'm further assuming that you code Perl alone (rather than in a team) and that you're trying to "get your job done before your boss fires you". Is that right? I'm fine with that BTW.

As I'm sure you're aware, the monks who responded to your thread probably use Perl in a very different work environment and participate here for different reasons. You may have noticed, for example, the light-hearted tone tybalt89 used around readability vs brevity. This is because he's renowned around these parts for writing very clever and very terse Perl code. He will comment further if he wishes, but I'm guessing he participates here mainly for enjoyment ... and he really enjoys writing clever and terse code!

As you might have guessed, I value clean and efficient code at work, code that must be maintained by teams of many different programmers over periods of many years ... while also enjoying recreational Perl (e.g. obfu and golf) as a pastime ... hmmmm, maybe I have a personality disorder. :) The many links at my home node will give you more detail, in case you're interested.

I confess I pulled a face the instant I set eyes on your: 

if ( $isFoundInterface == true )

[download]
Though this is "readable" to you (and I'm fine with that, TMTOWTDI is part of Perl culture), if anyone in my team presented this at a code review meeting, we'd all be checking our phones to see if it was April the first. That is because in my environment, code must be maintained for many years by many different programmers, so we need to stick to the programming mainstream, individualistic eccentricities like this would never pass code review.

Update: Put another way, in my work environment, Maintainability is more important than Readability (see Readability vs Maintainability).

  • Comment on Re^4: Yet another config file editing programme : Tell me how to make it better !
  • Download Code

Replies are listed 'Best First'.
Re^5: Yet another config file editing programme : Tell me how to make it better !
by dazz (Beadle) on Sep 06, 2021 at 00:13 UTC
    Hi I am not a professional programmer. I don't work with or for any professional programmers (does it show???). I am merely an engineer whose toolbox includes some software languages. 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.
    I thought that perl would be the ideal tool to do something as simple as copy ip settings from one file to another. What I found was two broken case type constructs that seem to have remained broken for at least a decade? with no fix in sight. A Unix config module that goes half way to solving a problem, but like a hammer with no handle, is not much use to anyone. Really clever code that needs a Rosetta stone to translate.
    Of course only a bad craftsman blames his tools but a good tool should enable simple things to be done simply. In the hands of an expert, that is doubtless true for perl. I shouldn't need to be an expert. As a non-expert, this simple task has proven to be a lot more difficult than it should be. I did not expect to hit fundamental language defects and I did expect to find a module that would hide all of the cryptic clever code.

    Dazz
[reply]

      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:

[reply]
        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]
        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]

      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.

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
[reply]
        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
[reply]

      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...

      Give a man a fish:  <%-{-{-{-<

[reply]
[d/l]

In Section Seekers of Perl Wisdom