Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Nigel Wade Newsgroups: comp.lang.java.help Subject: Re: Whay IDE am I supposed to use/is the best? Date: Wed, 04 Jul 2012 09:26:26 +0100 Lines: 47 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net u+eTlhkhrXmmH90oeqm7GQGXrZg2jzxf6cpxVLGmUcfJbEzhvKM98nDWkQGGi33I8n Cancel-Lock: sha1:PIs2/f9ovXJtUq/Ri2QhSzGd3BQ= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 In-Reply-To: Xref: csiph.com comp.lang.java.help:1934 On 04/07/12 03:55, Patricia Shanahan wrote: > On 7/3/2012 5:48 PM, Patrick May wrote: > ... >> I do think there is value in simplicity (and yes, I do see the >> humor in calling Emacs simple). I also think there is value in >> understanding what your tools are doing, and many IDEs make that >> difficult or impossible. It is possible to deliver large enterprise >> projects using a programmer's editor like Emacs and a shell window or >> three, with occasional reference to documents in a web browser. > > Why is understanding what your tools are doing such a good thing? And is > it feasible, even if desirable? Because if you don't, how are you going to clean up the mess that the tools generate when they go wrong? > > Computing advances by making details irrelevant, and letting people > focus on bigger issues. Even the simplest of program editors, let alone > a tool like emacs, hides many layers from its users. > The more all-encompassing the tool becomes, the greater the potential for disaster when they go wrong. The more they hide from the user the less able the user is to fix the mess that the "tool" creates when it does go wrong. Just recently I decided to try the latest Netbeans (7.1), having used Netbeans 6.x for some years. When I attempted to open one of my applications (which I have been developing for over a year in Netbenas 6) and perform a clean-and-build it failed, throwing up errors in build-impl.xml. This file is internal to Netbeans, created and maintained entirely by the Netbeans. There is no user involvement in its operation at all, so the "tool" provides no mechanism or assistance in fixing the problem that the "tool" has generated. I now had an application which would not build in Netbeans 7.1 because Netbeans had screwed up its own internal files. There was no mechanism provided by Netbeans to help clean up the mess. Furthermore, in attempting to convert its own files from 6.9 to 7.1 it had rendered the files no longer usable by Netbeans 6.9. So, the upshot was that I could no longer build my application. What is this "bigger issue" which I should have been focusing on? -- Nigel Wade