Re: Great SWT Program
- From: blmblm@xxxxxxxxxxxxx <blmblm@xxxxxxxxxxxxx>
- Date: 29 Sep 2007 23:03:28 GMT
In article <1191101393.662899.27960@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
On Sep 28, 7:36 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
[ snip ]
Basically, the "interfaces" I disdain seem to be precisely those that
pretend we're still stuck with 300bps lines and dumb terminals, which
imposed stark limitations on what could be done to keep the user
informed and oriented. Also it seems keyboards hadn't standardized yet
at that time, so apps supported the low common denominator of the
alphanumeric keys and some punctuation pretty much to the exclusion of
anything else. Overloading the alphanumeric keys for all kinds of
other purposes then produces crufty modes, and not having standard,
universally-available navigation-dedicated keys results in every app
using its own idiosyncratic bindings as a hack. Of course, the excuses
in question no longer apply ... inertia and nostalgia appear to be the
primary motivators for use of things like vi and trn these days.
Well, that and the fact that to some of us they seem more reliable
and predictable than the fancier tools.
But I do get your point about taking advantage of the greater
capabilities of current hardware.
As
for emacs, well, it's an okay operating system, I suppose, though
marred by its lack of a decent editor. ;)
More a shell than an operating system, maybe.
I'm vaguely remember an X version of gdb, but not curious enough to
find out whether it still exists (apparently not on the system I'm
using here anyway).
Gdb is for the birds. If the JVM crashes I'll submit a bug report to
Sun. *They* can fix it. As for bugs in my own code, Eclipse's built in
debugging capabilities are more than adequate, and you can actually
see WTF you're doing to boot. ;)
Well, debugging one's own code is what gdb is for, isn't it?
Admittedly the line-oriented version is pretty primitive by today's
standards, but if I remember right, run from within emacs it's
a little nicer -- you have a window showing source code, and a
window in which you can type gdb commands for setting breakpoints,
examining variables, etc., and the window showing source code
has a pointer indicating the next line to execute.
More than once I've tried to teach myself to use Eclipse's
debugger, but apparently there's just enough of a learning
curve that it can't be grasped in the tiny amounts of time I've
been willing to spend. Real Soon Now ....
But that learning curve -- it goes back to my point (made
elsewhere?) about things seeming intuitive after you've been
doing them for a while, but not being so obvious to the novice.
I'm sure I had trouble with -- no, actually I think gdb was fairly
easy for me, since I had used similar debuggers on other systems.
I don't remember whether the first one was difficult.
(Better support for debugging
threaded code would be nice. For example it doesn't auto-detect
deadlocks when attached to threaded code, though it surely could.
Being able to make a breakpoint that would trip the first time any
thread hit it but not be trippable by other threads until the first
one was resumed would be nice, too. Sometimes I resort to adding a
gratuitous if { ... } around a dummy statement with a breakpoint set
on it to make it conditional on arbitrary requirements, and rig it to
trip a specific thread only or whatever; of course avoiding using
conditions with side effects...)
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.
- Follow-Ups:
- Re: Great SWT Program
- From: nebulous99
- Re: Great SWT Program
- References:
- Re: Great SWT Program
- From: nebulous99
- Re: Great SWT Program
- From: blmblm
- Re: Great SWT Program
- From: nebulous99
- Re: Great SWT Program
- Prev by Date: Re: Great SWT Program
- Next by Date: Re: Pointer vs Reference
- Previous by thread: Re: Great SWT Program
- Next by thread: Re: Great SWT Program
- Index(es):
Relevant Pages
|
