Firstly you have picked some of the worst tools, VB is an an archaic hybrid, NetBeans hasn't grown up and Visual Studio and its low level tools are so top heavy and complex it needs loads of Wizards to get anything useful done i.e. not good comparisons with Java tools.

Yes IDEs have their quirks, as does all software, even different version of the same software e.g. MS Office, but the effort to learn the goods ones is often worth it, because you can work much faster with an IDE than in a text editor. As with most complex software you often don't have to learn the whole product at once i.e. only learn the stuff you need.

I disagree with some of the comments about IDEs vs editors. Usage of an IDE (e.g., NetBeans) breaks the task into two very separate components: you have to learn the language _and_ you have to learn the IDE. Learning NetBeans or Visual Studio can be every bit as daunting and time-consuming a task as learning the language itself. Pick up any book on learning VB, for example, and you will find most of the text covers using the IDE, not writing code. What's more, learning NetBeans does not mean you know how to use Eclipse or JBuilder efficiently, either. If your company switches IDEs, then you have to start over again and learn the new IDE.

I believe that much is gained from writing in an editor. What is gained is a greater on-the-ground familiarity with the language. Whether you use the (crappy) editor in Visual Studio or emacs, you need to be alert and focussed to accomplish your task. The result of that familiarity is going to be elegance and efficiency in your code, a better understanding of what it is doing and an enhanced ability to critique and debug it.

mp

When the User who doesn't like you polishing the inside of your tin can is given his own IDE that will allow him to wish into being the software he wants then the person that owns that IDE owns him and the rest of us can go off and do other things for a living and for fun.

In the meantime Software Engineering still pays because for some strange entropic reason it still isn't autonomous or trivial.

And of course without a little can polishing we would all still be using Sinclairs.

Knowing when to use an IDE and when not to is similar to knowing when to go to a country doctor, but I figure his advice would be "When it starts hurting, then stop doing it!" :)

I myself prefer to use the tool of choice for a given task and shave with OCKHAM'S RAZOR whenever possible:

``Pluralitas non est ponenda sine neccesitate''
[visit link]

If a tool completely shields you from what it produces (the way a compiler shields you from the bytecode), then you run very little risk in using it. But if you'll be looking at or changing the output (ie, using a code generator or wizard), you had better understand the output.

Bottom line: if a tools helps you manage or create code that you understand, that's great -- you'll save a lot of time, and enjoy building more. But if the tool builds code you couldn't write on your own, code you don't understand, you're headed for trouble.

One of the earliest IDE's I ever used was QuickC 1.0. It was a DOS-based, character-graphics UI. It streamlined the code-compile-test cycle. It had a built-in graphical debugger with breakpoints. It had context-sensitive help with a C manual for the language and runtime library (plus Microsoft's proprietary libraries). The text editor was pretty decent and supported multiple files within the main frame. It generated the make file for your project. Primitive by today's standards, but definitely helpful to beginner and more experienced C programmers. I was glad to have it available.
As a consultant, I often found myself in shops that provided nothing more than vi and a C compiler (or for Oracle development, sqlplusw and notepad). If that's all you have, then you have to be competent in that environment. So you build your own toolbelt of useful utilities, and take them along with you from gig to gig.

So don't use the wizards to generate code, do it manually (in an IDE), IDE's still allow manual coding, but are often more helpful on the little useful bits than a text editor. As for cost, lots of the IDEs are free, and commercial IDEs have always had evaluation and/or licenced beginner/foundation (free) versions available.

One key benefit of good IDEs is that they integrate support for the JavaDocs (very useful, especially for beginners) e.g. you can highlight a class, property or method name in JBuilder *, press F1 and up pops the relevant JavaDocs page.

* Jbuilder even supports JavaDocs lookup for any external libaries associate with a project, provided the library directory/zip/jar contains the JavaDocs (or is told where to find them). I've used this feature a lot with Apache.org Java libraries e.g. Log4J, RegExp, ORO etc...., and the www.exolab.com castor XML libary. IMHO there are too many libaries to understand/memorise, so it's better to have fast efficent lookup.

(1)As a rank beginner I found it the generated code confusing. I wanted to learn to build a simple application from scratch. Once I understood the skeleton and the basic parts I am willing to switch to a fancy IDE. If you don't have some idea about what is under the covers you will be lost without your fancy IDE.
(2) When I was not on an official project, and before so much open source was available fancy IDE cost money and therefore were not available. I certainly did not have them at home. If I wanted to try out the new stuff I had to use the available tools. Tutorials that only told me where to click in their IDE did not teach me how to code.

I've used both emacs and vi in the past when I had nothing better, but I quickly jumped when the more capable/powerful editor Cygnus-Ed became available on the Amiga (with AREXX automation support).

I now use Borland JBuilder (on Windows) because it works, has lots of genuinely time saving features (e.g. refactoring, drop-down method lists etc., serious build and library support, switchable JDK support etc....) and can easily be extended e.g. I have a custom project menu to run a Java class to build castor XML classes from specific XSD's. No stupid key combos to remember and all the complex stuff is automated, it just works.

I have had to go back to using make for some legacy DOS C work and damn is painful, ant is just a java XML version of this, IMHO extensible IDE project files are so much easier. I don't want some kludge on an ancient editors, which needs any kind of make like script, it's just nasty.

BTW I tried Eclipse, it had some interesting features, but just seemed glued together, not really an integrated experience, IMHO JBuilder does it better.

I have worked with excellent developers of either type - some that wanted to have everything done in Emacs and some that were really fond of their chosen IDE. So I agree to let everybody choose the tools that make them most productive.

Regarding the pride in "having done it the hard way" - there is also some learning aspect to it. Yes, you can quickly assemble a GUI using some IDEs. But to really understand what the underlying API offers and to be able to think about a problem in the way of the used framework I would advice everybody to handcraft a non-trivial GUI at least once.
For me the learning effect is much higher than clicking and dragging around elements.
After I know what I am working with I can still benefit from the GUI builder in future projects. And I am less likely to be lost when I hit the limits of the tool.

Well, it depends upon what your priorities are when coding. IDE's offer great visual building tools. However, their text editing is usually rudimentary at best -- just the basics.

With Emacs I have to code the visual interface from scratch. On the other hand, I can do in a couple of keystrokes editing tasks that would be very difficult to do in any IDE I've yet worked with.

Emacs also:
1. Is cross-platform.
2. Is open source -- there's no vendor to abandon it when the VCs pull their funding.
3. Knows about a LOT of different languages, and has custom modes that add powerful tools for that particular language to the editor -- seamlessly.
4. Is highly customizable.

What I want is an IDE that offers the above advantages. Emacs has its drawbacks, and I've been looking for a good replacement for some time. I haven't found it yet. However, I think Eclipse just might get there, at least if you've got lots of memory to burn.

To attempt to disqualify a writer's opinion and the questions he brings solely becauses he writes IDE's for a living is as limited and short sighted as either using only IDE's for coding or using only the text editors out there.

There are generally two types of people that I have worked with in development over the past seven years: Those whose primary purpose and excitement in their job is evangelizing (either about the newest IDE, or about how open-source is pure, or about the only way to code is through a simple editor, et. al), and those whose primary excitement is designing and developing an extensible, maintainable system regardless of those factors.

The fact is, elegant and maintainable systems can be developed with nearly any language, technology, editor or IDE. The ability to MacGyver a system in extreme situations is quite admirable; however, the gunslinger mentality that the idolization of those abilities promotes is generally destructive to software development teams and the building and maintenance of actual business applications. This is also the gist from what I took from Mr. Winchester's article. And I agree.

So, my attitude is this: use whatever tools make you, as a developer, the most productive -- if you use a hand-router better than you use a powered router because you feel like you make fewer mistakes and that this makes your overall productivity better, then go to it. And if you use the powered router, knowing that you'll have to incorporate mistake-fixing time into your equation, and THAT improves your productivity, then more power to you (pun intended). But don't cast aspersions on the other camp just because they are in the other camp.

Be open to using the tools that improve your development productivity and help your clients produce their business applications. Be a solutions provider, not a solutions evangelist.

My two pennies,
Mark Kaiser

There are great programmers. There are programmers that want you to think they are great. Then there are those that write articles complaining about them. Over time, market factors will determine who is 'great' and who is outsourced. How they get themselves there is their concern - unless you write IDE's for a living.

Funny how this "IDEs are superior; people who use vi/Emacs are Luddites" position is always advanced by people with an IDE that they want other people to use. I've never heard of anyone who gave up Emacs for an IDE and then began evangelizing for it.

The simple truth is that real programmers (those with long-term experience) realize that IDEs are bad news for any number of reasons. Proprietary IDEs come and go, and woe unto you who have your project locked into their proprietary file formats when they go. (I could make a museum of old Java IDEs that died horrible deaths.) Most IDEs are exceptionally clumsy, getting in the way of a competent programmer who knows what to do and is trying to get it done, with clumsy interfaces, confusing UIs, etc. IDEs frequently don't work as advertised (a main reason why I don't bother with them anymore), crashing and having all sorts of errors.

Emacs will be around forever because (1) it is stable and works great, and (2) it can be adapted to whatever new language/fad/tool that comes along.

Every tool has a cost as well as a benifit. While I agree that using ancient tools is not necessarily good, using modern tools has a cost of it's own.

How many amoung use have used MS visual design tools and have spent hours moving fields around or scratching our head because it is acting in a way that makes no sense, or done something really strange because the design tool doesn't allow what we need to do. So the argument that the tools are implicitly better doesn't hold water in many cases and you often don't know which track is better (at least small apps) for an application until after it is behind schedule.

Additionally, the people that learned on the new tools are just as arrogant about the new tools.

Like it or not coding is in many ways a social activity and the best programmers require an arrogance to be any good, just like golfers or chess masters. The arrogance is gained by being good at something that is hard to do. The challenge to the developer community and the tool developers is evolve the tools, keep the arrogance and move the community forward.

Hey back when I was still in school I took a PT job writing BASIC on the old IBM System/23 (the granddaddy of the PC). Painting the edit forms fields on screen was a trial-and-error chore. So I wrote a program that let me enter screen coordinates and field length from a command line, then drew the field for me. Once I had the screen painted the way I wanted, the program dumped all the field info to a file. This then became the skeleton of my form application. This relatively simple tool saved me hours of drudgework.

At another company, my boss asked me to write queries to exercise all the indexes for a table. We were trying to identify corrupt indexes. Each table had anywhere from 4 to 16 indexes. She wanted this done for 6 tables. So I thought to myself, I could spend the next 4 hours devising the SQL for one of the tables; or I could write a generator to create the SQL for me. While challenging, once developed, it took just seconds to generate all of the SQL needed. I dumped the query code to a script, kicked it off, and went home.