Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

The Most Essential Perl Development Tools Today

by Tommy (Chaplain)
on Jan 01, 2013 at 18:52 UTC ( #1011175=perlquestion: print w/ replies, xml ) Need Help??
Tommy has asked for the wisdom of the Perl Monks concerning the following question:

Times, they are a-chaingin', but are the tools?

I recently asked tobyink about his opinion on this topic, but I thought it also made sense to pose this question to everyone in the community:

If you had to name the 10 most essential tools you use as a Perl developer -- the 10 utilities you wouldn't ever want to work without, what would they be? Now I'm asking about utilities specifically. Stating that CPAN and the Perl community are essential is an obvious understatement, but I'm asking for a list of things more like your software tool suite, such as komodo, padre, eclipse, a good irc client for example...

For me, the list isn't exhaustive; I'm not even sure if I have 10. But what about you?

My list currently includes (in no particular order)

  • Vim
  • perldoc
  • My Reference Manuals and (e)books
  • Revision control (I use git, moving away from subversion)
  • ExtUtils::MakeMaker / Dist::Zilla
  • A test suite; right now it's simply Test.pm, which will likely become something else soon. I'm evaluating my options here.
  • Devel::NYTProf
  • Perl::Critic
  • Debian is the operating system I develop on; it works the best for me. I use Windows 7+Strawberry Perl for testing (and backing up my DVDs)
--
Tommy

Comment on The Most Essential Perl Development Tools Today
Re: The Most Essential Perl Development Tools Today
by toolic (Chancellor) on Jan 01, 2013 at 20:28 UTC
Re: The Most Essential Perl Development Tools Today
by LanX (Canon) on Jan 01, 2013 at 20:35 UTC
    Manolo Blahniks! Never without them!

    Cheers ! And a happy new year! =)

Re: The Most Essential Perl Development Tools Today
by Old_Gray_Bear (Bishop) on Jan 01, 2013 at 20:45 UTC
    My tools, also in no particular order:
    1. vim
    2. Perl in a Nutshell from O'Reilly
    3. Other ORA references on the bookshelf
    4. Additional references in e-book form. (I am old-school, after all)
    5. PerlTidy
    6. PerlCritic
    7. Revision Control (currently git, I haven't found anything I like better)
    8. Nemeth, Snyder, and Hein -- Linux Administration; NSH and Seebass -- Unix System Administration
    9. Ubuntu is my primary development OS, The code runs on Linux and/or Win7+Activestate

    ----
    I Go Back to Sleep, Now.

    OGB

      Perl in a Nutshell? Yikes! It's ancient (1998). Is it truly still useful to you today as a reference?

      It just seems like it must be largely obsolete now, and there must be better books to use today as Perl references. I understand "old school" and its many positive attributes, but the Nutshell book is a relic of a bygone Perl era.

      Jim

        The Nutshell isn't used much a reference at home, but in a contract where they are still running Perl 5.8.x and can't upgrade, it's a God send. I have learned too many neo-perlisms from working with more current Perl's at home; so if I can't find it in the index in Nutshell, then I really can't use it in my for-pay code. (And yes, I know about perl -f, I just don't remember it as often.)

        ----
        I Go Back to Sleep, Now.

        OGB

Re: The Most Essential Perl Development Tools Today
by blue_cowdawg (Monsignor) on Jan 01, 2013 at 21:57 UTC
        Vim

    • Emacs

        Debian

    Any form of *nix environment does for me. I do the majority of my Perl coding at work on a Winbloze 7 box and Cygwin/X.

    I'm surprised your list did not included:

    • strict
    • warnings
    • Carp

    For me I'd add the following:

    • MIME::Lite
      or some other module that allows me to send EMail with binary attachments. I show MIME::Lite on my list because over the years that's the one I use most.
    • XML::Simple which I typically use for configuration parameter storage for my more complex Perl projects.
    • Subversion, CVS or other version control environment
      I call this "super save" because it means there's a version of what I'm writing someplace else. I do frequent commits to my SVN environment just so if I do something really stoopid to my workspace I can recover easily. It also means that I can work on one host, do my debugging and use svn co http://..... to pull the latest version onto another host. I notice you have git in your list, but I ain't ready to give up my investment in time to convert my subversion repositories to git just yet.
    • CPAN Search to look up particulars on various CPAN related modules that I'm using.
    That's all I can think of right now. Lots of scratch paper helps sometimes to help me visualize what I'm doing...


    Peter L. Berghold -- Unix Professional
    Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
Re: The Most Essential Perl Development Tools Today
by tobyink (Abbot) on Jan 01, 2013 at 22:18 UTC
      Many SciTE customizations?

        Nothing especially earth-shattering...

        perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
Re: The Most Essential Perl Development Tools Today
by BrowserUk (Pope) on Jan 02, 2013 at 01:36 UTC
    Perl::Critic

    Would you submit to having your code reviewed by a committed of Java theoreticians?

    Because that is exactly what you are doing by submitting yourself to PerlCritic.

    Fully 95% of Perl::Critic's (and by implication PBP) justifictions are as puerile as banning ball games from school playgrounds because participants might skin their knees.

    Making their own mistakes and learning from them is how kids learn. Banning every construct and idiom, that might under some obscure circumstances cause the occasional program to fail, is like trying to wrap your kids in cotton wool. Overindulgent, counter-productive and ultimately futile.

    Like the boy that cried wolf; perlcritic prematurely bellyaches at the merest hint of a possibility of trouble. And in the process, renders programmers that obey it, to a set of rule-driven automatons that never gain experience; lack any kind of innovation; and ultimately never acquire the programmer's greatest attribute: common sense.

    Many will say (have said) that perlcritic is "only advisory". The problem is that unless you have acquired the experience of when the particular constructs and idioms that it decries voluminously with artificial & fictional reasoning, are useful & not; dangerous & not; perfectly acceptable despite their dangers, & not; you will never have the knowledge upon which to reject its advice. Or not.

    Perlcritic is the thin end of the wedge to the de-skilling(*) of the programmer's art. Reject it. JUST SAY NO!

    (*Look up that word. Learn from the history that underlies it. Remember the old fart's of today were yesterday's youth. And do not deceive yourself into thinking that the youth of today know anything; think anything; or try anything that their forebears didn't know, think or try 20 years before them. Those that ignore history are bound to repeat it.)


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      I love it. The dissenting opinion... and it's a good one. You've made a very good case here. I have to take this into account; you've persuaded me a bit, and I think some changes are necessary.

      Thank you.

      And I'll disagree, but just a little.

      There are mechanical I-should-probably-always-do-this things that Perl::Critic can check for:

      • Did you use strict and warnings?
      • Did you remember to use 3-arg open?
      And several other things that Perlmonks repeatedly urges people to do that are on the mechanical side, meaning that they are simply "did I remember to do this or not?" questions that are not syntactically or semantically invalid, but are reasonable standards to enforce on your code. If the requirement to do something is mechanical, then making the check to see that it is done mechanical is reasonably well-advised.

      I do not currently run Perl::Critic against our codebase, but I can see that there are some - some - checks that might be useful - the "did I remember" ones. I do completely agree with BrowserUK that running all of the checks and just doing everything it says to do is very much the wrong way to go, mostly because you're abdicating your own judgement and knowledge of the code to something that does not actually understand the code at all.

      Used as a to-do list specifically for what you want to remember to do, and adapted to your particular needs, Perl::Critic is pretty useful. Otherwise, it's like a to-do list that includes the things that someone else has decided people Should Do.

      Metaphorically speaking, if you have a busy 20-something single woman living in Brooklyn and a forgetful 80-something man living in rural Arizona, the Brooklynite doesn't need a reminder to shake scorpions out of her shoes, but it might be critical for the Arizonan. Perl::Critic by default reminds you to be careful not to be mugged for your phone, but has no idea that scorpions even exist.

      (Okay, to stretch the metaphor, it's actually warning you to not be mugged for your Walkman because it's never heard of cellphones.)

        Used as a to-do list specifically for what you want to remember to do, and adapted to your particular needs, Perl::Critic is pretty useful.

        Sorry. But that "you can configure it to your needs" argument simply doesn't hold water. Let's start with the extremes:

        1. The experienced. Perler.

          When PC (thos initials say it all :) first came around, I ran it out-of-the-box against several scripts and modules -- some my own; some by authors I respect and trust -- and it just bugged me intensely.

          It whinged and whined and cried wolf about every other line of code. The only time I have ever seen so many warning messages was when I tried to compile my first Pascal program and mistakenly had used {}'s instead of BEGIN/END. The volume of output (from PC) was ludicrous; given the scripts and modules were all tested, well-exercised, thoroughly debugged code.

          First, I tried to # no perlcritic all the failing lines in one script of about 20 lines that had probably taken me 15 or 20 minutes to write, it took nearly an hour to understand what each message was meant to be warning me of -- there were a few warnings that without the benefit of PBP; I simply never did understand. The result was that the script almost doubled in size, and became unreadable because of all the garbage non-comments.

          So then I tried to evolve one of the modules to pass without disabling. I gave up on the script and the first two modules; because they simply could not be made complient and still work. That took almost two hours and the result wasn't like Java. It was worse. it over doubled in size because of all the useful idioms that had to be rewritten into prozaic generic syntac. And it ran substantially more slowly. But worse, with twice as many lines, it almost certainly contained twice as many bugs as a result. It was definitely twice as hard to understand (more lines; more to read and understand, for an experienced Perler), and therefore harder to maintain.

          So, to the idea that I could disable those warnings that I disliked. I did. I simply stopped using it. There's more about that further down...

        2. The novice.

          The novice starts using PC up front; and discovers that every line of code he attempts to copy or adapt from any Perl books he has access to -- from mastering Perl to Perl in a Nutshell to Perl for Dummies and everything in between -- won't pass PC's default settings.

          But how can he configure it? He doesn't have the experience to know which warnings he should heed and which to ignore.

          Beginner's have enough trouble with warnings; if they get around to adding it, as often as not they end up commenting it out. With PC, even if they copy the literature slavishly, they still get whinged at for doing the wrong thing. Talk about discouraging.

        ... If I disable everything; what good is PC doing for me? It isn't But when I use the types of things it warns ne about; I do so with consideration at the time; what point is there to having it remind me?

        For example: I purposely choose to use bareword file handles in top level scripts. I do this on the basis that different things should look different; and a top level script *OWNS* the global namespace so there is no conflict as modules should *never* mess with globals. And in modules -- complying with that rule -- I always use lexical file handles.

        So now I would need two configurations for PC. And then another for another (personal) rule; and another; and another...SO then the game is deciding which of those configurations I should run against this particular script or module. But that is pointless because I already made my decision when I wrote the code.

        And that's the second argument against PC. It does static analysis, after-the-fact. I do my analysis dynamically, as I write the code. Anything it chooses to tell me about, I've already made my decision about. (Or I don't want to hear it in the first place!)

        And finally, it is completely possible to write totally unintelligible, crap, wrong and dangerous code that no amount of PC's static analysis will ever detect. Which means it still comes down to testing to determine whether the code does what it is meant to do or not. And once I've done my testing and concluded it works; I couldn't give two monkey's hoots whether some anal retentive, failed Perler, wannabe Java coder thinks the way I've achieved that is sliced bread or moldy goat's cheese.

        Passing my tests won't guarantee that it is 100% bug free; but if it fails in use, it won't be down to anything that PC would have told me about.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

      I'm going to have to pretty much entirely disagree with you.

      I get the feeling from your arguments that you have your mind entirely made up to hate Perl::Critic, so I know nothing I say will convince you of it's usefullness. However, I have used it with multiple inexperienced Perl coders at work and found that it significantly improved their code quality. It introduced them to best practices that they weren't familiar with, and provided a sanity check for them against common mistakes.

      They are inexperienced. They don't know common idioms and best practices. And they're never going to learn it without someone (or something) correcting them. Perl::Critic is a great start. Do they follow everything it suggests? No. But they're not complete idiots, incapable of doing research on their own. If something comes up that they aren't sure about, they search online, or ask someone else about it. They learn from it.

      You seem to think that using Perl::Critic prevents people from gaining experience, although I'm unable to see any logic in that assertion. How exactly are people supposed to gain experience by making the same mistakes over and over, never realizing that they're making mistakes?

      Perl::Critic helps immature Perl programmers improve. It helps out of date Perl programmers learn Modern Perl practices. It's an incredibly useful tool, and I personally have benefitted greatly from it's use.

      Oh, yeah; I do run my code through it regularly, too. It makes for a great sanity check to make sure I didn't make silly mistakes.

        Downvoted!

        Here's why: You do not put forward any arguments for either the authority or efficacy of the result of compliance with P::C. Nor do you state an single example or any reasoning for your conclusion that P::C improves beginners code.

        You go one to say that: "But they're not complete idiots, incapable of doing research on their own."; clearly indicating that not everything P::C recommends is sacrosanct. But which ones? How does the beginner know which of the thousands of spurious and pointless whinges that P::C spews at them is worthy of further research?

        And, when they reach different conclusions to you; are you going to accept their "beginner's research" judgement in good faith?

        Or will you simply judge anyone who has a differing opinion to you, not as one who has taken the time and research and thought to have reach the point of having their mind entirely made up; but rather as someone who exhibits "hate" for a piece of software, as you have accused me?

        You simply state: "I like; I use it; therefore it must be good."

        Which is the exact same problem as P::C. It codifies an opinion as having authority on the basis of puerile and simplistic justifications. And without open and transparent debate and the reaching of some kind of consensus; it does not bear that authority.

        Pick (almost) any single one of P::C critiques and open up the discussion here to all comers comments; and I'll bet you'll never reach a consensus; without you give a specific example of the critiqued construct or idiom in situ. And even if you get a consensus for that specific usage, it will be only for that specific usage; and probably a contrived one at that.

        And for every supporting example; an alternative challenging example will be contrivable.

        And that is the crux of my position; P::C does not (and cannot) take context into consideration. It attempts to make black or white that which is inherently gray.

        And they're never going to learn it without someone (or something) correcting them.

        Exactly so. But demeaning the programmer's art and experience by allowing the substitution a dumb pattern matching algorithm, for proper (human) code reviews, is the greatest danger of a piece of software like P::C. It diminishes the knowledge, experience, intuition and dedication of the programmer to that of an electronic cardboard cutout.

        A surgeon friend of mine agrees that software is at least as hard and complex as surgery; and it takes 7 - 10 years before a surgeon is considered qualified.

        If you personally find P::C useful to you, I have no problem with that -- it it your time and cycles you are wasting -- but suggesting that it is a good way to teach new programmers is bordering on criminality as far as I'm concerned.

        I've spent 35+ years acquiring my programming skills; and I'm not about to substitute my experience, intuition and judgement with a dumb text matching script. And I heartily commend anyone who considers programming to be more than a rote-learnt way to earn a crust, to consider carefully the efficacy of same.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        p
Re: The Most Essential Perl Development Tools Today
by RFMonk (Acolyte) on Jan 02, 2013 at 04:50 UTC

    For mi just Crimson Editor

    CPAN

    My Reference Camel book (PDF)

    That's all I need.

Re: The Most Essential Perl Development Tools Today
by nvivek (Vicar) on Jan 02, 2013 at 08:23 UTC
    I would prefer following modules in the list.
    • Data::Dumper
    • String
    • Warnings
    • vim plugins - for perl which would provide file header, highlight syntax errors and automatic close braces
Re: The Most Essential Perl Development Tools Today
by salva (Monsignor) on Jan 02, 2013 at 13:28 UTC
    • emacs
    • sshfs
    • git or subversion
    • the perl debugger
Re: The Most Essential Perl Development Tools Today
by perl.j (Pilgrim) on Jan 02, 2013 at 15:25 UTC

    Hmmmm... well I agree with you on a few. In no particular order, here is my list:

    • Vim
    • perldoc/cpandoc
    • Programming Perl and Learning Perl
    • Git with Github
    • strict and warnings
    • Perlmonks and Stack Overflow
    • Perl::Critic
    • Windows 7/8 - sometimes Ubuntu
    • Pencil and paper - necessary when designing and brain storming
    • Firefox or Chrome

    I could probably go on for a while, but those are my Top 10.

    --perl.j
Re: The Most Essential Perl Development Tools Today
by SuicideJunkie (Priest) on Jan 02, 2013 at 17:46 UTC

    I usually keep it really basic;

    • Google to hit all documentation sites at once, but usually that's just perldoc and perlmonks.
    • notepad++
    • a flag in the code to repeatedly re-eval the source for "live" editing/debugging
    • a VM to run the code under windows too
    • a test.pl file for TIAS checks
    • SVN repo

Re: The Most Essential Perl Development Tools Today
by jandrew (Hermit) on Jan 02, 2013 at 22:35 UTC

    I would add tkpod for documentation review

Re: The Most Essential Perl Development Tools Today
by petdance (Parson) on Jan 03, 2013 at 22:20 UTC
    • vim
    • ack
    • bash
    • git
    • prove
    • 2nd monitor

    xoxo,
    Andy

Re: The Most Essential Perl Development Tools Today
by nagalenoj (Friar) on Jan 04, 2013 at 10:10 UTC
    I use diagnostics sometimes, to know about some warnings and errors. It helps better than google search sometimes, when you are not sure about specific errors.
Re: The Most Essential Perl Development Tools Today
by DrHyde (Prior) on Jan 04, 2013 at 11:26 UTC
    I'm surprised that no-one has mentioned virtualization. I use VirtualBox for working on applications, because generally my applications have non-perl dependencies and virtualization makes it easy to segregate applications from each other. I also generally deploy applications one per virtual machine these days too, now that memory is nearly free, using Xen on Debian.
Re: The Most Essential Perl Development Tools Today
by PrakashK (Pilgrim) on Jan 08, 2013 at 15:29 UTC
    • Emacs (with integrated Perl Tidy)
    • cpandoc
    • Perl Debugger/re.pl
    • perlmonks.org
    • Linux
    • GNU Screen
    • Perlbrew
    • cpanminus

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1011175]
Approved by Corion
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (8)
As of 2014-09-18 11:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (112 votes), past polls