I have always been perfectly happy using the combination vim + shell + perldoc.
Today a new colleague joined my company. One of the first questions he posted
on the mailinglist was which IDE or professional toolkit we recommend for perl development.
I wonder how much productivity one could gain with the ActivePerl Pro Studio and similar toolkits.
Is it worthwhile? How are your experiences?Is he just a guy of the "M$ Visual Studio" category?
Update:
Removed bad mouthing...

Replies are listed 'Best First'.
Re: Professional Toolkits <=> vim + shell
by Tanktalus (Canon) on Apr 05, 2006 at 20:46 UTC

    We have some really strict rules about IDEs and stuff: it's gotta all work in an automated build. After that, do whatever makes you the most productive.

    Thus, we have some developers working in the MS Visual Studio IDE. And some using vi. And some using nedit, emacs, fte, etc. I even know one guy doing perl using EPIC (Eclipse). I do try to discourage using notepad/wordpad and Word, however. ;-)

    Editor choices are the least of your worries. Productivity is one of your greatest worries. If this new guy wants to use a professional toolkit that costs a mere $800, my vote is to say "let him." Personally, I use free environments, but that's because they work for me. And I've managed to put in more than a couple tweaks to help it work the way I work. That obviously doesn't work for everyone.

    Focus on the things that really matter: the code works correctly, quickly (as in development time), and the code itself is maintainable. How you get it there is not really a concern. If you can whistle the code into a modem faster than using vi, then go ahead. Personally, I have trouble getting the ( and backspace characters right that way.

Re: Professional Toolkits <=> vim + shell
by Ovid (Cardinal) on Apr 06, 2006 at 02:15 UTC

    Just out of curiosity, how much experience do you have with full-featured IDEs? The reason Perl doesn't have much in the way of decent IDEs is that Perl really doesn't support them terribly well. It's introspective capabilities are really poor, it's very difficult to parse, you can't infer method or function signatures, the standard testing packages only allow primitive hooks and the debugger is a nightmare (though Devel-ebug seems like a step in the right direction).

    For these and other reasons, IDEs for Perl tend to be limited in scope. A good IDE can speed development quite nicely at the cost of the programmer not memorizing many things quickly. Frankly, I don't want to need to memorize all of the methods DBI uses to fetch results, but instead I need to keep popping open perldoc to remember exactly what I want. A good IDE makes that available in a couple of keystrokes.

    You might be happy with vim + shell + perldoc, but for many Perl developers, they have to be happy with that because that's all they have. It's almost like Guido suggesting closures aren't valuable because Python doesn't support 'em :) (yeah, that's a cheap and somewhat inaccurate shot)

    Cheers,
    Ovid

    New address of my CGI Course.

      I have done some projects with
    • Eclipse, JBuilder (Java)
    • Visual Studio (C#)
    • Visual Basic
    • They are all terribly nice, powerful and essential for their supported languages. I agree that it makes
      sense to switch to an IDE for DBI and other swiss army knife modules.
      I mainly use Perl for short scripts, that require/use modules, that I know good enough.
      There I would soon be annoyed of all the clicking together of commandline arguments.
      I was just curious how far IDE-development with perl has gone and under which circumstances one should dump vim+bash.

      Just FYI, EPIC now does code completion on module methods and has hooks for debugging and perldoc. In case you wanted to try it out again and see if it really saves you those keystrokes ...


      The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon
Re: Professional Toolkits <=> vim + shell
by hv (Prior) on Apr 06, 2006 at 01:43 UTC

    I use fvwm with 4x4 virtual desktops, very uncluttered - the virtual pane is the only sticky window. Most of them are filled with vi sessions, but one has a browser (mozilla), and another my mail client (exmh).

    I used the Microsoft development tools in my pre-perl days, around 1993-5. The one thing I still miss is the function key in the C debugger (F6, I think it was) that toggled between showing C code, assembler, and mixed. Of course it was much more important then because their C compiler was riddled with bugs, but it's still something I need to check from time to time - these days I use this script when I have such a need.

    I really don't know what benefit an IDE would be for me, but in a sense I guess I've developed my own - the work application includes a variety of tools that encapsulate the processes we've devised for project management. I've previously talked about the database upgrade process here, and about the logging facilities here and here, and we also have tools for creating new instances of the application, an installer, database introspection, CVS introspection and more.

    Of course it helps that I'm the primary developer, so the project structure and processes have mostly come straight out of my head, and are therefore easy for me to remember. But my colleague is a Macophile, and less comfortable about opening a couple of dozen xterms at a time, but still has had few problems coping with it (at least that he's told me about).

    Hugo

Re: Professional Toolkits <=> vim + shell
by diotalevi (Canon) on Apr 05, 2006 at 20:26 UTC

    Your characterization of this guy is out of scope of the rest of your question. He may be perfectly competent. Some languages really don't work all that well to develop unless you've an IDE to do the make-work for you.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

      You need IDEs for bureaucratic languages like Java. In Perl the language itself has a lot of power built-in and allows for concise programming. Thus it reduces the need for an IDE to do the work. Did you ever need to generate getter/setter methods in Perl? Perl is highly dynamic. Autoloading, eval on Strings and difficulties with introspection should give an IDE a hard nut to crack. I never considered using Perl-IDEs for that reason. Now a newcomer asks for a lot of money for a tool that I am not convinced is useful. I couldn't help, that the negative attitude came into my mind when I read the e-mail and wrote the node.

      I hope that you are right, he is a smart guy and I discover that Perl-IDEs are not be such a bad thing as I initially thought.
      Update:
      And that is my new attitude now. :-)

        You didn't understand what I wrote. I didn't say a thing good or bad about perl IDEs. You were badmouthing the guy and I was calling you on that.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

      I have been using OptiPerl from Xarka for some time.

      I really like the syntax highlighting and code folding, as well as the integrated Pod2Html window.

      I think I will probably move on to EPIC next though. My only complaint is Eclipse's project management (or lack thereof). I wish it would actually create new folders on disk, instead of just "folders" in the project. Maybe I could add the functionality as a plugin...
Re: Professional Toolkits <=> vim + shell
by ciderpunx (Vicar) on Apr 06, 2006 at 11:34 UTC
    > vim + shell + perldoc

    You missed google!

    On a more serious note, one disadvantage of "integrating" your development environment is that you lose (or sideline, anyhow) the flexibility and power of the shell.

    I'm also a big fan of using one editor - in my case vim - for everything. So I use my editor for developing perl, ruby, php and java but also for email and for drafting documents (they go into openoffice if they need to look pretty).

    I guess if you're wroking on a project that'll involve pair programming it'd be pretty important to have a standardized setup of editor/shell or IDE. Even if that meant having to not use your favourite editor/IDE. Does anyone have any experience of getting agreements on tools - I imagine its a herding cats type situation!
      In my office we're two working with nedit, and two working with emacs. No problem so far...
Re: Professional Toolkits <=> vim + shell
by explorer (Chaplain) on Apr 06, 2006 at 17:18 UTC
Re: Professional Toolkits <=> vim + shell
by jdtoronto (Prior) on Apr 06, 2006 at 19:10 UTC
    As a Perl shop I am a one-man concern, I used to be a plain editor type (vim on *nix) but now I am constrined to working on Windows much of the time. I tried EPIC/Eclipse, but it got to be very slow. So I decided that Komodo with the PDK would do what I needed. It has, it has been very stable, makes project management easier, integrates with CVS and has given me back a life!

    I have contract coders work for me, they are free to use whatever they want - I don't look over their shoulders so I don't much care. But whilst I am far more comfortable using Eclipse or Komodo, that doesn't mean that people can't be productive in an environment such as the one you prefer.

    jdtoronto

Re: Professional Toolkits <=> vim + shell
by vkon (Curate) on Apr 06, 2006 at 16:14 UTC
    I quite often use ptkdb among other things, which visually looks quite well like an IDE, because of its step-by-step debugging, and ability to watch for variables.
    Its not an IDE, but must-have anyways.

    addition: of some relation to your question, the VTCL IDE is usable from Perl for GUI design, although I, personally, rarely use this approach, and this is not perl IDE (but still a powerfull addition to the one's toolbox).

Re: Professional Toolkits <=> vim + shell
by aufflick (Deacon) on Apr 07, 2006 at 06:40 UTC
    While I agree whith the "whatever works for you" philosophy, it's probably worth asking him if he wants an IDE just because that's what he's used to.

    If he's never tried living inside emacs (my favourite) or vim + shell it might be worth his while trying it out. If someone can use a "project search" function of an IDE but has never learned to use grep is going to miss out when he tries to grep log files etc.

    OTOH, if you are always a vim + shell person it may be worth *your* while trying out a more interactive environment. I especially love the interaction between emacs and the perl debugger - I assume the EPIC or ActivePerl debuggers would be even better.

Re: Professional Toolkits <=> vim + shell
by aufflick (Deacon) on Apr 07, 2006 at 06:47 UTC
    I think this is an important discussion for us to have. The unix-ish way that most Perl developers work is quite different to the way most IDE dwelling Java/MS developers work. It really stands out, and it is not clear to many people whether it is a positive, negative or neutral difference. I think the flexibility to work the way that suits the individual is a real strength of Perl but some options deserve more air time. For instance while I prefer emacs, if "Perl" became as synonymous with Kimodo as with, say, vi, then it might *look* like a more "enterprise" option which will only benefit us all.
      I think this is an important discussion for us to have. The unix-ish way that most Perl developers work is quite different to the way most IDE dwelling Java/MS developers work.
      I completely agree. I do more development in Java than Perl these days and I've had a hard time adjusting to the idea of maintaining a copy of the entire development environment - including an application server - on my PC. I recently switched jobs and the standard Java IDE here is Rational Application Developer (based on Eclipse), which weighs in at over 4 GB with the embedded Websphere server (Yes, 4 GB!). It still blows my mind that Eclipse doesn't have a way to just open and save a file by FTP.

Re: Professional Toolkits <=> vim + shell
by t'mo (Pilgrim) on Apr 07, 2006 at 16:45 UTC
Re: Professional Toolkits <=> vim + shell
by radiantmatrix (Parson) on Apr 13, 2006 at 15:59 UTC

    It is, of course, perfectly possible to be extremely productive and write quality code with vim (or emacs, or any other programmers' text editor), a shell session or two, and perldoc. I even know people who have used such a combination for years and consistently produce more, better-quality code than other good people using RAD tools.

    However, IDEs have advantages as well -- I used Komodo for a while, and I loved its snippets library, the on-the-fly syntax checking, the nice GUI debugger (which is actually a separate app in ActiveState's PDK product, but it's nicely coupled to the IDE). Currently, I use Eclipse with the EPIC plugin for my Perl needs. The on-the-fly syntax checking, code outline (rapid access to subroutines and a handly list of modules called directly from a given file), code templates, and CVS/SVN/ClearCase integration really speed up my work.

    Ultimately, however, IDE v. editor+shell must be a personal decision. I think it's generally better to define polcies and goals for development environments than to force an environment on someone. In other words, saying "people should use Eclipse" is a poor idea, when you could say, instead "all development environments in use must support our versioning system, and all code checked in must not break the build and must comply with our code style guidelines".

    This way, individual developers can use the tools that work most in-line with how they think and work, whenever possible.

    I think it is far too tempting for dev managers to think of a particular development technology as "faery-dust". Technology is a tool, and it exists to enable people1; so, when possible, it's best to let your people find and use technology that they feel comfortable with. Tech works best when good people feel like they can weild it as extensions of themselves.

    1: part of that is taking on repetitive, predictable tasks, so that people can concentrate on things only people are good at. Another part is allowing people to express their ideas (like code) efficiently -- and this is where different people need technological solutions to behave in different ways.

    <-radiant.matrix->
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet

      Can you post a snapshot or something of that "code outline" feature? My emacs already embeds the debugger, automatic syntax checking/lint/perltidy, autocompletion, and a bit of xref.

      ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

        Autocompletion? What are you using for that?

        Sure thing, a wide screenshot slice will have to do, with Getopt::Long's source loaded in the editor window.

        Folding in Emacs or vim accomplishes much the same thing, so I wouldn't recommend switching to Eclipse for just this one convenience. I haven't been able to get folding working with EPIC (the Eclipse Perl plugin), but I found the mechanism under discussion to do what I wanted folding for. YMMV, of course.

        <-radiant.matrix->
        A collection of thoughts and links from the minds of geeks
        The Code that can be seen is not the true Code
        I haven't found a problem yet that can't be solved by a well-placed trebuchet
Re: Professional Toolkits <=> vim + shell
by Anonymous Monk on Apr 08, 2006 at 00:58 UTC
    vim + screen is all I need to be incredibly productive. I wouldn't think about having more than one vim running at a time either. It handles multiple files with power and ease. Screen affords me the ability to run commands, tail logs, restart servers, all without my hands ever leaving the keyboard. The combination of the two makes me a faster Perl developer than I ever was. I feel sorry for those locked into the mindset that windows-style editors offer ANY value over vim+screen..

      I feel sorry for those locked into the mindset that windows-style editors offer ANY value over vim+screen.

      I feel sorry for those who are so attached to a particular idea that they don't recognize that other ideas have merit.

      Cheers,
      Ovid

      New address of my CGI Course.