|laziness, impatience, and hubris|
Re: Editor / IDE Consolidationby sauoq (Abbot)
|on Aug 27, 2002 at 01:24 UTC||Need Help??|
I don't know how this thread has gone on this long here without a single mention of vile! Vi Like Emacs can be built with an embedded perl interpreter on Unix and Win32. (That's according to the README. I can only vouch for the Unix half of that claim.)
And don't you just love the self-referential name?
Ok. That said, I have a few comments...
Skill level plays a big part in choosing an editor. Pico might be a great editor for a beginner who wants to jump right in and start coding without taking the time to learn a particular editor's peculiarities but it isn't too good for someone who is debugging a program composed of several large files.
Regarding builtin support for revision control, I agree with you in principle. Where I disagree is your defense of those who don't add the support. You said it would be: time consuming and difficult to add support for the numerous revision control systems that are available. Yes but the makers of IDEs wouldn't be expected to do so. IDEs include an editor, sometimes a debugger, sometimes a compiler, etc. Why not include a proprietary revision control system as well?
I'm probably failing miserably but I'm attempting to use irony to make the same point that I did in that node of mine that you referenced. The problem with IDEs is that they are tightly integrated. What if you want the editor from Visual Slick Editor and Komodo's debugger? If you can do it, you probably can't do it easily, and even if it isn't too hard, it's probably a waste of resources to have them both running at once.
There is real merit to using separate programs for separate tasks. The concept of an IDE is probably a result of false hubris. Somewhere along the line someone got a little carried away with abstracting and decided that writing software was a distinct enough task that there should be a separate program. But developing is a combination of many tasks: writing, compiling, linking, debugging, testing, profiling, controlling revisions, etc. It makes sense to be able to pick and choose different tools for each of those tasks.
I like knowing that if a better compiler comes out next year I won't have to learn another editor before I can use it. Or if a better editor comes out next week, I won't have to switch to a different debugger to stay efficient.
These principles are a core part of the philosophy from which Unix was born. Cygwin is a port of much of this wisdom to the Windows platform. I highly recommend that anyone thinking about their ideal development environment consider the issues these platforms address.
If you want integration try to make things integratable. Lego™ blocks are small and integratable. They wouldn't be much fun if they all came glued together.
-sauoq "My two cents aren't worth a dime.";