Re: Great SWT Program

On Sep 22, 4:57 pm, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
"Assume you're lying"? No. I'm just very skeptical about whether,
if I knew the whole story, I'd agree with your assessment. And in
truth, even if you were to share details, I wouldn't feel confident
that I was hearing all sides of the story. I don't accuse you
of deliberate lies. But we've established on many occasions that
the way you perceive the world is different from how I perceive it.

If that is so, then it is not I who is perceiving it inaccurately.

It may be asking for trouble, but it's not that easy to avoid in
the setup at my current place of employment, in which we have a
couple of dozen Linux systems sharing a password/file/etc. server.
Users' home directories, which is where the configuration files
live (where else?!), are shared by all machines. When we do
the yearly software (and sometimes hardware) upgrades, it often
happens that there's a period of some days or weeks during which
some of the machines are running the old stuff and some are
running the new stuff.

Ultimately it still results from the old version and the new version
trying to share files. If one looked for ~\fooSoft\1.1\foo.rc and the
other for ~\fooSoft\2.0\foo.rc, they wouldn't collide. (The new one
also wouldn't inherit the old one's settings without the user
importing them manually, but it would apparently save a lot of
headaches too!)

Alternatively, either the config files could be local to the machines
with the software binaries, or the software binaries global with the
config files. Centrally storing the config files without centrally
storing the binaries is probably asking for trouble regardless. Since
central binaries means the machines all turn into paperweights if the
network goes down, locally installing the binaries makes sense, so
local config files also make sense. Central storage of user documents
still makes sense if users need to access them from multiple machines.

Of course, some config settings will be user-variable preferences. In
that case, they may need to be centralized anyway. And then there
should be different ones for different versions as initially
described.

I have multiple versions of one tool over here (GTKRadiant, a 3D-game-
level editing tool; versions 1.2ish and 1.5ish IIRC) but they are
installed in separate directories, each with its own copy of its
settings files; they appear not to clobber anything important
belonging to one another.

When you say "settings file", do you mean a system-wide file, or
a per-user file?

There's no distinction in this case; it's a single-user machine.

Yeah. Lack of a consistent interface is a problem, though again,
I think there's more commonality than your description suggests.
I doubt we're going to agree about that, though.

The only commonality I recall observing is that they all deviate
equally from standard user-interface guidelines, key-bindings, and the
like. Ctrl+C is never copy. F1 is never help. F3 is never search. Page
up and page down never actually do what their names describe.
Backspace and delete may or may not work. Arrow keys may or may not
work. The mouse may even work, on a GUI-capable machine, but often
won't do squat. The alphanumeric keys, space, and enter can actually
be counted on to do the expected; function keys and page up/down can
actually be counted on to do nothing; Ctrl+C can be counted on to be a
quit command (instead of a copy command); and that's about it for
commonalities, in my experience. With each other or with typical
Windows or Mac software (modulo command/option for alt/ctrl in the
case of Mac software). Even the GUI apps have niggling little quirks
with e.g. minimize behavior or (especially) focus change/tab order.
Drop down menus, input fields, and even the simple check box usually
offer up some surprising or nonstandard behavior some of the time.

Of course, it's not like Windows software is perfect. The behavior of
Home and End is pretty random -- sometimes Home does the expected
(jump as far as possible left) and sometimes it instead acts as a
super-Page Up, for instance. Focus behavior isn't perfectly consistent
either -- overlap two Explorer windows with files in two columns in
each one, half-overlapped so the right column of window A overlaps the
left column of window B, and try to drag a file from the right column
of window B to the right column of window A. Sometimes clicking on the
file in window B brings that window to the front, hiding the intended
destination, and sometimes only releasing the mouse button while still
in window B will do so; it seems to behave somewhat randomly. Once in
a while a control will behave egregiously badly -- attempting a common
and typical operation fails in dramatic and broken ways. I've seen a
combobox in one app frequently spectacularly screw up apparently due
to a broken implementation of autocomplete: typing anything that
started with the same letter as any autocomplete entry and hitting
Enter would enter the wrong thing, because on the first letter it
would drop down the autocomplete list and then decide later that your
enter keypress was to submit that instead of what you'd actually
typed. More usually, if you keep typing and diverge from the items in
the autocomplete history it will accept what you actually typed, but
in this one case anything that triggered the autocomplete drop-down
had to be typed in, but then submitted by mouse instead of Enter
keypress to work. Sometimes text fields respond to tab-home-type-some-
stuff by replacing everything originally in the box instead of
prepending the new typing, usually those that auto-select everything
on focus. Hitting home should jump to the start of the text field and
deselect everything but doesn't always in particular cases.

Nevertheless, such behavior is the exception on Windows. On Unix GUI
apps (and Windoze ports of same) it's the rule. And when it comes to
console apps, the only exceptions to "anything goes" seem to be a few
places that strictly and consistently depart from standard Windows/Mac
usage, unfortunately including the standard help key and two very
commonly used and useful standard navigation keys.

And this doesn't happen in GUI tools? I hear these stories about
MS Word .... (Yes, I have used the program, but any time I have
to do more than very simple things with it, I very carefully go
through all the options/settings menus I can find and turn off
most of the auto-this and auto-that, so I'm not sure I've really
ever gotten the full "Word does weird things!" effect. As for
why I do that .... When I was first presented with a Windows
system and, um, "strongly encouraged"? to use Word, I realized
pretty quickly that I wasn't going to learn it very well by just
trying things. So I bought a book, and the book started out by
telling me about all the wonderful auto-whatever features, and
after I stopped making faces, I figured out how to turn them off,
and .... But I digress. Or do I?)

Word is not the best example, because of the 800-pound-gorilla effect
that kicks in whenever Microsoft is involved. I doubt you'd have had
this trouble with Notepad (even though that's also of MS origin!) or
OO Writer.

As opposed to being sunk a little later .... I think one of the
things that annoys me about GUI tools is that they somehow give the
impression (to me anyway, and I don't *think* I'm alone in this)
that anyone can use them, even to do tasks they don't understand
(setting up networking, say, or working with a CVS repository in
Eclipse [*]).

I'm not sure what this means. It's certainly not the case that anyone
actually CAN use them even to do things they don't know how to do,
unless the tool can completely automate the process and autodetect
everything, which is rarely the case.

It is often the case that they remove needless complications and bring
related things together in one place -- setting up PPPoE involves
filling in a "questionnaire" detailing the things that are actually
parameters of the process, and the computer does all the rest, instead
of the user having to separately find and hand-hack half a dozen text
files in cryptic machine-readable formats according to arcane
instructions that cannot actually be located anywhere, but nonetheless
apparently exist, if only in the system's designer's head
someplace. :)

[*] Something I've been making off-and-on attempts to figure out,
and -- well, maybe if I read through all the online help carefully
I'd do better, but just dipping into it, mostly what I get is
a sense that somehow they're trying to express not-that-simple
technical ideas in non-technical language ("team", "share project",
etc., etc.). Clearly this is a case in which background reading
is needed, but .... Well, I digress again.

It may be a case of them having tried to dumb-down something technical
and not actually amenable to being dumbed down. The error at the
opposite extreme from excessively sophisticating-up something basic,
such as, say, text editing, until it comes to resemble rocket
science. :P

Setting up CVS can probably never be simplified to "just push this
button and away you go". On the other hand, text editing should
probably never be complexified beyond "just push this button and type
into the box, and navigate and such in the normal way" ...

Your point about a guild mentality is all too true; I rather *like*
the feeling of being part of a somewhat exclusive club, but I'm not
sure that's really something to boast about.

Not more powerful is the Dark Side; but more seductive it is. But once
you start down the Dark Path, forever will it dominate your destiny!

Then again, it seems
natural enough to be a little smug about being able to do something
not everyone can do. Write Java programs, for example. :-)?

Sometimes it's something "naturally difficult". Actual programming,
for example.

But it seems screwy when it's something "artificially difficult".

It's a big accomplishment to climb Mount Everest. On the other hand,
it's still damned stupid of anyone to decide unnecessarily to locate a
7-11 way up there where almost no-one can reach it.

It's a big accomplishment to program complex software yourself. On the
other hand, it's just plain brain-damaged if some text editor,
newsreader, or whatever basically has to be programmed in its own
idiosyncratic scripting language just to use the darn thing, instead
of getting out of the way so the user can get their *real* work
accomplished.

Some game software makes the same sort of mistake, I find. Certain
RPGs particularly. You end up with "work" to do to, say, generate a
pile of ammunition or money or something, only to get pestered by
random encounters when you're "at work" instead of actually off
adventuring or whatever. :P

In a way, it's even like a sort of spam. It's intrusive and unwelcome.
You want to check the latest posts at some webboard or browse for and
download some file or find and read some information, and every other
mouse click leads to a popup or three, every other link seems to
gratuitously go via a "splash page" covered in ads instead of directly
to its nominal target, and no page at all isn't plastered with
animated GIFs and Flash. Needless to say, you get Firefox and adblock
or you go insane.

Unix tools seem to have a different motive, if they have one at all,
but again the interface (or lack thereof) intrudes on your simply
getting on with your task, whatever that may be, and keeps you
conscious of the interface itself. Most of your attention and thought
ends up being focused on how to navigate the interface. Generally with
exactly zero visual cues with which to navigate, too -- they subscribe
to the "drop people blindfolded into the middle of a hedge maze"
theory of navigation and interface design. Usually having selected
flora on the basis of having eight-inch thorns, since obviously a
blindfolded person will be unable to appreciate colorful flowers and
foliage! Regardless, it's hard to focus on (let alone be very
productive with) one's main task when one is constantly having to
concern themselves consciously with the interface and, often, what
passes for the help file. Instead of "editing text" or "reading news"
you're "using vi" or "using trn" or whatever, as determined by your
attentional focus. It doesn't become transparent and get out of the
way. If you find "using vi" fun or challenging that's one thing. If
you just want to "edit text" on the other hand being forced to do so
is liable to get very annoying very fast.

Well .... It's not that you don't have a point; you do. But for
some tools I'm willing to accept a certain amount of novice-hostile
behavior if I get expert-friendliness in return. I think. I'm not
sure when I last had to get up to speed with such a tool ....

The problem being that you really *can't*, save perhaps with a live
tutor, as near as I can figure. Unless you designed it to begin with I
suppose; then you'll know it inside and out. Often that seems to be
necessary; knowing the internals instead of just the problem domain
seems necessary to use a lot of that software. In some areas that's
more or less unavoidable; those are the very areas where you say GUI
tools keep coming up short (network configuration, etc.) but even
there a proper GUI tool can streamline the process and organize it
visually into a series of parametrized steps (the "setup wizard"
design, at setup, and a tabbed dialog at later times when changing
something), as well as provide a specialized editing tool (that
dialog) that does validation and gives immediate feedback in some
areas. Hand-hacking the config file(s) versus using a well-designed
such tool is akin to using a plain text editor on a Java file versus
using Eclipse, with its on-the-fly linting of the code and
autocomplete capabilities. Only more so, since usually there are much
tighter constraints on what's valid, and what you're entering isn't
Turing-complete! Just numbers with certain range limits, etc.

The other thing I like about configuring by editing text files is
that *you know where the configuration information is stored* --
so you can back it up before making changes, and it's potentially
much easier to track what you actually did than if you were
pointing and clicking through menus. Or that's my mileage, anyway.

This is a point, but it points more to an issue with common GUI
implementations of such things than with the GUI concept. The GUI
configuration editor could tell you where the file is, or even provide
backup/rollback functionality directly. That they often don't is
shoddy, I must admit. Of course there are tricks -- use the
configuration editor and then search system-wide for files modified in
the last five minutes right afterward and you'll probably find it in
the small number of hits; if not, it's probably using the registry
(ick). Ordinary Joes shouldn't have to resort to such tricks of
course. Again a problem of implementation, not of concept.

Well .... I don't know. I'm not sure there's such a huge
difference between looking through a manual and pointing and
clicking one's way through a lot of menus and tabs.

There is, if the latter is well-organized; finding something in a
linear text is O(n) versus O(log n) for a tree structure. (This
assumes a printed manual, or a help system that lacks hypertext/search/
etc. functionality, or in which such functionality is nontrivial to
discover and use; the usual situation with unix documentation, IOW.
Search also suffers from the possibility that the document is not
written with searches by n00bs in mind; if the solution is described
purely in solution-domain terms without a good description of the
problem it solves in problem-domain terms accompanying it, it will not
be found by someone who doesn't know the solution, but only knows the
problem; it will be found by someone who remembers part of the
solution or the gist of it and needs to retrieve the details, which is
the only target audience typically considered by unix documentation
writers, unfortunately. Put more simply, people search for the
question, not the answer, and if the answer appears somewhere but not
right after the question...)

And don't get
me started on the little icons. Which one does what? Who knows?
Sure, put the mouse over one, wait a few seconds, and probably
some moderately explanatory text will appear. That wasn't the one
you wanted? Move the mouse, wait a few seconds. Move again, wait.
Maybe you get used to it.

Generally, the ones you use you learn to recognize, and they take up
less space than text menus would (and as a result, can be right in the
main window instead of needing an additional menu-title click to
reveal first). The images should generally communicate what they do.
They don't always do it very well. Many have been standardized to some
extent (cut, paste, new, open, print, etc.; browsers' back, refresh,
home, etc.) but many have not. This area may mature further in the
future. Again many apps admittedly could use improvement. At least you
*can* browse the available functionality and find stuff, and once you
know where something is find it again very easily, without resorting
to the help!

You do? Once again I think we must be talking about different
software. Example: the (in)famous two modes (insert and command)
of vi. "Real" vi (and vim in compatibility mode) doesn't provide
any cues about which mode you're in, which is the situation
you describe. But vim (in its default mode) does, with the text
"--INSERT--" at the bottom of the screen when you're in input mode.

One case in which they fixed the "bug" it seems. There are surely lots
of other places where that sort of thing is still extant. There's only
so much information that can be displayed at once on an 80x24 text
terminal, after all; within the constraints of the older display
devices (and emulations of same) there's limited real estate to spend
on keeping the user oriented.

Emacs (some version or another) certainly provides some issues along
similar lines -- with no tabs/taskbar/analogous structure, for
example, and no Windows menu, there's no way to see at a glance what
documents are open. Just the one or two you see, or several dozen
more? Who the hell knows? There's probably some way to rotate through
them all, but it sure as hell ain't ctrl-tab, and opening the help to
find out what it is will alter the very thing I'm seeking to measure,
since the help doesn't open in a separate system-help-browser
application...

It can also be in the state of a long meta-sequence being half-
entered. (Windows apps admittedly suffer from the equivalent problem
fairly often -- if they think alt has been tapped, subsequent keyboard
entry may unexpectedly trigger menus or annoying beeping instead of
working as expected.) The upside is leaving the app with such a thing
half-done is uncommon. And at least Windows lets you back out of this
state with one ESC keypress. Emacs as I recall seems to do nothing
until you hit ESC a few more times, and then beeps and prints
something like "Unrecognized command: M-Esc Esc" or some such. :P

Browser-type programs too: they may be navigating line-by-line or link
(or occurrence of search term) by link, and it won't be obvious which.

GUI apps have a big advantage here in that when there are modes, they
can be indicated by changing the mouse pointer in a communicative
manner. Paint program tools are the obvious example, though the
toolbar's depressed button also provides a visual cue.

Of course, the worst unix offender of all time has to be the shell
itself, rather than vi, emacs, or anything else. For a long time, at
least, the standard was apparently to display a completely rudimentary
shell prompt with no indication whatsoever as to where you were in the
filesystem. Contrast

C:\Dir\Subdir>_

with

%>_

Which is more useful here? Of course you could configure the unix
prompt -- if you could find out how from the help system. You could
get some information with "cd" or see if you were somewhere
recognizable with "ls". Puts me in mind of fumbling around in a dark
house with a flashlight looking for the light switch. With large and
heavy pieces of furniture here and there about the place. And the bulb
in the fixture probably burnt out. And on attempting to replace it,
finding that it doesn't have a standard screw base at all, but some
kinky mechanism with a half-dozen pins and clams that have to be
worked with tweezers. In the dark. With the tweezers located at the
other end of the place somewhere, with miles of darkened hallways and
treacherous staircases to traverse in the dark to reach them and
return with them. Oh, and in case I forgot to mention it, all of this
has to be done in the dark, and the batteries in the flashlight seem
to be going dim. :)

(Admittedly, old DOS versions defaulted to a useless C> prompt barely
conveying more information than %>, but DOS fixed that a lot sooner
than I recall unix of any sort doing so!)

Flow control in the terminals created another issue; something of a
trilemma. Say you had a text file displayed partially on the screen
with no visible prompt. What is it doing? Is it a) waiting for XON? b)
waiting for you to hit space or down-arrow (but surely not page-down,
no, never would page-down do the obvious)? or c) just plain hung? :P

I wonder, too, if what you describe might be something of a
YMMV thing reflecting different styles of thought or something:
What I'm thinking is that some people seem to have no trouble
remembering shortish strings of meaningless data, such as phone
numbers, while others apparently would have to work hard to do
that.

It's designing software to cater to the type of autistic savants that
can memorize *a whole damn phone book full of such numbers* and
remember exactly who each one calls that bugs me. The UI for emacs
appears to be designed for autistic savants, in particular. :P

One or a few such things is one thing. Forty thousand is something
else entirely.

GUIs have a clear advantage in usability here, all other things (such
as commonly-used-command-set size) being equal, because the normal
human brain is geared toward remembering place-associations and
geography. If you saw it once you can navigate to the same place
again. Our ancestors found this handy when they had to locate good
watering holes, bushes with various medicinal leaves and edible
berries, and other such useful things in their environment. Most of
those objects stay put; their locations are fairly stable on
timescales comparable to a human lifespan or so. Phone books and
similar such things have appeared, by contrast, in the evolutionary
blink of an eye. People cope with the primitive interface of the phone
system (and it is damned archaic; all we could do to improve it so far
was *touch-tone*?! Talk about legacy apps!) mainly because most of the
times they only have a handful of numbers they use at all often, and
of course they need to look up manually some directory entry somewhere
in every other case, which is annoying and tedious. The phone system
is in need of a major redesign; converging the phone into the computer/
PDA is likely to be part of any such redesign, and then it will be as
easy and convenient (and cheap, even at long distances, hopefully) as
email and the web, complete with bookmarking. (Speed dial? Address
books in cell phones? What a joke. Mainly due to the terrible user
interface forced on the designers by only having ten or twelve heavily-
overloaded buttons instead of a 101-key keyboard to work with in the
input-device area, and a tiny LCD screen or none at all for an output
device. Usually there's not even any way to make it "remember who just
called me/I just called and dial them whenever I hit autodial 1" or
something of the sort; you need to type the number in manually to set
it up. If it's a caller rather than callee you may not even *know* the
goddamn number. :P)

In my opinion, most of these advances are most helpful for tasks
you haven't done before or don't do often. For such tasks,
I agree that it can be pretty nice to be able to point and
click through menus rather than reading man pages and editing
configuration files. For tasks I do often -- and that's most
of what I use those text-mode tools for -- well, for example,
I find it faster to type ":w<return>" to save a file than to
click on a little floppy-disk icon.

I find it faster to type Ctrl+S than to do either, and *much* slower
to go traipsing through even a well-designed and familiar help browser
than to click on an icon. ;)

Common actions usually have keyboard shortcuts -- from the sounds of
it, shorter ones than unix tools. And then the menus and buttons
provide alternatives, for when you don't know the shortcut yet or
forgot it. Menus usually indicate the shortcuts of items that have
them. Shortcuts for generic, domain-independent actions like "save"
are standardized (e.g. Ctrl+S, and Ctrl+A for save-with-new-name)
instead of idiosyncratically different per application. Shortcuts are
generally control+something chords or else alt, x, y, z sequences and
never clash with potential ordinary-typing keystrokes or other usages,
barring a few applications that have no ordinary typing involved in
their normal use (text fields in dialogs notwithstanding), so mainly
graphics-editing tools.

Of course, sometimes there's an action that while commonly done
annoyingly lacks a short ctrl+X type shortcut and only has a longer
alt, this, that type sequence, and rarely something fairly frequent
requires working with a dialog to do. These just show that poor UI
design can happen with GUI tools as well. Even then, GUI tools at
least offer the poor user much more scope for recovering from these,
and from the user's own goofs such as may occur! Sometimes the user
may be helpless to do something really quickly, or to fix things
easily after an error, but they're much less likely to be helpless to
do/find something at all, or to even know what went wrong after an
error.

But the occasions I'm vaguely remembering -- and it's altogether
possible I'm confusing Eclipse with another IDE (Together
from Borland) -- did not result from attempts to operate on
configuration files with other tools. I'd be happier if that were
possible, but before attempting it I usually make a backup copy of
the -- well, with Eclipse usually the whole workspace directory,
since I don't really know where the configuration files are kept --
and if things go wrong with the "edit outside Eclipse" experiment,
I'm apt to conclude that it's not going to work, and just replace
the messed-up workspace with the backup.

Smart. As for where the configuration files are kept, you can probably
find out from the documentation or by just poking around and
exploring. The good news is that for most ordinary purposes you don't
actually *have* to. Contrast that with just about anything unixy I can
recall running across...

As for how they got hosed, if you kept diligent backups of config
files and restored them at the first sign of trouble, and this didn't
fix/avert the disaster, I'd guess it was a bug. Made by Borland.
Eclipse just doesn't seem to be prone to that kind of thing.

Bugs happen. I am fairly certain they are not exclusive to Windows
software, if perhaps more common in Microsoft's own software than in
many other companies' or in open source. This could happen with a unix
tool as well, and if you don't know a whole lot about how and where it
stores this stuff and in what format, you're just as hosed. It's just
the unix tool probably won't even start and function normally until
you've already learned that stuff and acted on it in some particular
way; Windows tool users tend to have the luxury of ignoring such
details until and unless something stops working and only then having
to worry about what's under the hood.

Cars used to require hand-cranking some gadget under the hood to start
the engine, as I recall, but obviously now there's a control in the
driver's interface area to do this instead. Only when they break down
is it now necessary to fiddle around under the hood, or get out and
push or something. Software on the other hand seems to be where cars
where in the early 20th century -- around when this sort of thing was
just changing over. Only with some makers already having introduced
automatic gearshifts too. I guess software and computing develops
faster, but older models have about the same turn-over curve, with ten-
plus-year-old models still being driven in not insignificant numbers
in both cases.

It's not the mouse that's unreliable; it's me. I find keyboard
navigation is almost as fast (especially if I can get to the
right spot with a search), and much more reliable -- getting
the cursor placed on precisely the right spot on the screen is
not something I do very well. More practice using a mouse might
help -- or it might cause me to know more than I'd like to about
repetitive stress injuries.

I don't find a GUI browser provides any disadvantage there. You can
still arrow up and down, and (ugh) search; you can also use the scroll
bar to jump to a proportional place in the document (e.g. 1/4 of the
way down) in a consistent way, and to page up and down, and simply to
*see* where the hell you are in the document and get a gauge of how
big the document is. And you can jump within the portion displayed,
using the mouse, to select any area by hand. Even click in vicinity
and hit arrows a couple times is much faster than hit up-arrow 17
times, right-arrow 43 times, then shift-right-arrow 21 times...

And of course you can move a page at a time with the keyboard in a
consistent, natural, and reliable way with the page up and page down
keys. Space also works. But there's no more "how the hell do I go up?"
issues -- "is it -? backspace? just quit and start over from the top,
even?!" And search is, as it should be given the typing and target-
specific actions involved, a last resort. Particularly as using it to
navigate within a document is limited to what you've already read in
detail, and, with reduced usefulness, what you've skimmed. If I want
to jump to the bottom of a document it's easy with a scrollbar and
mouse. How do I do that with search unless I've read the whole thing
before and memorized some likely-unique phrase near the end? Also, if
you get the search slightly wrong you go nowhere. If you get the
mousing slightly wrong you end up near where you wanted to go and it's
easy to nudge it the rest of the way where it should go. The GUI way,
you miss your exit and take the next and circle back and get there a
bit later. The unix way, you miss your exit and the next exit is
somewhere between Omaha, Nebraska and fucking Timbuktu, or even a
great-circle all the way around to back where you started from. :P

That (ton of reference information) might actually be helpful.

Sure, but if you're looking for concise information regarding "how to
do X" it's not helpful for that particular task. Reference material
and tutorial material are by their nature fairly different from one
another in content and structure. Consider javadocs. Those tell you a
great deal about specific library functionality but do they help if
you want to know how to compile? The fastest way to store references
to a bunch of Foos and remove the duplicates? Nope -- the one is
completely outside their scope; the other is documented with Set and
HashSet in particular but there's nothing in the front page view of
the docs that would naturally lead a querent there who didn't already
have at least passing familiarity with Java, and with the java.util
package in particularly. And though you could in theory answer that
question and learn a lot more besides by reading the whole shebang
from cover to cover, who but the aforementioned autistic savant is at
all likely to even be *capable* of doing so without going bat*** long
before they were done?

Fortunately there's also Sun's Java tutorial and other material geared
toward n00bs or specific how-to questions. (And this newsgroup, and
google).

Point being, reference material has use within a certain scope, but
sometimes the vendors of certain software products fail to provide
anything with use beyond that scope. Sun doesn't seem to be among
them, fortunately.

What make me rant is "help" that tries to express technical
concepts in non-technical language. Eclipse's explanation of how
to work with CVS repositories comes to mind.

This can be an issue. It's probably trying to be both of the above
types of help at the same time, and failing at both. Badly-written
help is unfortunately not that rare, any more than is completely-
missing help (of one or both types).

I don't find it difficult to remember the keystroke combinations
I use regularly, and for stuff I don't use regularly -- it's hard
to be sure, but I don't know that having done something with a
GUI makes it easier for me to remember -- I think I'd be more
apt to just remember that the task can be done and there's a menu
*somewhere* (possibly not in the same place it was the last time
I did the task -- GUI designers seem to like to tinker with this
stuff from release to release.

Rearranging things in the GUI from one version to the next is indeed
objectionable. Ideally there would be separate interface
versions/"deep skins" (that go beyond looks to things like control and
menu organization) and engine releases, and you could choose to
upgrade only the engine. Software architected as I suggested earlier
in this thread would have this occur naturally.

On the other hand, your own complaints about old and new versions of
something puking when forced to share one copy of the configuration
file indicate that the unix equivalent of your GUI-software complaint
does occur -- they gratuitously change something and make the format
of some file or another not forward- or backward-compatible (or even
neither).

This is something else I like about a command-line / text-files
approach to configuring things -- there's a better chance that,
for something you don't do often but have done successfully at
least once, there will be a record somewhere of what you did,
so you can repeat it. (Or if it didn't work, a record of what
you tried.)

That sounds to me like it would seem more useful in theory than it
would prove to be in fact. First, this "record" would take the form of
a copy of the configuration file with the change you made. This is
likely to not exist, as it's likely to have been clobbered by the next
change; certainly you're implying something was changed, then changed
back, and now the user wants to change it again. If they backed up the
file when they made the change back, the backup when they changed
something else later on is likely to have clobbered THAT copy. And
even if a copy survives, an old copy of some obscure configuration
file gathering dust in a now-disused corner of the file system is
likely to sit there for eternity, being copied now and again when
everything is migrated to new hardware, and perhaps also onto numerous
backup discs or tapes, without ever again being seen or noticed by a
human being. Finding it would require guessing that such a thing
existed and then searching for it. Probably manually, since automated
search only works when you have a good idea (including some exact,
accurate text strings) what you're looking for, and in this particular
case if you remembered what was in the file you wouldn't need to find
it anyway! And, of course, once you DID, by some miracle, find it,
what you DON'T have is a diff between the two versions showing exactly
what you'd changed. And of course any tandem changes to other files
won't be apparent. If you recreate what turns out to have been only
half (or a third, or whatever) of some previous change instead of all
of it, you'll probably just hose the system thoroughly. Backups
certainly seem warranted; too bad you can't do anything with them if
the machine won't even boot now, or the partition with the renamed
copy of the last known-good configuration is the one that now refuses
to mount, or whatever.

That's like putting the little numbers onto a formerly-blank stick
shift instead of noticing that a few decades ago they invented this
nifty thing called an "automatic transmission". :P

I think you won't be surprised to hear that I rather like stick
shifts too.

No. Unix and stick shifts both cater to the sort who like to
micromanage everything instead of just getting on with the job at a
default coarse granularity and only getting nitty-gritty when there's
a problem or exception of some sort.

In funny ways they both automate one thing and don't automate the
other. Unix stuff is much more amenable to automating particular data
manipulation tasks and whatnot, but forces the user to micromanage the
system and, basically, *program* it to do anything (with a large
library of pre-existing subroutines at least -- if not one with
anything as comprehensive and easily navigable as Java's javadocs PLUS
tutorial to guide you through it!); if the user wants a single common
task to be done by hitting a single key, they need to program this
behavior in first! Windows and its ilk on the other hand far better
automate the user's tasks of finding their way around the system and
making it do things, but do a poorer job of supporting automating the
things themselves.

For example, rename a huge batch of files to add a "foo_" prefix.

Unix (command-line): Getting to the files is a chore, and a long
arcane command must be typed to rename a file once there. However,
this command can be generalized or a script file easily used to rename
the whole lot in one shot.

Windows (eschewing use of a DOS box): Getting to the files is easy and
renaming one is as simple as click, f2, type new name, enter. However,
renaming the whole lot entails click, f2, home, "foo_", enter, click,
f2, home, "foo_", enter...

Windows (with DOS box): Find the files easily. Select path of
directory from a text field at the top of the Explorer window. Open
command prompt, put in "cd " and paste, and there's a long arcane
"for" command that can be typed to do the batch rename.

Windows, no DOS box, don't care about the new names *except* for the
prefix: select all of the files, hit f2, and type "foo_.ext". Result
will be foo_.ext, foo_ (2).ext, foo_ (3).ext ...

Unix (with some X WM): Probably allows a Windows-style ability to
navigate to the files and rename one of them easily by hand without
much arcana.

It seems the GUI systems support both automating at the UI level and
automating at the data manipulation level, but not at the same time.
The non-GUI systems only support automating at the data manipulation
level.

There's a lesson here. Perhaps that we need a kind of visual or
gestural language capable of the rich semantics of a scripting
language.

AI software was demoed a few years back (as a Java applet!) that could
draw analogies between two sequences. Perhaps this kind of AI is key:
a user could rename a few files with "foo_" prepending and then hit
some "automate" key. The system will then examine the last few user
actions and look for a pattern. The last few commands were file
renames. The sequences of old and new names, side by side, have a
discernible analogical relationship in that they all differ pairwise
in an algorithmically-specifiable way -- one single algorithm can
generate the output sequence from the input sequence and isn't just a
lookup table. Ergo, show the user a preview of the results of applying
this to the whole available scope; the directory containing all the
files the user just renamed. Perhaps the user renames a few files and
hits say F9, and all the other files' names change to show a
differently-colored "foo_" at the start. The user can scroll around
and such. If they go to take any other action in that window they're
prompted to accept or reject the changes. (Until then it's dimmed to
indicate it's all temporarily read-only.)

Of course this could screw up in some subtle way. So can "replace
all".

In the specific case of batch renaming, in fact, it's probably the
same thing under the hood: the analogy-discovering part outputs a
regular expression representing the change in a parametric way, which
used as a regexp replace would have transformed all of the original
names of the renamed files to their corresponding post-rename names,
and isn't just a lookup table special-casing each one.

In other situations, particularly with non-text data being
manipulated, it's going to be something more general, though a lot of
the times it might still be the case that the output "script" can be
treated as a finite automaton working over some kind of regular
grammar in some symbol space.

How would binary search be useful anyway?

To find something in alphabetical/whatever order, given the absence of
a (known) way to automate the search, but a way to scroll decently
rapidly through the document.

And I thought everyone knew that to search for text you type "/"
and the text .... Sort of a :-).

Yeah, when it's not ctrl+S, or ctrl+F, or M-x s, or alt-Q, or control-
shift-J, or ... (but rarely ctrl+F, and *never* F3!)

Not that it would be quite so bad if it weren't both not documented in
any obvious place nor readily discoverable by any other means. It's
often not obvious that any kind of search is supported. Honestly, even
on DOS I find most text-file-echoing things to be very clumsy to use
for anything but linear reading of very short documents. Notepad on
the other hand does quite nicely -- you can see where you are and how
big the document is at a glance, you can move around at any speed and
(since Windows 95) you don't even have to do so blindfolded as it
visually scrolls as you go; you can search, of course, and if you
don't yet know that it's *universally* accessible via ctrl+F and F3,
you can use the menus to both find out and actually do a search; and
of course plain old up- and down-arrow work, and (*gasp*) Page Up and
Page Down too! There's no shortage of navigational options, both
mouse- and keyboard-based. If you still can't find your way around the
document, it's either fucking huge and too undifferentiated for search
(what is it, a logfile, and you're not looking for something
exceptional even???) or you're as blind as a bat or as dumb as a
post. :)

There is still a 500-page manual with no page numbering.

For a stick shift?

For a Unix app. If it's anything whose functional domain is at all
complex (e.g. server configuration or 3D dataset manipulation rather
than, say, mere text editing or file renaming) it's going to be 1500
pages or more. :P

Talk about a word that pushes my buttons! Do you know the
oft-cited remark about how the only truly intuitive interface is
the nipple, and everything else is learned?

Consider it shorthand for "you can actually see what the hell you're
doing and where the hell you are, and what tools are sitting on the
workbench in front of you" then. :)

Actually I think it *is* true that what you learn from operating
one typical GUI application is apt to make the next one seem
more "intuitive". But I claim that the same is true of the old
text-mode applications as well.

Doubtful, since the only consistent rule among them all is
inconsistency -- aside from the absolute and inviolable ban on making
any kind of use of page up, page down, function keys, or (usually)
delete, and making ctrl+C quit rather than copy. :P


.

Loading