informat IDE survey

[Roedy Green]

I'm curious what people are using as their IDE to write Java code.
The biggies used to be Eclipse, NetBeans and IntelliJ. What are they
now? What are you using?

 

[Arne Vajhøj]

I'm curious what people are using as their IDE to write Java code.
The biggies used to be Eclipse, NetBeans and IntelliJ. What are they
now? What are you using?

That is more or less still the case (with Eclipse in front).

http://storage.pardot.com/1772/18317/Survey_Results.pdf
http://www.zeroturnaround.com/java-ee-productivity-report-2011/

Personally I also prefer Eclipse.

Arne

 

[Arved Sandstrom]

I'm curious what people are using as their IDE to write Java code.
The biggies used to be Eclipse, NetBeans and IntelliJ. What are they
now? What are you using?

All of the above, plus JDeveloper. The choices are largely driven by
having to work on client sites with client developers who are told what
to use, which means I use what they use so I don't go insane.

Truth be told I don't much care which IDE I use. All of them have the
necessaries, as far as I am concerned. Provided that they are reliable I
am tolerant of idiosyncracies.

AHS

 

[Roedy Green]

Emacs. And I'm measurably more productive than my colleagues who
waste their time fighting with their IDEs.

I take it you are not a windows user, or for some reason are able to
avoid windows apps. I found flipping back and forth insanity inducing.

 

[Lawrence D'Oliveiro]

Emacs. And I'm measurably more productive than my colleagues who
waste their time fighting with their IDEs.

I wasn’t going to be the first, but another vote for Emacs here.

 

[Arved Sandstrom]

Emacs. And I'm measurably more productive than my colleagues who
waste their time fighting with their IDEs.

Regards,

Patrick

Nothing against Emacs, but if your colleagues are "fighting" with their
IDEs then they are either novices or doing something wrong. If you are
doing standard editing+building of Java source, say, it's basically
impossible for Emacs on any platform to be faster, in practical terms,
than Eclipse or Netbeans or IntelliJ. What could possibly be faster?
Typing of keystrokes or deleting a piece of text? Calling javac to
compile your source? Locating a Java class and opening it?

If you mean that your colleagues are fighting with their IDEs when it
comes to doing another task that isn't particularly well-supported by
the state of tooling for that task in the IDE, I'll buy that. For
example, for a number of reasons I won't do all but the simplest
revision control operations (whether SVN or Mercurial or whatever) in an
IDE - I do them on the command line and then refresh the IDE. I won't do
anything but the simplest merge work in an IDE either - I'll use a
purpose-built merge program on whatever OS I'm on.

If an IDE proves lacking or fractious during a deploy procedure to an
app server, I'll not use the IDE. I make sure I know how to command-line
or admin console deploy artifacts to the server if necessary.

A key skill that intermediate developers (even promising junior)
developers learn is how to *not* use an IDE when it's in the way. If all
the dialog-driven tooling in an IDE is interfering with your use of JPA,
say, then skip the automation and craft the necessary files yourself. If
some little quirk in JDeveloper, while working with Oracle ESB or BPEL,
is driving you to distraction, skip the IDE and know what XML files you
need to edit directly.

Emacs doesn't have close to the same kind of Java support that a full
Java IDE has. So ultimately the productivity argument for Emacs over a
Java IDE comes down to editing large volumes of text...for which Emacs
is arguably better. However, and speaking for myself, as a Java
programmer (well, as a programmer period, in any language), I don't
generate large volumes of text. I don't even create medium volumes of
text. Even in full-blown new development mode I spend most of my time
thinking about what I'm doing, not acting like an administrative
assistant pounding out letters for the boss.

I trust that you're not talking about Emacs+JDEE, say. That combination
*is* a Java IDE.

AHS

 

[Lew]

Rather tangential to this discussion, perhaps, but I think that one
of the bad habits of developers who grew up on an IDE as opposed
to text-editors + command-line tools are likely to have is to reach
for the debugger much too soon.

I've seen far too many developers who spend time blithely single-stepping
through code instead of thinking about what could be wrong.

Sure, people misuse tools. But a hammer isn't a bad tool because someone hit
their thumb with it, and an adze isn't a bad tool just because someone tried
to fasten a bolt with it.

"Grew up on an IDE" is one of those pitiful excuses used to let someone off
the hook for not knowing what the **** they're doing.

 

[Daniele Futtorovic]

I've seen far too many developers who spend time blithely single-stepping
through code instead of thinking about what could be wrong.

Amen. Always makes me wonder whether a good punching would help.

 

[markspace]

Rather tangential to this discussion, perhaps, but I think that one
of the bad habits of developers who grew up on an IDE as opposed
to text-editors + command-line tools are likely to have is to reach
for the debugger much too soon.

Corrallary: Not using print/log statements to debug code.

Not only are log statements often a much faster way to debug, they are
permanent and therefore can be reused later, used when you have new and
different problems, and also can be used by other programmers or later
in a product's life cycle, i.e. maintenance.

 

[Lew]

Corrallary: Not using print/log statements to debug code.

Not only are log statements often a much faster way to debug, they are
permanent and therefore can be reused later, used when you have new and
different problems, and also can be used by other programmers or later in a
product's life cycle, i.e. maintenance.

+1.

Particularly if the log statements are designed to help ops folks, not
particularly developers, particularly.

 

[Mike Schilling]

Amen. Always makes me wonder whether a good punching would help.

Single-stepping through newly-written code is an excellent way to determine
whether it's working as designed, or getting what looks like the right
answer for the wrong reason.

 

[Daniele Futtorovic]

Single-stepping through newly-written code is an excellent way to
determine whether it's working as designed

Not even that. Not unless you can simulate all the logical branches
(which, incidentally, means doing your stepping through 2^n times, with
n being the number of branchings), in which case you'd have written a
unit test and might as well give it a run for itself and see in one go
whether there's a problem in the first place.

What's more, you speak of newly-written code. I understood Leif's
comment to apply to debugging, rather.

 

[Lew]

Single-stepping through newly-written code is an excellent way to determine
whether it's working as designed, or getting what looks like the right answer
for the wrong reason.

The right tool is what works for a given programmer at a given moment with the
given situation. One shouldn't be afraid to apply the debugger, but it isn't
the only crayon in the box.

Not long ago I worked on a routine (to calculate the number of days in an
interval) that appeared to pass its unit tests because the test code had the
same bug as the code under test, canceling the effect. Code inspection
revealed suspicion, debugging confirmed it, a new test class was able to
validate the difference and confirm the fix, and judicious log statements in
the code guarded against future problems. All the techniques were useful.

 

[Lawrence D'Oliveiro]

If you are doing standard editing+building of Java source, say, it's
basically impossible for Emacs on any platform to be faster, in practical
terms, than Eclipse or Netbeans or IntelliJ. What could possibly be
faster?

Pressing CTRL/S to start a search, typing the search string, then repeating
CTRL/S to step forward through all instances or CTRL/R to step backward.
Press Enter to leave the point at the desired location, or CTRl/G to abandon
the search.

Pressing CTRL-X ( to start defining a macro, CTRL-X ) to finish it, then
CTRL-X e to execute it, e to execute again, repeat, repeat.

Having multiple clipboards with CTRL/X r s 1, CTRL/X r s 2 etc.

Being able to execute a shell command and insert its output directly into a
text buffer.

Basically, being able to type as fast as you can think.

 

[Arved Sandstrom]

Single-stepping through newly-written code is an excellent way to
determine whether it's working as designed, or getting what looks like
the right answer for the wrong reason.

I won't argue the point; it's clearly a useful thing for you to do in
some scenario involving new code. The question that occurs to me is,
given that if we're considering debugging that we've got executable code
in hand, what happened to all the unit tests? And functional tests?

"Right answer for the wrong reason": I can see debugging happening here.
Lew came up with a scenario where that was useful. But "determining
whether it's working as designed": I don't see this as a compelling
scenario for debugging.

On a related note, and I could have added this to a reply to several
other posts in this thread, I tend to look at defect work in any stage
of development - new code or old code - as an opportunity to help out
the ops support people and the maintenance programmers. Probably because
I do mostly maintenance consulting - how to rescue applications.
Because debugging is sort of the tool of last resort in this environment
I consider logging and tests and code knowledge to come first. In fact
even with a codebase that I didn't have source for I'd probably consider
decompiling first, as an aid to putting in useful tracing with something
like AspectJ.

The other point to consider, in discussing a limited skillset that
focuses on debugging, is how do you deal with all those defects that
cannot be reliably reproduced, or that don't happen in a debugger? By
"reliably reproduced" I mean those defects - and they are common - that
happen in production but that nobody knows how to make happen in any
other setting.

AHS

 

[Daniele Futtorovic]

Basically, being able to type as fast as you can think.

It's either one or the other, lad. You can't see the big picture when
you've got to focus on writing the small one.

 

[Arved Sandstrom]

Pressing CTRL/S to start a search, typing the search string, then repeating
CTRL/S to step forward through all instances or CTRL/R to step backward.
Press Enter to leave the point at the desired location, or CTRl/G to abandon
the search.

Every decent text editor under the sun, whether contained in an IDE or
standalone, can do this through multiple files in defined scopes. Java
IDES can also let you restrict your search to methods or ctors or
fields, for example. I must be missing something.

Pressing CTRL-X ( to start defining a macro, CTRL-X ) to finish it, then
CTRL-X e to execute it, e to execute again, repeat, repeat.

The main Java IDEs have macros in a true sense of the term. You haven't
found them yet?

Having multiple clipboards with CTRL/X r s 1, CTRL/X r s 2 etc.

Some Java IDEs have this capability or an equivalent. Failing that it's
not exactly difficult to keep a text editor pane/window open as a clipboard.

Being able to execute a shell command and insert its output directly into a
text buffer.

Well, let's see, I need to do that _inside_ a Java IDE about once every
5 years. Considering that the operation of executing a shell command and
inserting its output into a file I can do in a Linux/Mac OS X terminal
or a Windows Powershell window, I don't think I'm missing much here.

Basically, being able to type as fast as you can think.

Which is fantastic if you're writing a book.

AHS

 

[Martin Gregorie]

The other point to consider, in discussing a limited skillset that
focuses on debugging, is how do you deal with all those defects that
cannot be reliably reproduced, or that don't happen in a debugger? By
"reliably reproduced" I mean those defects - and they are common - that
happen in production but that nobody knows how to make happen in any
other setting.

That can be where the next stage after the ability to turn on tracing/
logging really shines - tracing/logging via a circular buffer, where
tracing messages are generated but written into a circular buffer rather
than to a file. The buffer is dumped if/when the program hits a fatal or
a serious but recoverable error. There are three benefits from this
approach:

- the overheads of writing to the circular buffer are much less than
writing to a log file - so much so that the impact on the running
system is often scarcely noticeable.

- you don't have megabytes of trace log chewing up disk space and
using bandwidth if it gets sent to the maintenance programmer.

- you merely get the n trace messages, where n is the number of lines
in the buffer and will be a few hundred at most. This is usually
plenty to show the error and how it caused the more serious error.

Its an approach I learned back in the late 70s when I was sysadmin for
ICL's George 3 OS, which maintained two circular buffers, one much finer
grained than the other, and which could be printed out during a crash
analysis.

If your shop has a standard tracing class its worth giving it a
configurable circular buffering capability.

 

[Arne Vajhøj]

I've never seriously used Eclipse, but I'd be willing to bet a paycheck
that I could adapt and be productive with it in a week or two. The key
word there is "adapt" - a little flexibility goes a long way.

Being able to learn a new tool relative quickly is a
requirement for being a good software developer.

Arne

 

[Daniele Futtorovic]

That can be where the next stage after the ability to turn on tracing/
logging really shines - tracing/logging via a circular buffer, where
tracing messages are generated but written into a circular buffer rather
than to a file. The buffer is dumped if/when the program hits a fatal or
a serious but recoverable error. There are three benefits from this
approach:

- the overheads of writing to the circular buffer are much less than
writing to a log file - so much so that the impact on the running
system is often scarcely noticeable.

- you don't have megabytes of trace log chewing up disk space and
using bandwidth if it gets sent to the maintenance programmer.

- you merely get the n trace messages, where n is the number of lines
in the buffer and will be a few hundred at most. This is usually
plenty to show the error and how it caused the more serious error.

Its an approach I learned back in the late 70s when I was sysadmin for
ICL's George 3 OS, which maintained two circular buffers, one much finer
grained than the other, and which could be printed out during a crash
analysis.

If your shop has a standard tracing class its worth giving it a
configurable circular buffering capability.

Sounds cool. But what if you want to have logging statements so as to
affirm that some expected thing happened?