IDEs (Was: Mainstream D Programming)

[Bruce Adams]

Robert Fraser Wrote:

> Janice Caron Wrote:
> 
> > On 10/14/07, Ary Manzana <ary at esperanto.org.ar> wrote:
> > > Please tell me the steps you perform to do the refactor... Say, for
> > > example, you are renaming the name of a method of class A, and suppose
> > > there is another class B with the same method name (but you don't want
> > > to change B's method's name).
> > 
> > Change the method name, then recompile. The compiler will find all the
> > references using the old name, because they are now compile errors.
> > Obvious!
> 
> That works, but on an enterprise codebase where there could be 100+ references to that method, this becomes tedious.
> 
Use script foo.
 grep -l "error message" | xargs mysearchandreplacefoo.sh

mysearchandreplacefoo.sh

#!/bin/sh
for FILE in $*; do
  sed -e s/<oldName>/<newName>/g < $FILE > $FILE.tmp
  cp $FILE.tmp $FILE
done

Insert favourite scripting language foo in place of ugly old-fashioned 
Bourne shell. There's not much more than that going on under the hood of a lot of these fancy IDEs anyway. 
Okay the syntax awareness makes it a hell of a lot less ugly.

> I think the point is that IDEs, while not essential, can certainly do a lot of things that are helpful. For example,
> 
Absolutely.

> * Show exactly where in a huge string mixin an error occurs

Maybe the design would be better if the mixin were broken down
into brain size chunked chunks.

> * Show the particular instantiation of templates
> * Manage imports automatically, so whenever it comes across an >undefined symbol, you just need to press a button to import the >required module, not look up what module it's in, etc. Never write >another import statement! This could also improve code quality, since >you could make it only use selective imports and never pollute your >namespace by importing an "all" module.

You still have to read the documentation to know what other functions it interacts with. Otherwise you might end up mixing printf's
and couts using the facilities of two libraries where one might suffice.
That said. Having some kind of hypertext link to the documentation is really helpful.

> * Mark errors instantly (and have suggested fixes for some of them), rather than having to compile every time.
> * Automatically implement stubs for inherited abstract methods/interfaces.
> * Track TODOs, etc.
> * Show formatted Ddoc on hover.
> * Integrate debuggers to visually step through code.
> * Format source code
> * Autocomplete
> * Go-to definition (even across files)
> * Additional warnings and static analysis if you want them (for example, it could warn for "x == null" or integrate Coverity-like nulll checking)
> * Automatically organize/sort source code
> * Generate an interface or abstract superclass from the intersection of one or more classes' methods.
> * A "use supertype where possible," where all references to a subtype are changed to references to the supertype if they can be (encourages more modular code in a highly OO system).
> * Change "auto" to its actual type.
> * Move functions/classes between modules and automatically update modules that reference them.
> ...
I hope the IDE writers are ticking these off on their feature request lists.

The real power of an IDE comes through being able to script it. This is what made emacs such a success.

> 
> Anyway, the point is not that "an IDE is essential," and for smaller projects, it's arguably overkill, but for huge projects, it can be helpful.
> 
> I think one of the things stopping a lot of people from adopting IDEs >is this implicit fear of having to learn something new. There is a >learning curve associated with everything, and if you've been using >ed for the last 30 years, an IDE can be a scary place.

Its also about changing IDEs. When your own your own system you can usually pick whatever IDE suits you best but even in the 21st century, though it sickens me I occasionally find I have to use vi. I hate vi. vi is an abomination. It just happens to be the lowest common denominator sometimes. 

Your point also gets us back on topic as using D versus using C or C++ for the last X years is even more daunting a transition.

Regards,

Bruce