Do you suggest me using IDE when I'm learning JAVA

[Arved Sandstrom]

I agree with all of the above - now. Prior to 2000 I used text editors

»[T]he only 3 editors we know to be used by great
hackers are TextMate, vim and emacs. (...)

We haven't met a single great hacker that relied
on an IDE, although we hear they exist.«

http://giraffesoft.ca/blog/2009/03/10/4-core-competencies-of-great-hackers.html

»He declined offers of typing help, and just kept
writing away in pencil. He rewrote parts, copied
things over, erased and rewrote.

Finally André took his neat final pencil copy to a
terminal and typed the whole program in (...)
the VTOC manager worked perfectly from then on.«

http://www.multicians.org/andre.html

I ordered my first computer in 1977, but it was delivered
not before 1978. In the meantime, I learned »my« first
programming language »BASIC« by reading a book and writing
programs on paper, executing them in my mind. So, when the
Pet 2001 finally arrived, I already was able to program it.

I started programming with punch cards, first in Fortran and then
Algol W -- you'd write everything out by hand and then stand in line
for one of the keypunches. It did make you check everything over and
over and over again. Still, I wouldn't recommend doing that now.

You and me both, actually, although for me it was just the FORTRAN. What
that taught me was to be careful when using the keypunch. Yes, it also
taught me to be fairly careful of language errors, but mostly I gained
respect for meticulous typing. In effect the main lesson from using
punched cards was to avoid typos.

I progressed from cards to line editors on basic terminals, then fairly
quickly to vi and emacs on UNIX, then decent programing text editors on
various Macs and PCs, and finally to IDEs (although I'll still use
command line or text editors where they shine, e.g I'll usually do
complicated Subversion on the C.L. outside Eclipse, then refresh the
Eclipse workspace). To be brutally honest, while each step in that
progression did teach me not to be sloppy, I believe I would have
learned that lesson soon enough if starting with an IDE.

To put it another way, I don't think the tools you use teach you to be a
good programmer. Which is sort of an undercurrent I'm sensing here in
parts of this thread. I think mental discipline that you have already is
what carries the day. If you're sloppy when using an IDE you'll be
sloppy when using vim.

I read a story like the one about Andre Bensoussan
(http://www.multicians.org/andre.html) and, no disrespect meant to the
dead, but the part about him writing and erasing and rewriting, when he
actually got to writing code, when terminals and electronic editor
programs were available, is just silly.

I also happen to believe that a lot of these folks who praise text
editors to the skies, and who think that great hackers don't use IDEs,
are making a virtue out of artificial and unnecessary self-imposed
constraints. Unless I take a programming text editor and heavily
customize it, in effect making it an IDE, there are many things I can do
in an IDE that I can't do with the text editor alone. Many of those
things are very useful and time-saving. I could do them on the command
line or with shell scripts, but then I'd be re-inventing the wheel. If I
chose not to do them at all, or wasn't even aware that I could do them,
I hardly think that's praiseworthy. In any case I'd be spending more of
my time in a non-IDE situation to get the job done.

I don't doubt that a lot of very good programmers use text editors
rather than IDEs. More power to them - I'll stick with IDEs where they
suit, because they allow me to get work done faster.

A lot depends on exactly what it is that people are writing. If I was
writing a Linux device driver in C I'd be cool with vim. But these days,
where I have to deal with .NET or J2EE web apps with thousands of source
files, I'd be an imbecile to try and do that with emacs.

AHS

 

[David Segall]

I started programming with punch cards, first in Fortran and then
Algol W -- you'd write everything out by hand and then stand in line
for one of the keypunches. It did make you check everything over and
over and over again. Still, I wouldn't recommend doing that now.

You mean you haven't used a dibber to alter a paper tape binary? How
did you avoid using the switches on the front panel to alter the
program in core memory?

I don't see how anybody can seriously join this style of competition
if they have watched the "Four Yorkshire Men"
<

>.

 

[Jim Janney]

You mean you haven't used a dibber to alter a paper tape binary? How
did you avoid using the switches on the front panel to alter the
program in core memory?

I don't see how anybody can seriously join this style of competition
if they have watched the "Four Yorkshire Men"
<

>.

Sorry, no paper tapes. In high school the computer was on a different
campus, and only one student was allowed to operate the card reader.
If he didn't like you he'd "forget" to run your jobs. In college you
could walk right up and use the card reader, but the computer was
behind a glass wall: no way were they allowing mere freshmen anywhere
near it.

With Eclipse I can hit a breakpoint, change a line, recompile, and
continue running in the same stack frame. I like this better.

 

[BGB / cr88192]

I agree with all of the above - now. Prior to 2000 I used text editors

»[T]he only 3 editors we know to be used by great
hackers are TextMate, vim and emacs. (...)

We haven't met a single great hacker that relied on an IDE,
although we hear they exist.«

http://giraffesoft.ca/blog/2009/03/10/4-core-competencies-of-great-hackers.html

[ SNIP ]

After reading what that guy wrote in that link, I must conclude that he's
an ignorant idiot. It is not humanly possible - and common sense should
have informed that fool of this fact - to be faster without an IDE than
with one. And if some individual has an environment built up around vim or
emacs or some other programming text editor, with all sorts of helper
scripts and macros and what have you, with which they are also very
productive...guess what? That is also an IDE.

I think a lot of this would depend on various factors:
the speed and skills of the developers involved;
the particular languages and coding practices in use;
....

for example, a developer who can (on a good day) churn out several kloc/day
with Notepad and with a relatively low error rate, will naturally still be
much faster than someone who fudges away getting caught up on details like
what exactly "Encapsulate Field" does, or starts having troubles due to
having created several different objects with conflicting names...

another problem is that many IDE commands tend to depend heavily on
mouse-movements (such as pointy-clicky or operating menus), which can eat up
more time than the equivalent sets of keyboard actions (if one really gets
into it).

for example, if it takes around 5-8 seconds to do an action with a mouse,
but one can do the same with the keyboard in around 3-4 seconds, then not
much is saved (apart from maybe one being accused of jackhammering the
keyboard...).

granted, for the most part IDE's still tend to work pretty well as
text-editors. apart from many of them being laggy and having poor response
times, and it can be disorientating when one is typing faster than the thing
can update the text on the screen... (granted, this can also be a problem
with other apps as well...).


however, as noted, language may also effect a lot.

for example, Java imposes the one-class-per-file restriction, and this
itself can eat time (since then one has to manage many more files, which
typically means much more jumping between files, ...). this is different
from something like C or C++ where one can generally put however much code
per file is convinient (which often ends up being around 500 - 1500 lines
per file IME).


granted, much more of the time though, one typically goes at a more
leisurely pace, often due to things like doing other stuff, thinking about
stuff (having to stop and think is itself a great time-eater), ...

if one considers all the huge masses of time that usually go into having to
stop and think about stuff (like strategize and consider implementation
strategies and such...) then this likely eats up much of the overall
performance differences (the great flow of mind-to-code broken by the
consideration of how to work a given feature into the existing codebase,
....).


or such...

 

[John B. Matthews]

Java imposes the one-class-per-file restriction

More specifically, one public, top-level class per file. There can be an
arbitrary number of package-private and nested classes.

<http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.6>
<http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html>
<http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html>

 

[Lew]

I think a lot of this would depend on various factors:
the speed and skills of the developers involved;
the particular languages and coding practices in use;
...

for example, a developer who can (on a good day) churn out several kloc/day
with Notepad and with a relatively low error rate, will naturally still be
much faster than someone who fudges away getting caught up on details like
what exactly "Encapsulate Field" does, or starts having troubles due to
having created several different objects with conflicting names...

In other words, a developer who understands programming and knows what they're
doing will outperform a developer who doesn't.

I don't think the IDE is a factor in that.

A developer who can churn out effective and useful code (KLOC being a useless
measure of productivity) with an IDE and a low error rate will naturally be
much faster (and more effective) than someone who fudges away with a text
editor, getting caught up on details like what exactly encapsulating a field
is, or has troubles due to the creation of several different objects with
conflicting names.

(One period suffices to end a sentence.)

 

[BGB / cr88192]

More specifically, one public, top-level class per file. There can be an
arbitrary number of package-private and nested classes.

<http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.6>
<http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html>
<http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html>

granted, but I meant excluding these and similar...

either way, it is not the free-form "collection of loosely-related stuff"
strategy one can typically use with C and C++, where one is more free to
organize file contents generally however they want...

granted, with C++ many people still follow a one-class-per-file organization
as well (or, more like, one class per pair of header-and-source file).

 

[Mike Schilling]

A developer who can churn out effective and useful code (KLOC being a
useless measure of productivity) with an IDE and a low error rate
will naturally be much faster (and more effective) than someone who
fudges away with a text editor, getting caught up on details like
what exactly encapsulating a field is, or has troubles due to the
creation of several different objects with conflicting names.

Or simply making typos that the IDE catches immediately, rather than having
to fix them during some number of compilation cycles.

 

[BGB / cr88192]

In other words, a developer who understands programming and knows what
they're doing will outperform a developer who doesn't.

I don't think the IDE is a factor in that.

A developer who can churn out effective and useful code (KLOC being a
useless measure of productivity) with an IDE and a low error rate will
naturally be much faster (and more effective) than someone who fudges away
with a text editor, getting caught up on details like what exactly
encapsulating a field is, or has troubles due to the creation of several
different objects with conflicting names.

well, the IDE is a factor, mostly since it is often portrayed as being a
sort of productivity silver-bullet...

someone who doesn't know what their doing, even with such a silver-bullet,
will not outperform someone who does know what they are doing, regardless of
particular tool choice.


now, if both people are otherwise fairly equal skill-wise, then it is more
of a contest, and I suspect which is faster is likely to depend a whole lot
on the particular task and coding practices in use, ...

for example, in the creation of GUI apps (and IDE's with support for this
built-in), then the person with the IDE will be at a notable advantage.

if they are doing something like kernel development or compiler writing,
then the IDE is not likely to provide as much help.

(One period suffices to end a sentence.)

how many periods is best I think depends on the particular semantics and
affect of the sentence being ended.

a single period has the idea of finality, namely that the particular
sentence or idea has ended.
"..." has the sense that the idea goes on, but the writer is not going to
spend lots of time going over the various possibilities, describing each
one, ...

I guess it can also be used to indicate when a person is drifting from one
topic to another, and the things separated by elipses are not necessarily
related, for example:
"and then I was doing some homework... oh look, a dog has wandered by the
window... and the homework was being really boring and difficult... the dog
turns in a circle and sniffs himself... the birds are singing in a tree."
(absent elipses this chain of thought would seem to be broken).


http://en.wikipedia.org/wiki/Elipses

or such...

 

[BGB / cr88192]

That's entirely possible, that some people will have barely any grasp of
how to work outside the IDE. If we discount developers leaving the IDE fro
time to time to use a word processor or web browser, and also include the
ability of the IDE to call up server consoles and what not, then these
days with the latest IDEs a person can likely get away with using the IDE
for everything and not suffer.

and then experience vendor lock-in and the inability to "port" their code to
another OS (or IDE...).

one could easily see such a person trying to, say, copy-paste piles of code
(from the editor windows, or worse-yet, from the GUI designer) between, say,
Visual Studio and Eclipse, and not really have any idea why all their stuff
is blowing up in their face, or end up bewildered at the thought of how to
make use of 3rd party libraries, ...

so, there is some merit in a developer having some understanding of what is
going on underneath.

it is much like how there is merit in end users having some idea how the
filesystem works, and so not being hopelessly confused with the idea of how
to send contents from "My Documents" to a different computer.

 

[Arved Sandstrom]

and then experience vendor lock-in and the inability to "port" their code to
another OS (or IDE...).

Only if they don't understand where all the artifacts are. Which both of
us comment on further below.

one could easily see such a person trying to, say, copy-paste piles of code
(from the editor windows, or worse-yet, from the GUI designer) between, say,
Visual Studio and Eclipse, and not really have any idea why all their stuff
is blowing up in their face, or end up bewildered at the thought of how to
make use of 3rd party libraries, ...

so, there is some merit in a developer having some understanding of what is
going on underneath.

it is much like how there is merit in end users having some idea how the
filesystem works, and so not being hopelessly confused with the idea of how
to send contents from "My Documents" to a different computer.

You won't find me arguing that an IDE user shouldn't understand all
source artifacts generated by the IDE. In my experience when using the
various Java IDEs, or Visual Studio, or somewhat more esoteric IDEs like
Anjuta or Leksah, you can always find the "raw stuff" so that you can,
if necessary, dispense with the IDE and proceed with text editor and
command line tools.

Also in my experience, developers that are going to amount to anything
do find out what the sources - Java, C#, F#, HTML/XHTML, XML etc - are,
and how to edit them directly. And in any case a developer using an IDE
may, depending on inclination, be looking at the unvarnished source just
as if they were using a text editor like vi, except that the IDE also
understands that source but vi doesn't.

The only thing I have no patience with is if a developer lets an IDE
shortcoming or defect stall them in getting work done, when there is
*always* a way of bypassing the IDE. I've seen people get stuck with
flaky server adapters in Eclipse, or buggy ESB/BPEL configuration
wizards in JDeveloper, or have EAR deployment issues to J2EE servers,
when all they had to do was work outside the IDE for these things.

AHS

 

[BGB / cr88192]

Only if they don't understand where all the artifacts are. Which both of
us comment on further below.

yep.



You won't find me arguing that an IDE user shouldn't understand all source
artifacts generated by the IDE. In my experience when using the various
Java IDEs, or Visual Studio, or somewhat more esoteric IDEs like Anjuta or
Leksah, you can always find the "raw stuff" so that you can, if necessary,
dispense with the IDE and proceed with text editor and command line tools.

Also in my experience, developers that are going to amount to anything do
find out what the sources - Java, C#, F#, HTML/XHTML, XML etc - are, and
how to edit them directly. And in any case a developer using an IDE may,
depending on inclination, be looking at the unvarnished source just as if
they were using a text editor like vi, except that the IDE also
understands that source but vi doesn't.

yep.

I guess this makes sense.
actually, one could encourage developers to mess with and look at the
various files, fileformats, ... in order to get a better idea of what is
there and how it works (even as much as the thing may look like some magic
do-everything frontend...).


but, I have seen plenty of people get stuck on the whole Word <-> My
Documents <-> Filesystem issue.
notatbly, there are classes at colleges to try to address these sorts of
issues.

theoretically, these people are still otherwise-productive individuals, just
for whatever reason they never really learn what goes on in the OS (and the
way Windows is designed at times doesn't help, it is about like they try to
specially design it so that people don't actually learn what is going on,
them instead apparently imagining the computer as some magic box which
stores Word documents or similar...).

I have also seen people get dismayed when they manage to change directories
(or end up somehow saving their document somewhere else), and end up
thinking that all their documents have just disappeared, ...


then again, maybe these sorts of people are also unlikely to become
programmers?...

The only thing I have no patience with is if a developer lets an IDE
shortcoming or defect stall them in getting work done, when there is
*always* a way of bypassing the IDE. I've seen people get stuck with flaky
server adapters in Eclipse, or buggy ESB/BPEL configuration wizards in
JDeveloper, or have EAR deployment issues to J2EE servers, when all they
had to do was work outside the IDE for these things.

yes, ok.

 

[Arne Vajhøj]

The Zeus editor does not have these issues and it supports Java:

http://www.zeusedit.com

Plenty of editors does. That is not really the discussion topic.

Arne

 

[Arne Vajhøj]

Rubbish. Should they unpack every jar they move across and see if it has
text files in, so they can convert them? Should they then have to
magically re-sign any sealed packages whose contents have changed?

Given that notepad does not support editing of text files
inside jar files, then there are absolutely no point in
that nor any relevance for the discussion.

Arne

 

[Arne Vajhøj]

I don't know a single good developer who develops on Windows. ....
I'm sure good developers who use Windows exist, but *everyone* i know
who's worth their salt uses either a Mac or Linux.

Maybe you don't know companies where the company decide
what OS their employees run and where the choice of OS is Windows.

But that tells more about your level of experience than
the Java world.

As for deployment, i've been involved in exactly one project that was
planning to deploy on Windows. As far as i know, that project is still
in the process of bursting into flames and dying, although that's got
little if anything to do with its target platform.

A recent survey showed the following target platforms for Java EE:

Window 57%
Redhat & Centos 35%
SUSE 12%
Other Linux 16%
Solaris 18%
AIX 14%
HP-UX 5%
Other 7%
No answer 18%

(it adds to a lot more than 100% because many deploy on
multiple platforms)

Arne

 

[Arne Vajhøj]

More specifically, one public, top-level class per file. There can be an
arbitrary number of package-private and nested classes.

<http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.6>

This just say:

<quote>
When packages are stored in a file system (§7.2.1), the host system may
choose to enforce the restriction that ...
</quote>

But SUN's implementation (and probably all other common implementations)
of Java compiler does enforce.

Arne

 

[Tom Anderson]

I also happen to believe that a lot of these folks who praise text
editors to the skies, and who think that great hackers don't use IDEs,
are making a virtue out of artificial and unnecessary self-imposed
constraints.

It's also a complete lie. What did Alan Kay use while developing
Smalltalk? Naturally, he used Smalltalk, which is effectively an IDE.

tom

 

[Arne Vajhøj]

well, the IDE is a factor, mostly since it is often portrayed as being a
sort of productivity silver-bullet...

someone who doesn't know what their doing, even with such a silver-bullet,
will not outperform someone who does know what they are doing, regardless of
particular tool choice.

now, if both people are otherwise fairly equal skill-wise, then it is more
of a contest, and I suspect which is faster is likely to depend a whole lot
on the particular task and coding practices in use, ...

for example, in the creation of GUI apps (and IDE's with support for this
built-in), then the person with the IDE will be at a notable advantage.

if they are doing something like kernel development or compiler writing,
then the IDE is not likely to provide as much help.

USAF STSC publicized some research results for software costs last
summer.

(quite an interesting paper I can recommend it)

The concluded that the GUI tools from 2000 gave a
productivity increase of approx. 10% compared to
the text tools from 1980.

At average the GUI tools are slightly more efficient.

Arne

 

[Tom Anderson]

Given that notepad does not support editing of text files inside jar
files, then there are absolutely no point in that nor any relevance for
the discussion.

What? Where does the idea of editing files inside JAR files come into
this?

On any platform, you may find yourself confronted by files with any kind
of line ending at any time, which have arrived from via any route.
Declaring that all files must be converted on import is a complete
non-starter.

tom

 

[Arne Vajhøj]

That's entirely possible, that some people will have barely any grasp of
how to work outside the IDE. If we discount developers leaving the IDE
fro time to time to use a word processor or web browser, and also
include the ability of the IDE to call up server consoles and what not,
then these days with the latest IDEs a person can likely get away with
using the IDE for everything and not suffer.

Oh - the developer may not suffer, but all the people that has
to do the final packaging, QA support and production support that
the developer can not help with because the does not understand
how the output of his development is used will suffer.

Arne