[OT] Which IDE / Editor do you use?

[H. S. Teoh]

On Sat, Sep 14, 2013 at 02:57:39AM -0400, Nick Sabalausky wrote:
> On Fri, 13 Sep 2013 22:15:06 -0700
> Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> 
> > On Saturday, September 14, 2013 06:56:10 Paulo Pinto wrote:
> > > Am 14.09.2013 00:06, schrieb Jonathan M Davis:
> > > > .... The features that an IDE has that vim doesn't typically
> > > > just aren't worth it. e.g. if I'm stuck doing Windows
> > > > programming, about the most that I even do with VS is use the
> > > > debugger. I even build from the command line rather than open
> > > > the IDE.
> > > > 
> > > > Vim's learning curve is quite nasty, but I definitely think that
> > > > it was worth it.
> > > > 
> > > > - Jonathan M Davis
> > > 
> > > You mean things like:
> > > 
> > > - Semantic refactoring

This would be nice, but I would say if something like this is
necessary, then it means the code wasn't properly designed in the first
place. Code can, and probably should, be written such that this is
never necessary.


> > > - WYSIWYG design of user interfaces

Ugh. I don't trust that kind of design. It has a tendency to devolve
into programs that need screen resolutions with exact pixel sizes and/or
make unfounded assumptions about font dimensions. UIs should be
*programmatically* specified in such a way that they are logically
consistent in layout *regardless* of environmental factors such as
screen resolution, font dimensions, etc..


> > > - code navigation, even across binary modules (call graph, derived
> > > class, overridden methods, call sites, ...)

Ctags. ;-)


> > > - graphical representation of code relationships

std.d.lexer + graphviz


> > > - UML design

Range-based design is better. ;-)


> > > - visual XML tooling

What would that be for?


> > > - background compilation showing where there are issues

Waste of resources. I hate it when programs (including IDEs) try to be
"smart" and point out perceived problems that may or may not be real
problems. The compiler already points out the *real* problems when I
decide to compile the code anyway; having an IDE actively try to point
out the fact that my code doesn't look like code yet (because I'm still
thinking over various implementation possibilities) is very disruptive
to my thought processes.  I prefer to doodle possible implementations
until I mold it into possibly-compilable form first, *before* I even
consider running the compiler on it.  An IDE to consume system resources
while annoying me? No thanks. Let Clippy rest in his grave, don't bring
him back from the dead.


> > > - background static analysis while coding

ditto


> > > - code completation with documentation popups

I can live without it. Vim has 'K' to open the manpage of the identifier
under the cursor anyway -- one of these days, I'm going to write a
program to autotranslate ddoc into manpages, then I don't even need to
depend on dlang.org anymore. I find autocompletion redundant anyway,
since I still prefer to read the module docs thoroughly to know exactly
what something does before using it (*especially* if I don't know it
well enough to recall the exact name off the top of my head).

So it's a nice-to-have, but meh.


> > > - integrate source code control with task management software to
> > > track code changes to project tasks

An IDE is not a substitute for my learning how to manage my projects
independently of the coding itself. Besides, I've yet to find a task
management software that I can tolerate using. I usually just use text
files in a specific format that outlines tasks in a hierarchical format,
organized into per-task per-project directory trees, in which I keep all
associated data like backup files, crash logs, code diffs, etc.. All
these have very specific naming conventions and structures that let me
find stuff easily, and everything is plain text and greppable for when I
need to find a specific detail from an unknown past bugfix, say. I still
find grep -E more effective than any task management software's poor
imitation of the google search box.


> > > - map failed unit tests to code lines

Er... isn't that what AssertError line numbers are for?


> I find most of that stuff to be "nice, but not that big a deal" (and a
> few I just plain don't care at all). I used to be a big IDE guy, but
> I've done enough development on various immature platforms and
> ecosystems that I can get by just fine as long as I have:
> 
> - Basic editing that's solid, fast, robust
> - Highlighting
> - CLI compiler

For me, I can dispense with the second item. :) Give me vim and a
command-line compiler, and I'm good to go.


> I've had to debug things using as little as one LED. So printf
> debugging is perfectly comfortable to me, and I've gotten to the point
> where I even find it preferable to a full debugger in many cases.
> 
> The rest is just icing (or gravy if you prefer).

It's funny, the more years I spend coding, the less I found myself using
the debugger. Nowadays my debugging approach is approximately:

1) Code inspection: based on the bug description / known steps to
reproduce it, locate the general place in the code where the problem is
likely to be, and thoroughly audit that piece of code for problems.
Roughly 30% of the time, the bug would be found this way, and quite
often, other not-yet-found bugs would be discovered too. So it's quite
worth the effort before we even use any real debugging tools.

2) Printf/writeln debugging: mainly to determine execution path on the
way to the problem, by strategically placing printfs/writelns at branch
points and before/after loops, then refining it to loop bodies and
functions down the call tree as the location of the problem reveals
itself. Once the malfunctioning piece of code is identified, then start
to dump variable values, etc., to ascertain the cause of the problem.
This actually covers about 60% or so of the cases I've encountered.

3) Use a debugger. I find myself doing this only about 10% of the time.
And out of that 10%, 9% is just to get stack traces from segfaults, and
only 1% is really using the debugger for stepping through code.

All in all, writeln debugging is pretty effective, for all the stigma
against it.


> > I honestly find almost all of that to be useless or nearly so. The
> > only one that I'd actually be much interested in would be better
> > code navigation (particularly the ability to hop to the definition
> > of a function). And having poor code editing capabilities would
> > hamper me quite a bit. So, for me, vim wins hands down.
> > 
> 
> Yea, the basics of code editing are the real #1 thing. If I can't "be
> one with the cursor and text-edit control", so to speak, then no
> amount of extra features can make up for it. (Of course, for me that
> means *not* vi, although I just haven't cared enough to get through
> the learning curve - but that's just me.)

I utterly hated vi(m) until I actually tried learning it. Then I found
that the "be one with the cursor" approach is actually less effective
than vim's "describe your edits in a *language* involving verbs, nouns,
and adjectives, not just point and grunt" mindset. Nowadays, I actually
find other editors rather crude for my tastes. They're too focused on
the character-by-character motion of the cursor and the WYTIWAG (what
you type is all you get), whereas vim lets you speak to it in a far more
expressive language.


T

-- 
Do not reason with the unreasonable; you lose by definition.