Java IDEs--benefit or liability? (AUTHOR RESPONSE)

[Brad O'Hearne]

Hello!

First off, I want to thank all of you for your responses to the DevX article
of mine, "10 Reasons to Dump your Java IDE". I originally intended on replying
to each one personally. However, the response has been tremendous: I have
gotten inundated with responses, online and in email, and it is still flowing
in! I have gotten a host of comments, but there were some common themes,
and I quickly realized that it would be better to reply to everyone at once,
where all could benefit from the comments of others.

In sum, the vast majority of the responses were in strong agreement with
the article, which kind of surprised me. The article was the result of a
personal evaluation I went through of using IDE's, the primary catalyst being
integration with team development and choosing an IDE for work. It was very
clear that the article touched a common nerve with many, and that my experience
hadn't been an isolated one. However, there were several points that were
made, that I thought you all would find interesting, that I wanted to quickly
address. The points are listed, with my response below:

1) "I agree with the article, but still need an IDE for debugging."
Response: This is a great point, probably the best one of all. Truth is,
I have developed every day for six months in emacs, and truly haven't needed
it. It hasn't been as convenient, I will admit, but I have compensated by
placing debug code in my programs, and that hasn't been too much trouble.
However, emacs does have an extension called Java Development Environment
for Emacs (JDEE), found at http://jdee.sunsite.dk/, that has an integrated
debugger. JDEE adds some IDE capabilities to Emacs, and it is also free.
There are also some individual debuggers out there too I have heard of.
Perhaps this is one real legitimate complaint about a text editor, however,
it still doesn't outweigh the other issues in my opinion.

2) "I agree with the article, but I need a graphical GUI builder."
Response: Another valid point. However, let me add this. Unless you are
doing very small, insignificant dialogs, I have found almost no code that
a GUI editor produces that I would use as is. Every time I have used a GUI
builder, I have pulled apart the code generated and reworked it to the point
it is nearly unrecognizable, and further, the GUI tool couldn't re-render
it. I have found that GUI-building tools are for prototyping and mock-up,
but beyond that, they are of little use. They generally have tight constraints
on the format of the code it can recognize to visually reproduce the GUI
components, and any changes to the code ends that. Furthermore, most GUI-builders
can't make decisions like reuse of event handlers and the like across common
classes for efficiency...this has to be done by hand.

3) "I agreed with you, until I found (insert IDE name here)."
Response: By far, the number one IDE mentioned was IDEA by IntelliJ. Following
behind that, were Eclipse, and Netbeans. I received such glowing reviews
of IDEA, that I am compelled to check it out. But my primary thought right
now is: I am not experiencing any deficiencies using Emacs...I am right where
I wanted to be, ultra productive with a free, multi-platform, multi-language,
resource-lite, integration-easy editor. Why change? But hey, I'll take
a look anyway.

4) "Prices for computer resources are so cheap, who gives a hoot about resources
or performance? Just go buy a new (insert computer or computer component
here)?"
Response: You all have more money than I do! Seriously though -- I could
write a whole article on this comment alone. It really reflects a dangerous
and kind of lazy attitude some of us developers have adopted, probably due
to being spoiled with the pace of hardware technology improvements, and to
a general acceptance of the expectation of continual hardware upgrading when
a new software product is released (I'm glaring up toward Redmond right now.)
Truth is, this should not be the case, and personally, I don't want to have
to continually upgrade my computer in order to multitask with decent performance.
In general, we should strive to develop software that is lean, not bloated;
and runs well on ours (and our customers) existing hardware. That presents
a real value proposition to the market.

5) (I'm just going to paraphrase this last one) "Visual Studio .NET Rules!"
Response: For most of you, I apologize, but I just had to respond to this.
Truly, it shocked me to read that a few had actually been duped into thinking
that VS .NET supported Java, and further, that J# = Java. I understand that
this article isn't about .NET, but real quickly, here's the scoop: VS .NET
is not cheap, it is very expensive; it is not multi-platform; it does not
provide seamless integration with 3rd party tools; and it does not support
Java. Furthermore, J# is not Java, C# is not Java, nor does Microsoft have
any intention to support Java.

In conclusion, I once again want to thank all of you for your responses.
Regardless of opinion, I found them insightful, and all were greatly appreciated.

Take care,

Brad O'Hearne

[Zane Thomas]

On 11 May 2002 20:03:31 -0800, "Robert Pappas" <rpappas@sound.net> wrote:

>Is the author arguing that I should do my graphics by entering hex values
>into a Bitmap editor?
....
>I think the key to being a Jedi-coder is to not use the IDE as a crutch.

Are you a jedi-coder or aren't you? I make my bitmaps with debug.


--
Turn on, tune in, download.
zane@mvps.org

[Robert Pappas]

I just had one other thought as I sit here doing some graphics work with Adobe
PhotoShop. Graphics tools, like PhotoShop, are IDE's in a way.

And they suffer from almost all of the same problems that the author mentions.
(Cost, learning curves when switching tools, incompatibility, platform dependence,
etc.)

Is the author arguing that I should do my graphics by entering hex values
into a Bitmap editor?

I'm glad the author responded, I liked his comments, but I guess we will
have to agree to disagree on this one, because I know for a fact that a good
IDE can make developers of all skill-levels more productive. Maybe what
we are arguing here is how much of a productivity gain that is, and is it
worth the cost?

I think the key to being a Jedi-coder is to not use the IDE as a crutch.


1) Don't let the IDE be smarter than you. Don't let the IDE do anything
for you that you haven't done at least a few times "the hard way", so that
you know what's really going on.
2) Don't use proprietary IDE features or classes that will make your code
hard to port to another IDE.
3) Don't use an IDE just for the sake of using an IDE. Research what's available,
and test-drive the different offerings, and see how well it will work for
you and your team. If none of the IDE's on the market really rock your world,
then by all means don't use an IDE. For the longest time, the Java community
HASN'T had a better IDE than emacs. I think that's going to change, because
it HAS to, or else 6 million Visual Studio IDE users are going to walk all
over us.

Robert Pappas
rpappas@sound.net

[Rob]

zane@mabry.com (Zane Thomas) wrote:

>Are you a jedi-coder or aren't you? I make my bitmaps with debug.

I wish you used it to write your responses as well, maybe we'd see less of
them

[Greg K.]

Outside of an IDE, I have not been able to hone in multi-threaded consternation
using System.out. How do you figure out threading issues with Emacs? [Note:
I use Emacs-JDE for the majority of my work.] From your response, it sounds
as though you are creating code instead of maintaining someone else's creative
"genius". The UML generating tool within JBuilder, coupled with observable
runtime behavior using the debugger (across multiple threads) has been invaluable
to me in understanding the current design.

Note: If you use Swing and your application is of any complexity, you are
multi-threaded.


Kind Regards,
Greg K.