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?
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.
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
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.
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.
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
What other reason would a person have for even creating a category named like that, especially with the MS spelled with a $? I think it's pretty clear from the way FOSS types talk to each other what kind of name calling was going on here. If you aren't aware that a stereotypical FOSS characterization of MS stuff and the people people that use their software is negative, perhaps the former won't make as much sense.
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
I can't imagine myself saying that someone is a member of the "M$ Visual Studio category", but if I did the most negative implication would be that he or she might have to climb a steep learning/relearning curve in the process of adopting a new environment. Visual Studio does a lot of stuff, and being without its features could be a significant but temporary hindrance to someone who's spent a long time using nothing else.
Since it's been admitted that "M$ Visual Studio" was intended as a derogation of the craftsman rather than the tool, and I've spoken my piece, I'll just shut up and go away now.
Thanks for your 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...
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.
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 include 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
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 :)
Cheers,
Ovid
New address of my CGI Course.
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
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!
Its not an IDE, but must-have anyways.
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.
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.
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.
It might depend on the power of the language you're using (which, since this is a Perl community, I'd assume is Perl) vs. the power of the tools you have available to use with said language. It would also depend on your individual skill and comfort level with both the language and the tools. See also http://osteele.com/archives/2004/11/ides.
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.
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.
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.
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Autocomplete
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defadvice cperl-indent-command
(around cperl-indent-or-complete)
"Changes \\[cperl-indent-command] so it autocompletes when at the end 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)))
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
(defun my-indent-or-complete ()
(interactive)
(let ((pos (point)))
(indent-command)
(when (and (= pos (point))
(eq last-command 'my-indent-or-complete))
(complete-command))))
See also Hack #5 Autocomplete Perl Identifiers in Vim in Perl Hacks - Tips & Tools For Programming, Debugging, and Surviving by chromatic with Damian Conway and Curtis "Ovid" Poe. That has a nice script for trolling your @INC to make a file of autocompletion candidates. That could be hacked into dabbrev so you'd get better candidates than just "whatever is near or recent."
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
Shoooot. Does your module work well? There might still be a chance to mention your module in a footnote. There's something there but it could use an xref to your module..
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
Further, it looks like your deps, Emacs::EPL doesn't pass tests and Module::Info is missing from CPAN.
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
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.
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
Indeed! In fact, Emacs and vim will use the tags files in a reasonably intelligent manner, making for a pretty nifty code browser. I'd nearly forgotten about it, thanks for the reminder.
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