Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #1916 > unrolled thread

Whay IDE am I supposed to use/is the best?

Back to article view | Back to comp.lang.java.help

Contents

  Whay IDE am I supposed to use/is the best? ericmiranda7@gmail.com - 2012-06-30 23:32 -0700
    Re: Whay IDE am I supposed to use/is the best? Lew <noone@lewscanon.com> - 2012-07-01 03:53 -0700
    Re: Whay IDE am I supposed to use/is the best? Roedy Green <see_website@mindprod.com.invalid> - 2012-07-01 07:37 -0700
    Re: Whay IDE am I supposed to use/is the best? Patrick May <patrick@softwarematters.org> - 2012-07-01 14:20 -0400
      Re: Whay IDE am I supposed to use/is the best? Lew <noone@lewscanon.com> - 2012-07-01 14:44 -0700
        Re: Whay IDE am I supposed to use/is the best? Patrick May <patrick@softwarematters.org> - 2012-07-03 20:48 -0400
          Re: Whay IDE am I supposed to use/is the best? Patricia Shanahan <pats@acm.org> - 2012-07-03 19:55 -0700
            Re: Whay IDE am I supposed to use/is the best? Nigel Wade <nmw@ion.le.ac.uk> - 2012-07-04 09:26 +0100
              Re: Whay IDE am I supposed to use/is the best? Patrick May <patrick@softwarematters.org> - 2012-07-05 13:36 -0400
                Re: Whay IDE am I supposed to use/is the best? Gene Wirchenko <genew@ocis.net> - 2012-07-05 13:25 -0700
                Re: Whay IDE am I supposed to use/is the best? Joseph Parkton <jparkton@gmail.com> - 2012-07-19 21:54 -0700
            Re: Whay IDE am I supposed to use/is the best? Gene Wirchenko <genew@ocis.net> - 2012-07-04 10:04 -0700
              Re: Whay IDE am I supposed to use/is the best? Patricia Shanahan <pats@acm.org> - 2012-07-04 10:14 -0700
                Re: Whay IDE am I supposed to use/is the best? Gene Wirchenko <genew@ocis.net> - 2012-07-04 10:47 -0700
                  Re: Whay IDE am I supposed to use/is the best? Patricia Shanahan <pats@acm.org> - 2012-07-04 12:32 -0700
                    Re: Whay IDE am I supposed to use/is the best? Gene Wirchenko <genew@ocis.net> - 2012-07-04 13:01 -0700
                      Re: Whay IDE am I supposed to use/is the best? Lew <noone@lewscanon.com> - 2012-07-04 16:03 -0700
                        Re: Whay IDE am I supposed to use/is the best? Gene Wirchenko <genew@ocis.net> - 2012-07-04 17:38 -0700
                        Re: Whay IDE am I supposed to use/is the best? Patricia Shanahan <pats@acm.org> - 2012-07-06 08:29 -0700
    Re: Whay IDE am I supposed to use/is the best? Timothy Madden <terminatorul@gmail.com> - 2012-08-21 16:21 +0300
      Re: Whay IDE am I supposed to use/is the best? Lew <lewbloch@gmail.com> - 2012-08-21 11:47 -0700

Page 1 of 2  [1] 2  Next page →

#1916 — Whay IDE am I supposed to use/is the best?

I've heard about Jcreator and eclipse.. which ide would be the best?

[toc] | [next] | [standalone]

#1917

ericmiranda7@gmail.com wrote:
> I've heard about Jcreator and eclipse.. which ide would be the best?

"Best" is a subjective term, so I don't know what's best for you.

I do know that NetBeans and Eclipse are two very fine free IDEs.

IntelliJ is highly recommended by many Java developers.

Eclipse and customized versions thereof tend to be standard in the workplace.

Personally I like NetBeans, for some of the things that have other people 
prefer Eclipse, I suppose. I keep both around anyway.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#1918

On Sat, 30 Jun 2012 23:32:27 -0700 (PDT), ericmiranda7@gmail.com
wrote, quoted or indirectly quoted someone who said :

>I've heard about Jcreator and eclipse.. which ide would be the best?
 see http://mindprod.com/jgloss/ide.html for some notes.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#1927

ericmiranda7@gmail.com writes:

> I've heard about Jcreator and eclipse.. which ide would be the best?

     Emacs, of course.

HTH,

Patrick

------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation.  (C++, Java, Common Lisp, Jini, middleware, SOA)

[toc] | [prev] | [next] | [standalone]

#1928

Patrick May wrote:
> ericmiranda7@gmail.com writes:
>
>> I've heard about Jcreator and eclipse.. which ide would be the best?
>
>       Emacs, of course.
>
> HTH,

Eric,

Patrick is being mostly humorous here.

Emacs is an excellent programmer's editor, and for many languages, IDE, albeit 
not to everyone's taste.

However, for Java and JVM languages the particular Java-based IDEs tend to be 
superior on a pragmatic basis. They are more than just Integrated Development 
Environments, the "IDE" of "IDE", but full application platforms in their own 
right. As presented, both Eclipse and NetBeans provide not only Java language 
tools like debugging and syntax checking, templates for types and methods, 
yada yada, but dashboards for associated resources like databases, web 
servers, application servers (Tomcat, Glassfish, Geronimo, JBoss, ...) and 
much, much more.

Now how much would you pay? Well, they've slashed the price 50% - formerly 
free, now these downloads will cost you nothing.

Even when the raw product doesn't support exactly what you want, you can often 
find a companion for the IDE that does, either via a plugin or a full product 
atop the underlying platform. Aptana, for example, does both for terminal- and 
web-based HTML, CSS, JavaScript, PHP, Ruby, RoR and HTML5 programming. They 
built their open-source platform atop Eclipse. Consequently you can also use 
it for Java, C++ and the panoply of other things Eclipse already does. I'm not 
aware of a corresponding product built atop NetBeans, but there are a lot of 
products that do build on that equivalently flexible platform. (NetBeans 
already does Java, C/C++, PHP and Groovy.) There are plugins for things like 
Ruby on Rails and so on.

Check out the respective sites and decide for yourself.
In no particular order:

<http://www.eclipse.org/>
<http://netbeans.org/>
<http://www.gnu.org/software/emacs/>
<http://www.aptana.com/>

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#1932

Lew <noone@lewscanon.com> writes:

> Patrick May wrote:
>> ericmiranda7@gmail.com writes:
>>
>>> I've heard about Jcreator and eclipse.. which ide would be the best?
>>
>>       Emacs, of course.
>>
>> HTH,
>
> Eric,
>
> Patrick is being mostly humorous here.

     Only mostly.  http://catb.org/jargon/html/H/ha-ha-only-serious.html

     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.

     I would encourage the original poster to understand the costs as
well as the benefits of his or her tool choice.

Regards,

Patrick

------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation.  (C++, Java, Common Lisp, Jini, middleware, SOA)

[toc] | [prev] | [next] | [standalone]

#1933

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?

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.

Patricia

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#1942

Nigel Wade <nmw@ion.le.ac.uk> writes:
> 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?

     Exactly this.  There is a difference between encapsulating
complexity and merely concealing it.  Too many IDEs, in my experience,
do the latter.  This causes problems both when the tools are upgraded
and when different tools are used on the same project.

     I've seen a lot of time wasted by developers getting their IDEs
configured when those of us using Emacs or vi were solving the actual
business problem.  I've also seen too many junior developers who don't
understand what their IDE is actually doing under the covers, which
means they aren't a Java programmer, they're an Eclipse programmer.

     I'd rather work with people who understand how to use the command
line, even if they choose to use an IDE.

Patrick

------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation.  (C++, Java, Common Lisp, Jini, middleware, SOA)

[toc] | [prev] | [next] | [standalone]

#1943

On Thu, 05 Jul 2012 13:36:56 -0400, Patrick May
<patrick@softwarematters.org> wrote:

>Nigel Wade <nmw@ion.le.ac.uk> writes:

[snip]

>> Because if you don't, how are you going to clean up the mess that the
>> tools generate when they go wrong?
>
>     Exactly this.  There is a difference between encapsulating
>complexity and merely concealing it.  Too many IDEs, in my experience,
>do the latter.  This causes problems both when the tools are upgraded
>and when different tools are used on the same project.

     I like tools that tell you what the underlying commands are.
Every so often, the IDE might not be able to handle something, and it
is good to know the basics of the underlying commands.  Then, you have
a chance.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#1951

>      Exactly this.  There is a difference between encapsulating
> complexity and merely concealing it.  Too many IDEs, in my experience,
> do the latter.  This causes problems both when the tools are upgraded
> and when different tools are used on the same project.
> 
>      I've seen a lot of time wasted by developers getting their IDEs
> configured when those of us using Emacs or vi were solving the actual
> business problem.  I've also seen too many junior developers who don't
> understand what their IDE is actually doing under the covers, which
> means they aren't a Java programmer, they're an Eclipse programmer.
> 
>      I'd rather work with people who understand how to use the command
> line, even if they choose to use an IDE.
> 
> Patrick
> 
> ------------------------------------------------------------------------
> http://www.softwarematters.org
> Large scale, mission-critical, distributed OO systems design and
> implementation.  (C++, Java, Common Lisp, Jini, middleware, SOA)

Absolutely, IMHO you should be totally comfortable working in CLI and IDE both have their merits and downfalls. 

[toc] | [prev] | [next] | [standalone]

#1935

On Tue, 03 Jul 2012 19:55:11 -0700, Patricia Shanahan <pats@acm.org>
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?

     Knowing something of the layer below (or even more) can help one
get more out of the system.  If you insist on using black boxes and
keeping it that way, then you do not understand the system.

     It is practical.  I am claiming that one needs to know
everything, but knowing that bit more can make a difference.

>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.

     Of course, but some of these layers can be useful to understand
about.  Nigel gives good examples in his post.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#1936

On 7/4/2012 10:04 AM, Gene Wirchenko wrote:
...
>       Knowing something of the layer below (or even more) can help one
> get more out of the system.  If you insist on using black boxes and
> keeping it that way, then you do not understand the system.
...

I've treated emacs and other tools as black boxes on systems I
understood at every level down to details of the processor design.

Patricia

[toc] | [prev] | [next] | [standalone]

#1937

On Wed, 04 Jul 2012 10:14:54 -0700, Patricia Shanahan <pats@acm.org>
wrote:

>On 7/4/2012 10:04 AM, Gene Wirchenko wrote:
>...
>>       Knowing something of the layer below (or even more) can help one
>> get more out of the system.  If you insist on using black boxes and
>> keeping it that way, then you do not understand the system.
>...
>
>I've treated emacs and other tools as black boxes on systems I
>understood at every level down to details of the processor design.

     If you know the system to that level, it is not a black box.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#1938

On 7/4/2012 10:47 AM, Gene Wirchenko wrote:
> On Wed, 04 Jul 2012 10:14:54 -0700, Patricia Shanahan <pats@acm.org>
> wrote:
>
>> On 7/4/2012 10:04 AM, Gene Wirchenko wrote:
>> ...
>>>        Knowing something of the layer below (or even more) can help one
>>> get more out of the system.  If you insist on using black boxes and
>>> keeping it that way, then you do not understand the system.
>> ...
>>
>> I've treated emacs and other tools as black boxes on systems I
>> understood at every level down to details of the processor design.
>
>       If you know the system to that level, it is not a black box.

If you define "black box" in such a way that it is not possible to treat
something as a black box even if one understands the system, then "If
you insist on using black boxes and keeping it that way, then you do not
understand the system." is indeed a tautology.

I prefer a more functional view of "black box" in which one can treat
something as a black box by only considering and using its external
features, regardless of deeper understanding.

Patricia

[toc] | [prev] | [next] | [standalone]

#1939

On Wed, 04 Jul 2012 12:32:58 -0700, Patricia Shanahan <pats@acm.org>
wrote:

>On 7/4/2012 10:47 AM, Gene Wirchenko wrote:
>> On Wed, 04 Jul 2012 10:14:54 -0700, Patricia Shanahan <pats@acm.org>
>> wrote:
>>
>>> On 7/4/2012 10:04 AM, Gene Wirchenko wrote:
>>> ...
>>>>        Knowing something of the layer below (or even more) can help one
>>>> get more out of the system.  If you insist on using black boxes and
>>>> keeping it that way, then you do not understand the system.
>>> ...
>>>
>>> I've treated emacs and other tools as black boxes on systems I
>>> understood at every level down to details of the processor design.
>>
>>       If you know the system to that level, it is not a black box.
>
>If you define "black box" in such a way that it is not possible to treat
>something as a black box even if one understands the system, then "If
>you insist on using black boxes and keeping it that way, then you do not
>understand the system." is indeed a tautology.

     No.  If you know the inner details, it is going to help in using
such a system.  You do not just turn off your knowledge.  You will not
have a black box in that case.

     This is different from black box testing where you can do so.
(Just base your tests on use cases, not the algorithm.  (Of course, I
like white box testing, too.))

>I prefer a more functional view of "black box" in which one can treat
>something as a black box by only considering and using its external
>features, regardless of deeper understanding.

     I do that, too.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#1940

On 07/04/2012 01:01 PM, Gene Wirchenko wrote:
> On Wed, 04 Jul 2012 12:32:58 -0700, Patricia Shanahan <pats@acm.org>
> wrote:
>
>> On 7/4/2012 10:47 AM, Gene Wirchenko wrote:
>>> On Wed, 04 Jul 2012 10:14:54 -0700, Patricia Shanahan <pats@acm.org>
>>> wrote:
>>>
>>>> On 7/4/2012 10:04 AM, Gene Wirchenko wrote:
>>>> ...
>>>>>         Knowing something of the layer below (or even more) can help one
>>>>> get more out of the system.  If you insist on using black boxes and
>>>>> keeping it that way, then you do not understand the system.
>>>> ...
>>>>
>>>> I've treated emacs and other tools as black boxes on systems I
>>>> understood at every level down to details of the processor design.
>>>
>>>        If you know the system to that level, it is not a black box.
>>
>> If you define "black box" in such a way that it is not possible to treat
>> something as a black box even if one understands the system, then "If
>> you insist on using black boxes and keeping it that way, then you do not
>> understand the system." is indeed a tautology.
>
>       No.  If you know the inner details, it is going to help in using
> such a system.  You do not just turn off your knowledge.  You will not
> have a black box in that case.
>
>       This is different from black box testing where you can do so.
> (Just base your tests on use cases, not the algorithm.  (Of course, I
> like white box testing, too.))
>
>> I prefer a more functional view of "black box" in which one can treat
>> something as a black box by only considering and using its external
>> features, regardless of deeper understanding.
>
>       I do that, too.

I detect common ground between your viewpoints, with differences in the nuances.

Patricia's point of view relates to trust of a tool or layer.

You can rest on what an IDE does, as far as its functions go. You don't 
question its ability to syntax-color your source beyond the settings screen. 
That's a black-box approach.

Many recommend, however, that you understand what it does generate for source 
code, build scripts, server configuration, and other tasks that one normally 
would script, or perform through an external service-management interface. 
NetBeans Ant scripts are an infamous example, as are Eclipse .classpath files. 
Both of these work in IDE-osyncratic ways that tend to play poorly with 
industry standards.

Ditto the GUI generators. Many laud the Matisse generator built in to 
NetBeans, but its code style is its own. What if you gotcherself a corner case?

At this point you lose trust in the IDE at least somewhat. While you have no 
doubt that the symbols you type into a dot-java file will persist to disk 
safely, you might question its choices for variable scope or 'toString()' 
implementation.

The common ground, then, is to blackbox what you trust and whitebox or greybox 
what you doubt, to varying degrees. "Trust but verify", in the language of 
arms agreements.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#1941

On Wed, 04 Jul 2012 16:03:29 -0700, Lew <noone@lewscanon.com> wrote:

[snip]

>I detect common ground between your viewpoints, with differences in the nuances.

     Yup.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#1944

Lew wrote:
> On 07/04/2012 01:01 PM, Gene Wirchenko wrote:
>> On Wed, 04 Jul 2012 12:32:58 -0700, Patricia Shanahan <pats@acm.org>
>> wrote:
>>
>>> On 7/4/2012 10:47 AM, Gene Wirchenko wrote:
>>>> On Wed, 04 Jul 2012 10:14:54 -0700, Patricia Shanahan <pats@acm.org>
>>>> wrote:
>>>>
>>>>> On 7/4/2012 10:04 AM, Gene Wirchenko wrote:
>>>>> ...
>>>>>>         Knowing something of the layer below (or even more) can 
>>>>>> help one
>>>>>> get more out of the system.  If you insist on using black boxes and
>>>>>> keeping it that way, then you do not understand the system.
>>>>> ...
>>>>>
>>>>> I've treated emacs and other tools as black boxes on systems I
>>>>> understood at every level down to details of the processor design.
>>>>
>>>>        If you know the system to that level, it is not a black box.
>>>
>>> If you define "black box" in such a way that it is not possible to treat
>>> something as a black box even if one understands the system, then "If
>>> you insist on using black boxes and keeping it that way, then you do not
>>> understand the system." is indeed a tautology.
>>
>>       No.  If you know the inner details, it is going to help in using
>> such a system.  You do not just turn off your knowledge.  You will not
>> have a black box in that case.
>>
>>       This is different from black box testing where you can do so.
>> (Just base your tests on use cases, not the algorithm.  (Of course, I
>> like white box testing, too.))
>>
>>> I prefer a more functional view of "black box" in which one can treat
>>> something as a black box by only considering and using its external
>>> features, regardless of deeper understanding.
>>
>>       I do that, too.
> 
> I detect common ground between your viewpoints, with differences in the 
> nuances.
> 
> Patricia's point of view relates to trust of a tool or layer.
> 
> You can rest on what an IDE does, as far as its functions go. You don't 
> question its ability to syntax-color your source beyond the settings 
> screen. That's a black-box approach.
> 
> Many recommend, however, that you understand what it does generate for 
> source code, build scripts, server configuration, and other tasks that 
> one normally would script, or perform through an external 
> service-management interface. NetBeans Ant scripts are an infamous 
> example, as are Eclipse .classpath files. Both of these work in 
> IDE-osyncratic ways that tend to play poorly with industry standards.
> 
> Ditto the GUI generators. Many laud the Matisse generator built in to 
> NetBeans, but its code style is its own. What if you gotcherself a 
> corner case?
> 
> At this point you lose trust in the IDE at least somewhat. While you 
> have no doubt that the symbols you type into a dot-java file will 
> persist to disk safely, you might question its choices for variable 
> scope or 'toString()' implementation.
> 
> The common ground, then, is to blackbox what you trust and whitebox or 
> greybox what you doubt, to varying degrees. "Trust but verify", in the 
> language of arms agreements.
> 

I agree.

Patricia

[toc] | [prev] | [next] | [standalone]

#2046

On 07/01/2012 09:32 AM, ericmiranda7@gmail.com wrote:
> I've heard about Jcreator and eclipse.. which ide would be the best?
> 

Well I use Vim (or vi) www.vim.org, but you will have to do a little
learning in order to go with the same choice (for which case you can
open Vim, maximize the window, press F1, and start reading a few pages).

The point is if you don't know too well what and IDE is and what it
does, try to get a text editor first (or some simple editor-as-IDE), and
manually type the commands you need (for example to compile). At least
until you get bored, but in any case _not_ before you understand them
through a little practice.

Than you might feel a _need_ for an IDE, though it has never happend to
me yet, really. Even if you don't, there is nothging to loose by not
using the IDE, really. Proof to that is the fact that not everyone is
using one, some willingly choose to stay outside their convenient world.

But at the end you will find that you learned something in the process,
provided you know where the documentation is and you are not shy to look.

In any case what you should not do is go to the most sophisticated IDE,
so that you have to ask someone else to install it, 'cause you don't
understand what it wants, and after that realize that you still need a
few instructions from the person who installed it, because the 'New
project' button opens 3 to 10 more dialog boxes, instead of creating a
new project.

If you go that way, you will just learn "where to click", and you will
never learn anything else again... (sad part here).

Timothy Madden

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.help

csiph-web