nysus has asked for the wisdom of the Perl Monks concerning the following question:

Ok, why isn't this auto-compile checking tip up there with use strict as the best piece of advice to give a novice Perl programmer?

This is like having a silent friend quietly watching over your shoulder nudging you every time you make a mistake with absolutely no extra effort on your part.

How can it be that I'm just hearing about this now? Am I more clueless than I thought or is there some kind of drawback to using this tool that I'm missing?

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

Replies are listed 'Best First'.
Re: Auto-compile checking??? WTF?
by jeffa (Bishop) on Apr 15, 2016 at 18:04 UTC

    I solve this problem by writing unit tests. I start a Perl project with Module::Starter which provides the basis for your unit tests.

    jeffa@jeffa:~/code$ module-starter --module=Foo::Bar --author=me --ema +il=me@here.com Added to MANIFEST: Changes Added to MANIFEST: ignore.txt Added to MANIFEST: lib/Foo/Bar.pm Added to MANIFEST: Makefile.PL Added to MANIFEST: MANIFEST Added to MANIFEST: README Added to MANIFEST: t/00-load.t Added to MANIFEST: t/manifest.t Added to MANIFEST: t/pod-coverage.t Added to MANIFEST: t/pod.t Added to MANIFEST: xt/boilerplate.t Created starter directories and files jeffa@jeffa:~/code$ pushd Foo-Bar/ ~/code/Foo-Bar ~/code jeffa@jeffa:~/code/Foo-Bar$ prove -lr ./t/00-load.t ....... 1/? # Testing Foo::Bar 0.01, Perl 5.022001 ./t/00-load.t ....... ok ./t/manifest.t ...... skipped: Author tests not required for installat +ion ./t/pod-coverage.t .. skipped: Author tests not required for installat +ion ./t/pod.t ........... skipped: Author tests not required for installat +ion ./xt/boilerplate.t .. ok All tests successful. Files=5, Tests=4, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.02 cusr + 0.01 csys = 0.06 CPU) Result: PASS
    In my opinion, this is far better than a mere perl -c because you now have a framework with which to add finer grain tests for your code. Replace watch with a service like Jenkins or https://travis-ci.org and increase your available options.

    For what it is worth, i have been using vim exclusively for over 15 years now. Good quality, maintained unit tests are more valuable to me than an IDE (and i honestly consider IDEs to be crutches).

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    

      Yes, I am definitely interested in exploring unit testing. I am starting to get comfortable with Moose and I was thinking that learning about unit testing would be the next major skill I should learn. Thanks for pointing out these tools to me because I don't know where to begin. Do you know any good basic perl-related tutorials regarding unit testing that might help me get up to speed fast?

      $PM = "Perl Monk's";
      $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
      $nysus = $PM . ' ' . $MCF;
      Click here if you love Perl Monks

        Unit testing is one of the most very useful tools of a good developer (any language). Before, or as you code, you simply write code that uses your software just like a user would (while throwing in all the edge cases you can think of) to make sure your code is doing the right thing.

        You write these tests as you go, so the more you code, you run your tests to ensure you haven't broken something you coded earlier.

        See Test::More. That'll get you well on your way. Then, go to MetaCPAN and browse to the t/ directory of random modules and read the unit tests. Some modules have clear tests with good descriptions, other modules don't have any tests.

        The most important thing about writing tests is write them now. Not after you get those two new features added, not next week, they should be part of your coding regimen. Doing it this way helps make sure code you've already written is to the best of your ability not doing something wrong due to future changes.

        Getting up to speed fast will be an accomplishment. I am hard pressed to find a good, modern tutorial for unit testing with Perl, but i did run across this Youtube video and i thought the first 10 minutes are actually pretty nice. The final 20 seem to cover code coverage which might be more than you need, right now. I find code coverage to be more useful for legacy code you have inherited, but it can greatly help you ensure that all areas of your new code is being tested as well.

        jeffa

        L-LL-L--L-LL-L--L-LL-L--
        -R--R-RR-R--R-RR-R--R-RR
        B--B--B--B--B--B--B--B--
        H---H---H---H---H---H---
        (the triplet paradiddle with high-hat)
        
        You posted a lot of vi centric questions lately, would you mind marking them consistently?

        I for instance try to mark emacs stuff with a leading [emacs] in the title.

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Je suis Charlie!

Re: Auto-compile checking??? WTF?
by Your Mother (Archbishop) on Apr 15, 2016 at 17:10 UTC

    They're good tips++. They're highly IDE/ENV dependent. Most of us could reel out tips for a couple hours that would largely be uninteresting to most of the rest of us due to their specificity. I hadn't thought to use watch that way but it seems obvious once I see it.

Re: Auto-compile checking??? WTF?
by dasgar (Priest) on Apr 15, 2016 at 18:36 UTC

    I'm not opposed to the main concept of what you are referring to. However, I would like to point out that the blog post that you provided a link to is not fully OS agnostic. As someone who works primarily in Windows, the specific examples of using watch and a Vim plugin doesn't apply to the situation of using a Windows system and using only native tools. But I'll try to remember those specific tips the next time that I'm trying to write some Perl code while on a Linux system.

    Personally, I've been using Padre, which does some syntax checking as I'm typing code. That mostly achieves the same effect - as long I'm paying attention to what Padre is trying to tell me.

    The main feedback that I would offer is that it's my opinion that it would be better to stick with covering a general concept when trying to give advice to "everyone" rather than only covering an OS or tool specific implementation of the general concept. Otherwise, it's easy for those who don't use that specific OS and/or tool to simply ignore the advice based on the assumption that it doesn't apply to them.

Re: Auto-compile checking??? WTF?
by LanX (Saint) on Apr 15, 2016 at 17:11 UTC
    It's part of the IDE discussion we have here from time to time and I regularly mention flymake for emacs.²

    A big part of the problem is terminology mentioning "emacs" alone makes many people look away and I don't understand VI speak. see also: What are the criterias of a "good" Perl IDE?

    Thanks for the link ... I didn't know about flycheck-mode yet.

    BTW: I'm preparing a talk about emacs as IDE for YAPC::NA , so if you are around ...

    (... and emacs has an excellent vim-command-emulation called evil-mode ;-)

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

    ²) I'm always using it and I'm not a beginner ...

      Your link to YAPC::NA appears broken.

      Unfortunately, I don't have the capacity to learn a new tool. But it seems like watch would be independent of vim or emacs, right?

      $PM = "Perl Monk's";
      $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
      $nysus = $PM . ' ' . $MCF;
      Click here if you love Perl Monks

        flymake is built in and runs regularly in the background (if activated), your vim example apparently only when saving.

        Komodo has this feature activated by default.

        Most VIM users I know combine VIM as lean solution (bike) with other heavy IDEs like Komodo or Eclipse (trucks), learning emacs spared me the time to learn multiple tools.

        The main argument for sticking with VIM is the good design of key-commands which is deeply embedded in "muscle memory". This is addressed by evil-mode.

        So if you ask why ("WTF") you always ignored that feature, the answer might be that you are far too VIM centric and avoiding to look at other tools.

        For comparison: Looking at JS, Ruby, TCL and Python made me a better Perl programmer.

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Je suis Charlie!

        Doesn't look or act broken to me. Works as expected. Do you have some sort of restrictions on use of DuckDuckGo as a search engine?


        Spirit of the Monastery

        Questions containing the words "doesn't work" (or their moral equivalent) will usually get a downvote from me unless accompanied by:
        1. code
        2. verbatim error and/or warning messages
        3. a coherent explanation of what "doesn't work actually means.
Re: Auto-compile checking??? WTF?
by Mr. Muskrat (Canon) on Apr 15, 2016 at 19:30 UTC

    Compile checks are a nice first step but they do not replace unit tests or end-to-end testing. You can have code that passes a perl -c that dies when you try to run it.

Re: Auto-compile checking??? WTF?
by MidLifeXis (Monsignor) on Apr 15, 2016 at 17:20 UTC

    See also flymake mode under emacs.

    --MidLifeXis

Re: Auto-compile checking??? WTF?
by Anonymous Monk on Apr 15, 2016 at 23:10 UTC

    Ok, why isn't this auto-compile checking tip up there with use strict as the best piece of advice to give a novice Perl programmer? This is like having a silent friend quietly watching over your shoulder nudging you every time you make a mistake with absolutely no extra effort on your part.

    Because even beginners have editor preferences, and learning to program isn't about saving one or two keystrokes (what it takes to run perl -c yourprog.pl , either up+enter in your shell, or F7 in your editor...)

    How can it be that I'm just hearing about this now? Am I more clueless than I thought or is there some kind of drawback to using this tool that I'm missing?

    Monitor obstruction (the feet/toes) :D