Lew said:
I was not aware that Visual Studio supported Java development or
debugging.
technically, it doesn't...
it can be used though as a general purpose text editor though (which would
include being usable for Java), but its poor responsiveness makes it not
ideal for this (nearly any action in VS is followed by a bit of a delay...).
plain editors, OTOH, tend to be a bit faster...
but, I am a mixed-language developer, and VS works fairly well if/when one
is using C#...
I don't use it so much for C.
I typically use either Eclipse or plain editors for Java...
...
granted, not all IDE's [sic] 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...).
Which tools for Java have you not been able to use readily from Eclipse?
well, I have not had much problem with Eclipse for Java, but it is Eclipse
for C++ which is not as good.
most of this is due, FWIW, to too much stuff being hard-coded, stuff which
one could adjust freely with commandline tools (such as Make), or in other
IDE's (such as Visual Studio).
possibly having to edit source and/or recompile is not good, I would at
least want most of the configuration to be in text files or similar.
Lew said:
What does GIMP have to do with Java?
BGB:
well, it can edit images, and images are often used in apps, but
photo-editing is typically not supported by IDE's [sic] ...
Red herring.
strict IDE'ism would demand a person not use GIMP because it is not part
of
their enshrined "integrated" environment...
IDEs are a tool, not a religion, and "integrated" doesn't mean
"universal".
the usual IDE endorsement is that it does everything...
it sort of defeats the "idea" of an IDE if many tasks still require external
apps or tools...
Does VS support image editing?
yeah, but it is in the form of a tool along the lines of MS Paint (simular
UI and abilities, but integrated into VS).
for more elaborate graphics, one will still need a tool such as GIMP (or
Photoshop...).
3D modelling software also tends to be "integrated", but to a much worse
extent...
the people who make 3D modelling tools have an aversion to using a number of
tools which interoperate by using common file-formats or data
representations.
much like photo editing, some kinds of software also require making use of
3D modeling and animation, but these would not be reasonably provided by a
generic IDE...
OTOH, most "content creation" apps make it awkward to work with data in a
form usable to ones' own apps, as it is sort of assumed I guess that
everything which will be done on a 3D model or scene is done via plugins
into their "glorious" application.
more so, nearly all major commercial 3D modeling programs are now owned by
Autodesk (3DS Max, XSI, Maya, ...). because I guess they like buying out
their competitors...
with something like Make you can plug these things in easily...
typical IDE interfaces focus more on high-level "tasks" and offer less
flexibility WRT defining new tasks, or plugging ones' own tools into
existing tasks.
consider, what if one wants to use their own custom programming language
and/or compiler in a pre-existing IDE along with the stock compiler?...
typically, this is not allowed or is not easy to set up...
not that an IDE couldn't do this, but some things would be different, in
particular, one would need access to a much lower-level view of the build,
namely, in terms of sending particular files through particular tools, with
adjustable commandlines, ...
granted, MSBuild / Ant / ... can (presumably) do stuff like this, but
typically (as in, the ones' in which I am familiar) one can't customize this
directly via the IDE (one instead creates custom files, and maybe edits the
'project' some, ...).
(and one can use MSBuild and Ant via the commandline, ...).
it sort of defeats the purpose though if one ends up falling back to good
old Make...
Lew:
My point isn't that one can't do it outside the IDE, but that one can
inside.
and my point is that one doesn't particularly need an IDE to do these
things, as a good collection of 3rd party tools also works well, and that
even the things outside the IDE (commandline, ...) are not nearly so
terrible as people make them out to be.
for example, repeating a build in the CMD prompt is often:
down, enter (often to repeat the call to make);
down, enter (in this case, typically relaunching the app).
this is not much different than the GUI-based 'F5 to run' (or whatever else)
option, in terms of practical use.
(in Bash it is usually a chain of up's, followed by enter).
it would be worse if I were endlessly having to re-type these commandlines,
but one does not.
Now you're talking sense!
yes, ok.
well, I have not been sitting around here advocating complete abandonment of
IDE's, rather, that they are not some panacea of one-stop
does-everything-in-one-place project development either.
it is just a frustration to me personally that many who make tools, design
them imagining that their tool is such a "one-stop-shop" (and so make little
effort to support the possibility of a world outside their tool, or using a
"mix and match" strategy to get the job done).
granted, this problem is much worse with larger-scale "content creation"
tools than it is with IDEs...
or such...
