Re: [PLUG] graphical programming environments on Linux

[gabriel rosenkoetter <gr@eclipsed.net>]

A disclaimer: I'm being crotchety. I'm well aware of this. There is
no need to point it out. Nor do I mean to suggest that anyone else
does or should code with the same tools that I use. Okay, now that
that's out of the way...

I've never been a big fan of graphical environments. I find that
most of them (including those popular on windows) are done so
hideously wrong as to hinder the development process. NeXTStep
shipped with a somewhat cute (and not *terribly* wrong) development
for Objective C... and even that ends up irritating me.

Maybe I've got something against the mouse, but it sure seems less
useful for data input than a keyboard. (It can send fewer than 10
distinct signals, depending on how many buttons you've got on yours;
a keyboard can send an order of magnitude more.) I actually feel
(as early Xerox PARC researchers did) that the mouse should be
nothing but a pointing device... that is, buttonless. I argue that
this only seems outrageous now because mice with buttons and wheels[1]
have become the standard: I say that, for someone unfamiliar with
a computer, having a device serve precisely one purpose would be
less confusing, not more so.

So, that said, I much prefer editing source in vi, in a regular
xterm (well, in as many regular xterms as I can fit in my X display--
note that I never said I was against a GUI, btw). When I want to
compile, that's done with an ex command, like :!make (or even just
:!cc -o foo %). When I want to debug, I'll either pop up a new xterm
or just do :!gdb foo. Replacing or moving around blocks of code uses
the standard vi editing tools. If I want to commit my changes to the
repository, that's just :!cvs commit (or :!cvs commit %). This is
getting redundant. The point is, my editor takes up very little of the
processor and memory this way (leaving that much more for compilation
and user interface), so I can run many instances of it without
problems (note that this is NOT true with sacriligeous crap like
gvim, which has all kinds of irritating X widgets and shared library
calls associated with it, defeating the whole original purpose of
vi).

For the extent of my time as an undergraduate CS major, I've
considered learning how to deal with emacs and using XEmacs (nee
Lucid Emacs), probably with vi-key-editing (habits are hard to
break) for large development projects, since I'm fairly certain that
it would be more efficient, once learned, for handling multiple
files and debugging all at once... but taking the time to learn
all of the fancy keystrokes necessary to create and use macros (or,
hell, to save and close a file... ^[ZZ is pretty damn easy to type)
has just never really seemed worth the effort.

This also probably stems from the type of code I write is almost
all OS stuff, mostly within NetBSD, never using goofy windowing or
other graphical libraries.

[1] The one really good use that I have yet to see a wheeled mouse
put to is the fully-3D window manager. I want to be able to move my
pointer left, right, up, and down using the normal mouse movement,
and scroll in and out of the screen using the wheel. I want the
windows to be translucent (ala Mac OS X, not ala Enlightenment,
which really doesn't do this right, and does a pretty poor job of
following up on Amiga OS to boot), and to be brighter the closer
they are to me. I'd like a small, cube-shaped representation of my
environment (like the 2D one in vtwm, if you've ever used it), which
I can click in to jump to a given window. This won't happen without
a windowing system that can deal with a 3D card (ideally GL-based)
at a really low, intrinsic level. I have hope that such a window
manager would be possible on top of Berlin
(http://www.berlin-consortium.org/), but that's pretty far from
done, last I heard.

Okay, I'm done whinging for at least three days now... ;^>

-- 
       ~ g r @ eclipsed.net

Attachment: pgp1pwLntcBcy.pgp
Description: PGP signature