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

[BGB / cr88192]

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.

(irony / joke...):
simple: just send the IDE with the product and tell the end users the magic
ritual to invoke the program from the IDE...

 

[Arne Vajhøj]

Rightly or wrongly, with the state of software engineering being what it
is I'd guess, based on observation, that many (if not most) developers
spend more like 50 percent of their time - time which can be directly
tracked against a software project - buried in their IDEs. Often it's
higher than that. I've seen any number of junior and intermediate
programmers over the years who are not tasked with anything but coding,
in which case they are north of 75%.

With those numbers then just a 2x speedup in using a IDE over a text
editor is significant.

Yes.

But please don't use the term software ENGINEERING about a
process that spends 50-75% of the time in the IDE.

Arne

 

[BGB / cr88192]

Practically no one has used J#.

After all a Java 1.1 source code compatible language is not
that cool a decade after the Java world moved on.

ok, fair enough...

 

[BGB / cr88192]

I am not particular happy with Emacs either.

But just because it does not match my personal taste does not
mean that it is not a good IDE.

fair enough, but I wasn't saying here that Emacs universally sucks, only
that in my opinion it is horrid and I prefer to stay clear of it...

I have used it before, but my personal impression was that the thing was
ugly and the keyboard shortcuts were generally absurd, and I much preferred
damn near any other editor, including vim, which I also don't particularly
like, except as the fallback that typically this is about the only editor
(apart from Emacs) which tends to come with typical text-only Linux
installs... (although some came with 'joe'...).

it is odd that about one of the (IMO) best pure text-mode editors was 'MS
Edit' for MS-DOS (which happened to handle about like Notepad, and the later
versions had ability to manage multiple open files, ...).

(although vim does have a hex editor, ...).

or such...

 

[BGB / cr88192]

Well:
- I said that files should be converted to local line format for editing
- you suggested that would mean extracting changing and repacking jar
files

Assuming there is a correlation between the two then that must be
about editing files inside jar files.


It is the responsibility of the transferring mechanism
to ensure that text files arrive in a valid text format
at the receiver.

Let me guess: you have only worked with file systems with
delimited files and no meta information about line format.
Because when you have meta data about the line format instead
of the "let us guess based on whether we see a lot of LF's or
CRLF's", then the receiver had to get it right.


The FTP protokol, the ZIP format etc. were designed to solve that
problem.

Apparently those people do not consider it a non-starter.

yeah...

a lot of ZIP tools will automatically convert known text formats.


failing this, the chain of events usually goes about like:
open file in notepad, see that it is screwed up;
summon wordpad to fix problem (usually via "Open With", click save button,
exit);
open with notepad again, problem solved...

this doesn't usually take more than a few seconds, in the rarity it
happens...

(or they can use "shell nojutsu" if there are a whole lot of them and the
"open with" ritual would get tedious...).


OTOH, one can also use a different editor (I have little idea why MS never
really bothered with LF-only line-ending support, as I wouldn't think this
would be much more than maybe a few lines of code, but oh well,
whatever...).

 

[BGB / cr88192]

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

Declaring that all programs must recognize (and perhaps
generate) all the line-demarcation conventions of all systems
everywhere is a Hell of a lot less practical.

I have, personally, actually used systems that marked
line boundaries

- With a trailing LF
- With a trailing CR
- With a trailing CR LF pair
- With a leading CR and a trailing LF
- With a leading count and possibly a trailing pad
- With a leading count plus other metadata and a possible pad
- With no per-line data whatsoever

I'm willing to wager a modest sum that you, personally, have
*never* written a program that can deal with all of even this
limited repertoire. Care to name an amount?

I have not usually seen any others than:
LF
CR
and CR-LF...

this would seem to be all of them, and I suspect CR is falling into oblivion
(since OSX switched to LF...).

or such...

 

[Arne Vajhøj]

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

Declaring that all programs must recognize (and perhaps
generate) all the line-demarcation conventions of all systems
everywhere is a Hell of a lot less practical.

I have, personally, actually used systems that marked
line boundaries

- With a trailing LF
- With a trailing CR
- With a trailing CR LF pair
- With a leading CR and a trailing LF
- With a leading count and possibly a trailing pad
- With a leading count plus other metadata and a possible pad
- With no per-line data whatsoever

I'm willing to wager a modest sum that you, personally, have
*never* written a program that can deal with all of even this
limited repertoire. Care to name an amount?

I have not usually seen any others than:
LF
CR
and CR-LF...

this would seem to be all of them, and I suspect CR is falling into oblivion
(since OSX switched to LF...).

or such...

There is a world beyond MS and *nix.

Arne

 

[Jim Janney]

I agree, for some languages like C or C++ emacs _is_ an IDE. A prof of
mine wrote a fairly large C++ tool
(http://gri.sourceforge.net/index.php) using emacs, and he would have
been doing everything from within emacs. Depending on how much a
person's emacs has been tooled up it's a mistake to call it a text
editor.

This is a fairly representative discussion regarding emacs vs Eclipse
for Java:
http://stackoverflow.com/questions/689544/is-emacs-useful-compared-to-eclipse-programming-java.


I don't doubt that there are some very good Java developers out there
who use nothing but emacs. If I used nothing but emacs, had it
thoroughly tooled up, knew all my shell mantras and had shell scripts
available to duplicate what a lot of Eclipse commands do, and had an
encyclopedic knowledge of the Java APIs for the areas that I'm working
in, I'd be just as fast as if I were using Eclipse.

AHS

At one time I did a lot of coding in Emacs Lisp, using Emacs of
course, and for that Emacs was a very good IDE indeed, as good as
anything I've used. Which leads me to speculate that for reasonably
dynamic languages (Java and Lisp and C# but not C or C++) the best IDE
is one written in the target language. For example, I really expect
any Java IDE to take advantage of the reflection API, and that's
easiest done from Java (or at least some JVM-based language).

 

[Lew]

That "may not" can have a meaning as "absolutely not".

That is a pointless point since it never was in dispute.

 

[Lew]

personally, IMHO, I find that Emacs is just horrid and prefer to stay well
clear of it...

the main thing I like about using the commandline and more ad-hoc tools is
that one is more free to customize the build environment to do what they
want (rather than being forced into the project-management and build
strategies the IDE developers had in mind).

Since the primary IDEs out there support Ant- and Maven-based builds, that is
a non-existent restriction. You have just as much freedom to structure a
project using, say, NetBeans as you do with command-line tools. Your point is
moot.

for example, one can choose the type of editor they want, have a lot more

NetBeans's and Eclipse's editors work pretty much the same as everyone else's;
the primary differences are in the syntax coloring and meta-syntactic features
that are IDE-ish rather than editorish, like the refactoring tools.

control over the build process, and can create their own tools to perform
various tasks (typically processing source code in specialized ways, or

Nonsense. The IDEs plug seamlessly into those very tools.

automatically generating source-code from custom textual formats, ...), or
use GUI-based tools for other tasks (such as GIMP, or wysiwyg GUI forms
builders, ...).

What does GIMP have to do with Java?

Even Eclipse fans begrudgingly admit that NetBeans has a superb GUI-generation
tool. Which one do you prefer for Java? How does it not work with an IDE?

as well, anymore, the OS-provided shells (be it bash or the windows command
shell), typically provide a lot of nice editing features, so a command-line
interface is nowhere near as bad as back in the days of DOS (where, if you
wanted to repeat a sequence of prior commands, it was generally needed to
re-type them, ...).

Nor anywhere near as flexible for Java development, in terms of syntax
highlighting, refactoring support, name completion, navigation between source
artifacts, debugging, ...

I espouse that programmers should choose their own editors and IDEs, and be
rated on their output and its compatibility with the team build / test protocols.

Personally I use NetBeans when allowed, Eclipse and its offspring quite
frequently, and am interested in this new Brown University "Code Bubbles"
editor.
<http://www.cs.brown.edu/people/acb/codebubbles_site.htm>

I plan to look into JDeveloper, and I drop into emacs for quite a few things,
even the occasional Java source file.

 

[BGB / cr88192]

There is a world beyond MS and *nix.

but, one almost never sees such files in common use...

CR-only is a dying breed, but still not yet entirely gone...


it is like EBCDIC:
how often does one encounter a file in this format (at random, as in, not
working explicitly with some obscure IBM technologies)?...

simple answer:
almost never...


so, what can one do about things which almost never happen:
well, simplest option is to assume they don't exist, and hedge their bets
for the off case that they do...

much like the chance that M68K will rise from the grave and grace desktop
computing once more...

 

[BGB / cr88192]

<http://en.wikipedia.org/wiki/Editor_war>

yep.

Notepad is the one true editor...

and, when not Notepad, something sort of like Notepad:
Notepad2 or Notepad++, or pretty much any other commonly-used editor on
Windows (I guess WordPad, MS Word, and Visual Studio excluded...).

on Linux, this means GEdit or KEdit (the latter less so given the effective
demise of KDE...).

Since the primary IDEs out there support Ant- and Maven-based builds, that
is a non-existent restriction. You have just as much freedom to structure
a project using, say, NetBeans as you do with command-line tools. Your
point is moot.

not used NetBeans personally...

NetBeans's and Eclipse's editors work pretty much the same as everyone
else's; the primary differences are in the syntax coloring and
meta-syntactic features that are IDE-ish rather than editorish, like the
refactoring tools.

but, one can also choose between, say, Notepad and Notepad++, or throw
VisualStudio into the mix if they want (though usually I don't use VS much
as an editor as it is annoyingly unresponsive, but the debugger is nice,
although I also often use WinDbg, ...).

I also like CodeAnalyst as a (general purpose) profiler (although, there are
some things I miss which GDB did better, but GDB doesn't work with MSVC...).

Nonsense. The IDEs plug seamlessly into those very tools.

I messed around with Eclipse for C++, and couldn't figure out how to plug it
into a damn thing...

granted, not all IDE's are equal here, and Eclipse for C++ may be a
particularly bad example...
(Eclipse is a lot better with Java, although it still doesn't seem obvious
how one can plug in their own tools...).

What does GIMP have to do with Java?

well, it can edit images, and images are often used in apps, but
photo-editing is typically not supported by IDE's...

strict IDE'ism would demand a person not use GIMP because it is not part of
their enshrined "integrated" environment...


the same can be said about 3D modellers (although most mainstream 3D
modelers are worse, as they by default package all their data into some
proprietary fileformat and have crap support for more "generic"
fileformats), ... (so, a developer might find themselves resorting to
writing their own 3D modelling and animation tools to resist folding to the
will of Autodesk...).

so, really, it is the same sort of problem...

likewise if one has customized audio or image processing tools involved as
part of their build, ...

Even Eclipse fans begrudgingly admit that NetBeans has a superb
GUI-generation tool. Which one do you prefer for Java? How does it not
work with an IDE?

well, the point is that one doesn't need the IDE have this tool, as one can
use 3rd party tools and accomplish the same task.

so, one can build the collection of tools best suited to their particular
uses...


or, they may choose to use an IDE for some parts of a project, and the
command-line for others...

Nor anywhere near as flexible for Java development, in terms of syntax
highlighting, refactoring support, name completion, navigation between
source artifacts, debugging, ...

but, your can easily use tools which parse ones' codebase, and possibly
generate new data.

although not as relevent to Java, this kind of thing is useful in languages
like C and C++ to help implement features like reflection (or, originally,
automatic header writing, which was one of my earliest uses of
code-processing tools, as at the time I had found writing headers to be a
terrible annoyance...).

more recently, data mined by such a tool has been used generally to aide
providing a semi-transparent interface between ECMAScript and C-land (I can
use various C API's from within ECMAScript without any of the usual
boilerplate, and this info could be mined at runtime if needed, which is
actually how things were done originally until I realized that it was more
efficient and more convinient to mine this data at build-time, and manage
the databases as part of the build process...).

another related use is processing data files and generating code from them,
....


note that syntax highlighting, autocomplete, ... are supported by many text
editors (although not by Notepad... but whether or not one is using Notepad
is besides the point...).

I espouse that programmers should choose their own editors and IDEs, and
be rated on their output and its compatibility with the team build / test
protocols.

ok.


Personally I use NetBeans when allowed, Eclipse and its offspring quite
frequently, and am interested in this new Brown University "Code Bubbles"
editor.
<http://www.cs.brown.edu/people/acb/codebubbles_site.htm>

I plan to look into JDeveloper, and I drop into emacs for quite a few
things, even the occasional Java source file.

ok.

 

[Mike Schilling]

Practically no one has used J#.

After all a Java 1.1 source code compatible language is not
that cool a decade after the Java world moved on.

J# had a funny history within Microsoft. Ir began as a half-supported
upgrade path from J++, was made to work and spent a few years as a
more-or-less mainstream part of .NET (e.g. API docs gave examples of it
use), then it was "stabilized", and removed from the currrent versions
entirely.

 

[Mike Schilling]

At one time I did a lot of coding in Emacs Lisp, using Emacs of
course, and for that Emacs was a very good IDE indeed, as good as
anything I've used. Which leads me to speculate that for reasonably
dynamic languages (Java and Lisp and C# but not C or C++) the best IDE
is one written in the target language. For example, I really expect
any Java IDE to take advantage of the reflection API, and that's
easiest done from Java (or at least some JVM-based language).

True, but the class file format is simple enough that one would whip up a
(say) C++ version of Java reflection in at most a few weeks. I know less
about JPDA, but I suspect the same is true.

 

[Tom Anderson]

My mother is a retired English teacher.

Ah, so that's why you speak retired English!

tom

 

[Arved Sandstrom]

Yes.

But please don't use the term software ENGINEERING about a
process that spends 50-75% of the time in the IDE.

Arne

I think it would depend on the role of the developer and the particular
methodology in use - 50%+ time spent in the IDE might not be indicative
of a low state of software process, or it might be.

And after all, IDE does mean _Integrated_ Development _Environment_. In
theory a developer could be knocking out everything from requirements
analysis through design and coding to running/analyzing tests in one of
those puppies.

AHS

 

[Arved Sandstrom]

At one time I did a lot of coding in Emacs Lisp, using Emacs of
course, and for that Emacs was a very good IDE indeed, as good as
anything I've used. Which leads me to speculate that for reasonably
dynamic languages (Java and Lisp and C# but not C or C++) the best IDE
is one written in the target language. For example, I really expect
any Java IDE to take advantage of the reflection API, and that's
easiest done from Java (or at least some JVM-based language).

Interesting observation. My favourite IDE for Haskell is Leksah (quite a
nice piece of work in its 0.8 incarnation), and that's written in
Haskell. If nothing else the developers writing the IDE are developing
in the target language, so they are constantly immersed in doing exactly
what they want the IDE ultimately to help with.

AHS

 

[Arved Sandstrom]

Lew wrote:
[ SNIP ]

Personally I use NetBeans when allowed, Eclipse and its offspring quite
frequently, and am interested in this new Brown University "Code
Bubbles" editor.
<http://www.cs.brown.edu/people/acb/codebubbles_site.htm>

Nice find on Code Bubbles...I'll have to try that out too.

I plan to look into JDeveloper, and I drop into emacs for quite a few
things, even the occasional Java source file.

Interestingly enough JDeveloper's parent, JBuilder (which I used back in
the day), is still available from Embarcadero (CodeGear). That's gotten
so far off my radar screen that I can't say I've run across anyone that
uses it in years. But surely some people do.

My most frequent use of emacs is when I forget to supply a comment when
doing a command line Subversion commit; my EDITOR on my UNIXes is emacs,
so I have to write my comments using that. I don't have anything
against emacs in particular, but if I need a text editor I'll use vi or
gedit normally.

AHS

 

[Lew]

And after all, IDE does mean _Integrated_ Development _Environment_. In
theory a developer could be knocking out everything from requirements
analysis through design and coding to running/analyzing tests in one of
those puppies.

And in practice.

The top Java IDEs have varying degrees of support for design-time activities,
e.g., UML tools. They all intrinsically support JUnit. They all act as
really great control panels for database systems and app servers. They handle
deployment descriptors as such, and other XML quite niftily. They tightly
integrate with the major version-control systems. They capture the output of
these processes for perusal, storage on disk, diff comparison and the like.

I love that they control app servers and database systems.

 

[Lew]

Interesting observation. My favourite IDE for Haskell is Leksah (quite a
nice piece of work in its 0.8 incarnation), and that's written in
Haskell. If nothing else the developers writing the IDE are developing
in the target language, so they are constantly immersed in doing exactly
what they want the IDE ultimately to help with.

Similarly with the Java IDEs, which are written in Java.