Fog Creek Software
Discussion Board

IDE's--Are they a crutch or a valuable tool?

What do you guys think. I've stayed away from them, but then again, I don't ever do front end Windows programming.  (i've done a little for fun, but nothing advanced or tedious).  Some of the guys at my work are using really expensive stuff, mostly for java develoment.  Am I hindering myself by not using them? Or am I building a greater understanding of how to actually code? Maybe i'm just lazy :-P
what do you guys think? 

Vincent Marquez
Wednesday, July 31, 2002

You need to be extremely familiar with what's going on with the IDE (ie, generated code templates, etc) in order to be most effective. 

That said, you can be more effective than you otherwise would be without the IDE.  For example, I didn't know much about X Windows (back in the day), but I was able to get some X apps up and running pretty fast because of Builder's Xcessory's IDE.  So it can make an ignorant programmer better, but it's not gonna make an OK programmer great.

Wednesday, July 31, 2002

Typical Alyoshan' unhelpful response below:

It depends on the IDE and the proficiency of the user.  To make a blanket statement: if you know what's going on under the hood, they're a crutch; if you do know what's going on under the hood, they're a tool.

The fact that is nearly impossible to do write COM controls in C++ without ATL and the wizards either proves the usefulness of IDEs or the perversity of COM -- I'm not sure which.

I like source-level integrated debugging.  A LOT.  I'm not much of an editor bigot, I'm not a big user of gee-whiz editor featuresets, so the editors of most IDEs are fine with me.  Builds are another problem -- I don't like how VC++ does builds.  The IDE generates .mk files for you, but I'm always afraid in a multiuser development environment of clobbering the makefile or (if the makefile is checked in and read-only) getting my IDE settings out of sync with the directives of the makefile.  It's just simpler to go to the commandline and type nmake instead of worrying about all that.

I wouldn't worry about it too much, but I would peek over the shoulders of your coworkers once in a while and just watch their workflow and see if there's anything really *USEFUL* that you like about their IDEs that you can't do from the command line.

Wednesday, July 31, 2002

It's been traditional for IDEs to differentiate themselves by how much of your day to day coding they can automate, with an ever increasing arms race of wizards, visual designers etc. I've got to say I've never been a fan of these sorts of tools, and most of the projects I've seen built using them are a bit of a mess at the source code level.

Luckily there are some saner options. I really don't know what I'd do without IntelliJ IDEA for instance - and if you're a Java developer I recommend checking it out. The cool thing about it is that it's about helping me write code, rather than writing it for me - I'm at the controls the whole time, but the environment has a lot of knowledge about what I'm working on that I can make use of when necessary.

Eclipse seems to be heading along similar lines, and is also well worth looking at.

Mark Allerton
Wednesday, July 31, 2002

The big advantage of IDEs are the little time savings for common tasks that come from the IDE knowing how the compiler, debugger, version control etc. work.

For example, it's a huge productivity boost to be able to do the following:

* click on a compiler error message and go straight to that line.
* click on a function/variable and go straight to its definition.
* click on a function and go straight to its online help/man page etc.
* click on a file and check it out/in, view differences, history etc.

These are tasks you probably do hundreds of times a day. If they're just one click faster each the cumulative time savings are significant.

Andrew Reid
Wednesday, July 31, 2002

Not to mention (in more recent IDEs)

+ pop-up dialogs that help you fill in method arguments.
+ while-you-type syntax checking.
+ edit-and-continue that lets you change code while debugging.
+ automatically indenting / ballencing parens, and so on.

I think the original question was more about the kind of IDE (like Visual Basic or Delphi) that writes code for you. If you're stuck using a library or programming language that has required lots of boiler-plate code to work, a good code-generating IDE is usually very helpful.

But take COM as an example: rather than use a boilerplate-generating IDE, you might be better off switching languages, to C#, where most of the uglyness is taken care of for you by the language runtime.

John Palevich
Wednesday, July 31, 2002

I second the IntelliJ reccomendation.

I used vi to code in C/C++ and java for almost 10 years.  I argued that because I was good with vi that I was more productive in it.

I was wrong.  Creating getters and setters for me is very nice.  Keystrokes bring up java docs, take me to parent classes, autocomplete interators or method names, etc.  Get good with an IDE, you'll be a better coder.

On a related topic, my brother is a licensed electrician.  He knows things about electrical codes that enabled him to pass the test in two states.  However, it takes more than that be effective.  If he tried to use a drywall saw to cut the hole, strip the wire, screw in the receptical, and finally screw in the plate he would be terrible.

He needs to be knowledgable and competant with his tools.  It seems to me that a lot of programmers think their knowledge is their value and competance with tools isn't required.  Yeah, you can make do with just a saw but you'll be better at your job if you master the right tools.

Thursday, August 01, 2002

I can't see how one really make software without one.

They integrate help, references to syntax, and of course auto complete code.

In PeopleWare the studies showed that the programming language used does not make a difference in the amount of time taken to solve a problem.

While the above may be true, and a good COBAL programmer will run circles around a poor C++ coder, I think the difference in the real world is that we solve problems AND create interface. Hence, the real issue here is the IDE and the user interface. This is something that has not been really studied...but the results are obvious. Good tools allow you to create a better user interface in less time.

Once one gets beyond the actual algorithm to be used, then most of the work is interface stuff today. With a good IDE, then all of the interface stuff is essentially like using a  paint program. In this regards I can’t imagine coding data entry screens via hand. I did write some commercial applications for green screen stuff in Pascal. However, it was a very short time and I started using 4th gl tools to create the data entry screens. On those systems that I did not have a user screen creator, I made my own.

Just the other day I was traveling on a plane, and the fellow beside me was a hard core Unix C developer (on his way to a AI conference being held in my City). He currently codes his html by hand. I was stunned. How can one possibly have any productive use of hand coded HTML today? For sure some teaks and lean mean HTML code must be done by hand. Of course this person is from Academia, and the idea that consumer wants affordable web content is not a issue with such people. This person also does not need to write or use graphical interface code for his work also. If you are a commercial operation, you don’t create web sites by hand anymore with EMACS. That may have been the case 5 years ago..but not today! (not even close!). There is nothing wrong with hand coded HTML except that it is not commercially viable today.

The other thing to be aware of is that a IDE is not just a IDE. What is the IDE created for? The old saying about using the right tool for the right job rings true here? Just what is the IDE for?

While VB is a general IDE, ms-access can create a typical business software application in 1/3 the time * I F * you are talking about a application that deals with data. If this was not the case, then the market for database products (and the IDE’s they have) would not exist. The same goes for Auto Cad (there are people who develop applications in Auto Cad!).

Hence, a job costing program in VB that costs $36,000 can be done in ms-access for $12,000. By choosing the right tool you can save big bucks, and the results are much better. Note that ms-access uses the same programming language as VB, but is wrapped in a set of tools designed for data management. Since the prgramming language used in ms-access is the same as VB, then the large differance is due to the different object model and the tools in the ms-access IDE.

So, the real question is not should one use a IDE, but to use the right IDE for what task becomes the real important question.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Thursday, August 01, 2002

I like the RAD parts of the IDE, not for generating production code but as a learning tool. Looking at what code is generated can be very intersting when you are new to a system.

Just me (Sir to you)
Thursday, August 01, 2002

I think The Pramatic Programmer sums it up best:

The basic rule is Do Not Use Wizard Code You Do Not Understand.

Ged Byrne
Thursday, August 01, 2002

Not all IDEs with visual tools are code generators.

Apple's Cocoa tools do have the ability to generate a small amount of code, but it really is a *small* amount of code.  (Variable declarations for object outlets and method stubs for object actions, and then only when you're creating a new class from within Interface Builder.)  Otherwise, everything is done by creating descriptions of object graphs that are read in, instantiated, and wired up automatically at run time.

NeXT designed them this way because they recognized that code generation was extremely fragile, and because their frameworks were based on a dynamic language that made such things really easy.

Metrowerks CodeWarrior on the Macintosh is a great IDE, and it also isn't a code generator.  Its purpose in life is to get out of your way so you can code faster.  It has niceties like a class browser, ready access to documentation, autocompletion (in the latest version), etc.  Constructor, the visual layout tool that works with the PowerPlant framework -- both included with CodeWarrior -- also generates object graph descriptions.  Wiring them up requires writing code, unlike Cocoa (which does it for you in the framework), but it's fairly simple and straightforward to do so.

Really, I can't fathom developing an application with a high-quality human interface any way *but* visually.  And I also can't imagine using visual design tools that turn out reams of awful, fragile, hard-to-maintain code.

"The best line of code is the one you didn't have to write."

Chris Hanson
Thursday, August 01, 2002

"you might be better off switching languages, to C#, where most of the uglyness is taken care of for you by the language runtime. "

Personally I prefer compiler time checking instead of runtime... runtime checking will only extend your testing requirements.

"In PeopleWare the studies showed that the programming language used does not make a difference in the amount of time taken to solve a problem. "

Well... DUH!

"The basic rule is Do Not Use Wizard Code You Do Not Understand"


"The best line of code is the one you didn't have to write. "

Contradictions abound... don't they (laughing)

Think about this... you are talking about "means", not "ends".

Which is more important to you? 

Joe AA
Sunday, August 04, 2002

All this has to be taken with a grain of salt!

In the comment from Peoplware about the language not making a difference...well that is to solve a problem. The issue to day, is also one of creating the interface, and in that regards one cannot ignore the IDE. Hence, ok the language used is not that important, but a IDE that lets you visually create a screen and manage connections to a database is certainly going to make a *huge* difference!

A general test to create some algorithm or solve a complicated problem via code will not likely take too much difference if you are using a plain vanilla open source “C” compiler, or Visual Studio and C++, or even Pascal, or even Cobol.

However, when you starting taking about a interface to a database, or a user interface, then those times will DRAMATICLY vary. In that case, the IDE will make a dramatic difference! The same goes for using some advanced report generator tools.  Lets not confuse general coding with windows application development here.

Also, (as mentioned) a lot of wizards don’t necessary create code, but just fill in available options for you. The combo box wizard in ms-access is great example. On occasions it *does* write code,  but in many cases it does not (it just sets up the SQL statement for you, and also the number of columns to display for the combo box). It also lets one “size” the columns visibly. (again, this is not a code thing).

Hence, we can’t just make up (or agree with) some hard and fast rules here. It don’t work that way. So, when someone says:

    Don’t use a wizard!

I can’t buy that. In fact, I will not buy that! (especially in those cases where the wizard does not write code!).

However, there really is (was) some good points made as to why you should not use a wizard, and the pitfalls of using one. At the very least lets be open to some of the downsides. (the comments and links made in this regards were just fantastic!).

Are things like inteli-sense a crutch?...hum..for me they are..but I still love em!

I cannot even tell you what the parms are for the VB msgbox right now (actually, the first parm is the text....after that it is inteli-sense time!).

This is due to the fact that intel-sense has spoiled me (or most likely completely rotted by brain!). This is actually very terrible. Now when I write vbscripts to automate my applications (batch files), I have to fire up a IDE so that I can jog my brain. I can’t seem to remember any vb commands now! (and thus I find writing vbScript very hard).  In pick/d3 I could remember commands like:

Locate(MyRec,strSearch,Amc,Vmc;WhereFound;”AR”) then

The above has 6 parms, and I can explain every one of them. I have not used that Locate command for probably more than a year. I don’t have inteli-sense in Pick, and thus had to remember!

I can only say that if you are doing a repetitive task, then try and figure out a way to automate that task you are doing over and over. I think this what a good IDE, and a good set of wizards can do.

These great tools can help...but boy they sure can make the brain lazy!

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, August 05, 2002

I get paid to code Java, and I recently tried to use the Netbeans IDE [1] for everything. It was sometimes pleasant, but overall it just didn't agree with me and I went back to emacs. (I wrote about this elsewhere a little more.[2])

Automation is certainly one of the things that IDEs give you. But IDEs are not the only way to achive automation. In fact, most IDE automation capabilities are quite simple and can be replaced -- and greatly enhanced! -- by your favorite lightweight scripting language.

I have nothing against IDEs -- I am happy to accept that for many people IDEs enhance productivity. Just not for me :-) I think we frequently get caught up in the false dichotomy specified in the forum title, which is a shame.


Chris Winters
Monday, August 05, 2002

*  Recent Topics

*  Fog Creek Home