Java IDEs--benefit or liability? (AUTHOR RESPONSE)
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
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.
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL