[OT] Which IDE / Editor do you use?

[Nick Sabalausky]

On Sat, 14 Sep 2013 02:39:05 -0700
"H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote:
> 
> 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..
> 

That's exactly why I hate CSS for layout.

Although I found Visual C#'s WYSIWYG GUI editor (and even MS's stuff as
far back as Visual Basic 3) to make it fairly easy to make things
adjust properly. Probably because Win32 (like other GUI systems) is
designed for things like docked widget containers and auto-resizing
main content.

That said, it does still make it easy for bad designers to do things
the wrong way. But then, the same is true for programmatic layouts.



> > > > - graphical representation of code relationships
> 
> std.d.lexer + graphviz
> 

I think another layer on top of graphviz might be needed for that to
really be comparable. I've played with graphviz's DOT format a little
bit and found that it often takes some thought and tweaking to make
non-trivial graphs that are particularly good (and not gigantic).

Plus, to my knowledge (I could be wrong), I don't think it has any way
to generate interactive graphcs - graphs that you can drag parts around
to make it look good. Just static images, AIUI.


> > > > - visual XML tooling
> 
> What would that be for?
> 

For indulging MS's XML obsession ;) j/k


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

I actually found it nice in Visual C#. Although I think it did
occasionally annoy me with complaints about stuff I was still typing
(unless I'm thinking of VB6...), and I definitely don't find it worth
the cost of occasionally laggy text-editing.


> > > > - map failed unit tests to code lines
> 
> Er... isn't that what AssertError line numbers are for?
> 

Yea. My code editor uses a (optionally customizable) regex to grep for
any "filename(line_number):" lines in the output panel. It converts
them to "jump to that line in the source" links. That'll work for any
tool, unittest, compiler, whatever. So this is not something that
requires a full-blown IDE.

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

Heh, I can go without it for short periods of time if I really need to.
(I already do any time I use my source-diffing program.) I'm so used to
it though, I find it very difficult to visually parse non-highlighted
code in anything that isn't a pure data langauge (and even then it
helps).

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

Yea, I use pretty much the same approach, although my proportions might
be a little different. I've become so accustomed to printf debugging
(a habit developed through too many situations where no real debugger
was available), that even when I should fire up a debugger I try to
push through with printf-approach anyway because "Ehh, I don't feel like
trying to remember how to hook this up to a debugger..."

Plus I've been dev'ing on windows, so instead of segfaults, D
throws an Error and gives me a stack trace :)

Developing in any situation (not necessarily D) where I *don't* get
stack traces is a PITA. Of course, printf debugging usually works there
too, but it feels much more painful when I'm thinking "Ehh, I have to do
this just because I'm not being immediately spoon-fed the stack trace?
This blows!"

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

Well, "be one with the commands" in that case ;) Or "be one with the
keyboard", which is still critical for me, too: I feel like I'm running
through sand when I have to code with a built-in laptop keyboard
(especially because of the lack of *proper* arrow/home/end/del/page
keys, but also just the overall size/shape/feel of the keys).

I really can believe what you're saying about vi. Personally though,
I just haven't felt much of a need or desire to really give it a
chance anyway. And (in a small way) I almost don't want to like it -
I'm already in the minority on enough things ;) Maybe I will someday
out of curiosity, I dunno.

The "counting words/chars/lines" in particular seems rather off-putting
to me though. Ex: I like to just Ctrl-Left/Right across however many
words I need and don't really want to start caring how many words/lines
away something is.