in reply to Professional Toolkits <=> vim + shell

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
  • Comment on Re: Professional Toolkits <=> vim + shell

Replies are listed 'Best First'.
Re^2: Professional Toolkits <=> vim + shell
by diotalevi (Canon) on Apr 13, 2006 at 18:50 UTC

    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.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
      Autocompletion? What are you using for that?
[reply]
        ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;                 Autocomplete
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defadvice cperl-indent-command
  (around cperl-indent-or-complete)
  "Changes \\[cperl-indent-command] so it autocompletes when at the en
+d of a word."
  (if (looking-at "\\>")
      (dabbrev-expand nil)
    ad-do-it))
(defun cperl-dabbrev-installer ()
  (set (make-local-variable 'dabbrev-case-fold-search) nil)
  (set (make-local-variable 'dabbrev-case-replace) nil))
(eval-after-load "cperl-mode"
  '(progn
     (require 'dabbrev)
     (ad-activate 'cperl-indent-command)
     (add-hook 'cperl-mode-hook #'cperl-dabbrev-installer)))

        [download]

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
[d/l]

      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
[reply]
        People often overlook ctags, but it render more or less the same service with almost any existing editor.
[reply]

In Section Meditations