Re: Great SWT Program

In article <1190751222.013883.184640@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:
On Sep 24, 11:36 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx>
wrote:

[ snip ]

If incompatible versions of applications used different names for
configuration files, this problem would go away. But apparently
many don't. And I've found this to be much more of a problem with
"modern" applications than the old-time ones where you configure
things by editing text files.

A lot of Windoze apps don't play very nicely with copies of
themselves, mainly due to registry collisions. One more black mark
against the registry. But it's no reason to be requiring hand-hacking
config files manually -- an app could ask you to name its install, and
use that name for its configuration files and other stuff.

Sure. My point was that the behavior I find annoying -- silently
making changes that aren't backwards compatible -- seems to be more
common with the new-style than the old-style tools.

On Windoze
the ideal would be to have the user pick a directory under "Program
Files" and stick a .ini file there along with everything else. It's
there if it wants manual editing, and it's out of sight and out of
mind if you just want to use the GUI. The practise is to use the
registry instead. Guess which would enable multiple instances to play
nice on the same system?

Yeah. So, not particularly relevant to a discussion of a multi-user,
multi-machine setup.

Au contraire; it demonstrates that it can be done -- having an app
coexist with different versions of itself, by each having its own
subdirectory to put things in. Of course with per-user stuff this
needs to go in the user's home directory in subdirectories, instead of
in Program Files or wherever.

I think I was imagining that with a single-user system, every
version of an application might have its own config.ini file (same
name for all), but each could be stored in a folder specific to
the application version, together with the executable, or some
such, and that this might be slightly more difficult to manage
with per-user files because of the identical filenames -- not
impossible, no, just a bit more trouble and hence perhaps not
done as often.

[ snip ]

For suitable definitions of "never": F1 brings up help in mutt
(mail reader).

Really? This is the first I've heard of any unix app even knowing that
there is such a thing as a function key.

When was the last time you used a Unix/Unix-like system? Which one?
mutt has been doing this since I first started using it, hm, about
eight years ago.

Again for suitable definitions of "never": Both of these keys
do what their names describe in mutt and in vim. The keys labeled
Home and End also do something related to their names.

Again, this I find hard to believe. Extraordinary claims require
extraordinary evidence, and all that.

What evidence would you find believable? I could hardly be
mistaken about this -- I mean, I did some experiments before
writing the above paragraph -- so are you saying I'm lying?
Why would I do that, when it would be so easy for you to refute the
claim with a simple experiment? I admit that before writing the
above I've only done these experiments on Fedora Linux systems, but
I would be surprised if they weren't repeatable on other Unix-like
platforms as well. (And I just tried the same experiments on a
SunOS system, logged in remotely, and they work there too.)

Part of the problem (?) is one of maintaining backward compatibility.

Maintaining sideways compatibility with everything else people use
would be more valuable IMO.

In other words, don't worry about keeping the existing user base
happy; force them to adapt to what the majority does.

In case it's not clear, I'm not trying to argue that everyone
should use the same tools I do; I'm saying that there is a place
for tools that appeal only to a minority.

Curiously enough, I just tried using OO Writer to write a fairly
simple document last week, and to me it seemed much like Word --
difficult to use in the style to which LaTeX has accustomed me
(logical structure rather than "just start typing"), full of
irritating behaviors, etc. <shrug>

I'm not aware of a WYSIWYG word processor with LaTeX-style logical
structure. Seems there's demand for such a thing though. Automatic
behaviors should all be turnable-offable someplace.

Or better yet, they should default to "off" and be turn-on-able.
My opinion, though.

[ snip -- more later, maybe ]

I think there's two sorts of expertise at issue, and conflating the
two is going to confuse.

1. Domain expertise, relevant to the particular task the user is
accomplishing.
2. Expertise in the program's own internal workings.

1 will be required; this is unavoidable unless the domain expertise is
something completely automatable, which is as yet rather rare.
2 should not be required, to the extent that it doesn't overlap with
1.

I think my point is that somehow a "point and click" interface
obscures that (1) is needed. In my opinion, anyway.

[ snip ]

Help that "dumbs down" the expertise in category 1 won't be very
helpful. Help and a user-interface that minimizes the impact of
category 2 is another matter however.

Sure.

I wonder whether your idea of a text editor differs from mine.

I don't see how; a text editor is an application for editing ASCII
files (or, perhaps nowadays, also unicode files). The basic goal:
enable the user to put any desired string of printable characters,
tabs, spaces, and linefeeds together and store them to and retrieve
them from files. Anything else is window dressing, really.

Your "window dressing" apparently includes my "useful functionality
required to qualify the application as a 'real text editor'".

(*) IDE-like features such as syntax highlighting and automatic
indentation / reformatting of source code. I almost switched to
emacs some years ago just to get access to these features. Then
I discovered that vim had them too.

The usual unix editor syndrome: the editor tries to be a jack of all
trades; hence, master of none, and a baffled user too. A specialized
IDE makes more sense than a supposedly generic text editor for this
purpose; and on Windows, you'd use Eclipse rather than Notepad here,
instead of trying to make Notepad into Eclipse.

Well, the old-style Unix model is that everything is stored in
text files, and you use a single editor to work with all of them,
rather than having to learn a new editor to work with each new
type of file. Applications that need to do text editing from
within the application call the user's editor of choice. I think
it's still a model that makes sense, though maybe it's not for
everyone, and perhaps some applications need more interaction
with the editor than is possible with this model.

(*) Interoperability with other tools. I don't know how to say
this better, but some examples: vim makes it easy to import the
output of a command-line command (such as ls), or run selected
lines of a file being edited through an external command (such
as sort). "No one wants to do this"? I dunno. I seem to find
it useful pretty often.

This begs for a better interactive command processor rather than more
features in the text editor. On Windows, you'd want a souped up
command.com box with full-screen instead of line editing and an
immediate-mode prompt, not unlike the old QBasic in some respects,
rather than cramming a bunch more stuff into Notepad. (With Eclipse
and a command shell jammed in there, your ideal for Notepad is now
starting to resemble some kind of feeping creature already!)

Say what? the text editor isn't trying to be a command processor
here; it's giving me access to the rest of the system without
the need for cutting and pasting between windows.

Here's an example: I'm writing a document and want to include
the result of doing some simple calculation. I can express
the calculation in the form expected by a text-mode calculator,
pipe it into the calculator program, and get the result back in
my document. Of course there are other ways to accomplish this
involving cutting and pasting, but they strike me as somewhat
more trouble, if easier to learn.

A subset of this functionality is also found in specialized IDEs, such
as Eclipse.

(*) vimdiff, which shows differences between two files in a way
that's sometimes easier to grasp than the output of diff.

This might actually be sensible as a text editor feature, but is
especially so as an IDE feature.

(*) Ability to record and play back macros. This also is
something I seem to find useful pretty often.

This might actually be sensible as a text editor feature.

[snip]

AFAICT, you're really looking for an IDE, not a plain old text editor,
here.

Well, no, because a lot of these are useful features no matter
what kind of text I'm editing (source code, mail message, newsgroup
post, etc.) -- maybe not syntax highlighting, but the other
ones.

Maybe I felt like that when I first started using these tools.
Now, however, when I'm editing text with vim, I perceive myself
to be "editing text" rather than "using vim". The keystroke
sequences for actions I do often -- I don't think about them
any more than I think "I need to turn the steering wheel now"
when I'm driving a car and want to turn.

That's the oft-noted human capacity to get used to anything. Prisoners
of war in the Koreas even got used to torture, chronic sleep
deprivation, and other stuff. Kidnap victims sometimes form a bond
with the kidnapper. It's called Stockholm syndrome; see a doctor. :)

Thing is, the interface for "normal" stuff gets out of the way more-or-
less immediately, unless what you're doing actually is rocket science.
(Editing levels for 3D games for example, rather than typing your
resume. And I think the level editors could probably be improved in
usability even so, though only up to a point.)

Yeah. I'm not sure I'd recommend vim to everyone. But as I said
in another post, given a choice between something novice-friendly
but limited and something expert-friendly but requiring some
learning, well, I'm glad to have a choice, and will sometimes
choose the latter.

Now, I *do* have that feeling when I'm trying to edit text in
some other interface.

But it won't last long if the interface is simple and straightforward.

If the task is complex, the interface is going to be complex.
If the task is simple and the tool is a normal Windows app, the
interface is going to be simple.
If the task is simple and the tool is a normal unix app, the interface
is going to be complex.
If the interface is simple, it will be easy to use.
If the interface is complex but you've spent years with it, it will be
easy to use.
If the interface is complex and you've not spent years with it, it
won't be easy to use.

So when is it unavoidable that the interface not be easy to use?
When the user is not massively experienced and either the task is
complex -- or unix is involved. :P

As previously noted, I'm happier driving
from the keyboard than using a mouse, and while a lot of actions
(selecting text, for example) can be done that way, I usually
have to consciously think about which keys are needed. I'm
sure practice would help, just as did with vi(m), but -- why?

Think about which keys are needed? It's completely intuitive with,
say, Notepad; shift+navigation keys moves one endpoint of the
selection (the other being wherever you were when you first started
holding down shift).

Shift + navigation keys is intuitive?! In whose universe? Now,
that the key marked with a left arrow should move the cursor left
is semi-intuitive (though I think it does presuppose a notion
of cursor that total newbies might not have), but how would you
know that Shift does what you describe without reading about it
somewhere, or having someone show you? Once you've discovered it,
sure, it works in a lot of circumstances. But discovering it?

(This is assuming you have no desire to use the
mouse, where typically it's just click at one spot, and hold the
button to move the other endpoint.)

The problem being that you really *can't*, save perhaps with a live
tutor, as near as I can figure.

A live tutor is probably useful in learning the first few tools.
After that, not so much, again in my experience. I figured out
bash (a command shell) without a live tutor, but then I already
knew another Unix command shell ([t]csh). I think I learned
most of what I know about some of the other tools (sed and awk)
without a local expert to help. <shrug>

The latter are noninteractive tools.

So?

If you want an interactive tool, gnuplot. I'm pretty sure just
about everything I know about it was learned without a live tutor.
Now, if I didn't already have some familiarity with similar tools,
I might have had more trouble. But I do, just as Windows users
have familiarity with the conventions of *their* platform.

But you should really not need a
live tutor at all. A decent help system would obviate the need, but
tends to be lacking on such systems as you seem to be describing.

The old-style help systems (man and info pages) are admittedly
a weak point, better as reference documentation than tutorials.

It's not so much that I think the GUI tools come up short, as
that they encourage people who don't know what they're doing to
try anyway, and they present concepts in a way that I think is
confusing to the expert. I can't give specific examples; it's
more of that "don't scare the user with technical terms" stuff.

This is not, however, an intrinsic, unavoidable trait of GUIs, though
it may be a common flaw in particular instances.

Sure.

Yeah .... I actually find some of Eclipse's "let me help you"
features more intrusive than helpful. Maybe you get used to them,
but for a first draft, I'd rather rough it out with vim, which
doesn't get in my way, and then start up Eclipse and let it help
me with what it does well, such as generating import statements.
(Somebody may well have written a vim plug-in for that. I should
look around for one sometime!)

I don't find Eclipse bothersome in that regard at all; especially as
it doesn't change anything without my permission; just highlights
various things. I can tell it to generate or fix the import statements
and it does, though.

The one major nuisance is that sometimes when the autocomplete kicks
in with a suggestion some of the navigation keys stop working and the
mouse must be resorted to if you don't want to actually autocomplete
there. :P

That's one of the features I find annoying, yes.

The other is when I actually want it to suggest a completion and it
stubbornly doesn't, though there's a key that can coax it. Sometimes
also it won't update the highlighted identifier occurrences until you
hit ctrl+S to save for some reason.

And that.

[ snip ]

But still have a legacy philosophy of let's-keep-the-user-disoriented-
in-the-dark because they originated in an era when they really had no
alternative to that.

It depends. In a constrained-width environment, with a deeply-nested
directory structure, I prefer the latter. If I forget where I am,
I can find out with pwd.

Should rename that to "pwned", since that's what you are if you are in
a constrained-width environment in this day and age. :P

Your monitor is infinitely wide? Cool. Where can I get one of those,
and a big enough room to keep it in?

I observe that the default configuration for the GNOME terminal
emulator, at least on the system I'm using now, seems to put the
full path of the current directory in the title bar, where it can
provide useful information without getting in the way.

Another benefit of the GUI way -- information can be stuck in various
places about the screen to be referred to, without being in the main
task area, and there's room for a lot more of it besides. :)

One could put this in the top line of a text-mode application's display
as well.

[ snip ]

Could be. But speaking as someone who might have leanings in the
"autistic savant" direction, I'll say that I rather like software
that suits my way of thinking.

That doesn't stop it being completely unsuitable for the vast majority
of the population of this planet, though. :P

Okay with me. I don't insist that everyone use my preferred set
of tools, just that they leave me to use them in peace and not try
to explain to me how wrong-headed I'm being. The downside is that
I don't learn as well what most people's experience of computers
is like, which is limiting in its way -- though nice in other ways.

[ snip -- it's not that you're not making some good points, but
apparently there's a limit after all to how much time I'm willing
to spend, even though this is a subject I can get worked up about ]

Evidently. :P

And evidently I'm not alone.

[ snip ]

That's not my observation. See above. Hell, when "something goes
wrong" on Windows 90% of the time it's fixed with a reboot, or a
reinstall of the offending app, or both. When "something goes wrong"
on Unix 100% of the time it's fixed with voodoo, for which your local
witch-doctor will probably charge money. If you can even find one. :P

Not my experience.

[ snip ]

Huh? Say I want to learn more about the cd command. I type "man
cd" and get a long page about bash (since cd is actually a shell
builtin). Now I type "/cd<return>" to search for cd

And hit something that I'm sure is not F3 to jump to the next
occurrence, and the next, and eventually to the 500th or so, which is
the first that actually references the "cd" command instead of being a
random occurrence of those two letters side by side as part of
something else.

"cd" is an unusual combination, though, isn't it? (As it happens,
on the man page on my system, the third occurrence of "cd" was
the one that was most helpful.)

Search queries only a couple of letters long are well-nigh unusable.
So is any interface that depends on your using such to navigate.

Binary search is better? because that's what we're comparing here.

(Admittedly the use of "/" and "n" to search aren't intuitive
the first time you encounter them, but a lot of text-mode tools
use them, so .... <shrug>)

Given that the other 90% of the world uses Ctrl+F and F3, it's not
just "not intuitive", it's downright perverse. And let me guess, it's
also undocumented -- at least, anywhere you would likely stumble upon
without having already successfully performed a search?

Ctrl-F is somewhat intuitive. How is F3 intuitive?

[ snip ]

If you search for a common word, you get a trillion hits. If you
search for a rare word or a phrase, you get zero to a handful. The one
is simply useless; it's either a slightly faster or a slightly slower
page down, depending. The other requires you to know a fair amount
about the target already, likely only if you've already been there.

How is binary search better?

[ snip ]

Probably this marks me as terminally pack-rattish, or otherwise
weird, but I'm apt to accumulate version after version of those
configuration files, accumulating them in one location with names
that show the order in which they were created/saved. So the
problems you describe don't really arise.

Only in the specific case of someone doing the sort of thing you
describe. Requiring careful record-keeping and cataloguing by the
whole user-base strikes me as foolish and needlessly user-hostile.

Yeah, maybe. But at least it lets people who *do* want to have a
record do so, as opposed to point-and-click operations that leave
nothing recordable.

[ snip ]

I think you're onto something here. (And your use of the word
"micromanage" -- you're onto something there, and if in fact you
wanted to say "control freak", that wouldn't be out of line!)

Hrm. It seems to appeal to a certain personality type too, though not
the pragmatist that just wants to get sat down before the keyboard and
get things done by suppertime, and who certainly finds no room in
their schedule to cram in an extra seven-week training seminar or two.

Yeah. And the person who doesn't mind remaining ignorant of better
ways to do things, and continuing to do manually things that could be
automated. (You do have a point. But I think I do too.)

You do know about filename completion, right? so getting to
the files is not, IMO, more of a chore than it would be in a GUI,
except that there are fewer visual cues.

It's worse than "fewer visual cues"; if you have the file you want in
front of your eyes on a GUI, unless you do something dumb, like close
the window, it will remain within easy reach. In any commandline
environment, one wrong move and you start all over; although you can
keep the path part around by cd'ing to the file's immediate parent
directory. With the GUI, in other words, you only need to "find" the
file *once* and then make sure a window is kept open to a position in
which the file is visible. With a command line, you need to "find" it
for each occasion where its name is needed, plus any time you mistype
anything, etc.; so even if the "find" bit is no harder, instead of
"find" once, "specify" many, you need to "find and specify" whenever
you want to "specify". This may mean doing the "find" bit, say, ten
times instead of once, depending.

This doesn't sound much like my experience. Of course, I do things
like defining environment variables for directories I use a lot,
so navigation isn't as difficult as it might be -- $WEBDIR for
the directory where the files for my "Web site" live, for example,
so I type "cp file $WEBDIR" rather than giving the full path.

Still short on visual cues, but not, IMO, as bad as you're making
these systems out to be.

Even window managers these days aren't what they once were, but
are apt to be run in conjunction with a "desktop environment"
such as GNOME or KDE. I'm not sure I completely understand the
distinctions myself. But the idea of having separate mix-and-match
pieces is very Unix-y.

The window manager presumably provides the basic GUI API for
applications. The desktop environment provides a graphical shell for
the user, so they aren't staring at a blank screen with the GUI API
available but no way for the user to start something that'll invoke
it. (Well, short of getting back to a command-line shell prompt and
launching something from there, anyway.)

With Windows, one application (Explorer) provides the shell and a file
manager; there's a GDI.exe buried somewhere in the system that
performs the "window manager" function to provide access by other
applications, including Explorer.

So two of the three things are still technically separate with
Windows.

But the interesting question is whether you could replace one of
those pieces with something comparable -- or whether there even
*is* something comparable. Unix-y systems are apt to offer a
somewhat bewildering array of choices, and to allow mixing and
matching (possibly not arbitrarily so, though).

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.

Yes! One of the problems I perceive with people accustomed to
GUIs is that they don't even imagine the possibilities of the
kind of automation possible with the old tools.

And yet the old tools can't even do something fairly simple and not
needing automation without wizardry involved. The automation of course
also requires developing a small program, in effect, and generally
with drastic consequences to getting it wrong. (Windows apps often
have a search-and-replace which can likewise have drastic
consequences, but at least there's an Undo command available -- though
some boneheaded app designs treat each replace done automatically as a
separately undoable action! Morons.)

Not saying the old tools are always best, just that they provide
something that seems not to even be imagined by people who only
know GUIs. Something that somehow combined the best of both
worlds seems like a great idea, no? but it's not clear that it
will be invented by someone who doesn't know the benefits as well
as the drawbacks of the old tools.

It's something
I do my best to show my students .... Perhaps one of them will
come up with something along the lines of what you describe.

Or I will...

Could be. I'd be interested. I'd say "be sure to come tell us
about it", but -- off-topic, maybe.

[ snip ]

But you claimed you could learn something useful and transfer the
knowledge to another application. That's impossible if they don't both
adhere to *some* standard, but rather each does everything in a
totally idiosyncratic way.

But they don't. What you learn from one application may not be
100% helpful in learning the next, but the odds are that it will
be more than 0% helpful, and I claim that for the kinds of things
we're talking about here, it will likely be a lot more than 0%.

There isn't even a real standard for
*documentation* over there in nixland; there's man pages (with a
crufty, nigh-unusable browser tool required to read them, as they're
binary -- at least, they were on the system I am recalling),

On the systems I've used (Linux, Solaris, earlier systems),
"man" finds the files, converts them to text, and pipes the
whole lot into your pager of choice (something akin to DOS's
"more" command, though possible more capable -- the one I use,
"less", is able to page ahead by arbitrary amounts, search for
text, etc.). I have no idea what tool you're talking about.
Could it be -- I think I remember an "xman" tool that ran under X?
maybe still does on some systems?

Now, the fact that some information is only available via the
"info" pages, and the "info" command has a different interface --
well, yeah, annoying.

plain
text, and even .ps and .html; even using the latter is nontrivial if
you haven't got a working GUI and a copy of Firefox installed yet,

There are text-mode browsers too, and in most of these tools,
trying keys such as "?" and "h" often provides some help that's
enough to get a person started. A person that doesn't insist that
every new tool behave exactly like the ones he/she has used before,
anyway. (Not that I'm knocking consistency. Consistency is good.
It's just not the *only* good, and there can be trade-offs.)

and
I purely *hate* messing with postscript in any way, shape, or form,
mainly because the format was designed for transport between a
computer and a printer, not for storage/online viewing (the huge size
and total lack of compression -- they're highly repetitive ASCII text
inside, if you ever looked -- is another symptom of this, as the
designers expected this stuff to be short-lived as it rushed along a
100MBit parallel cable to a printer, rather than to sit around on a
disk drive taking up space, or even get downloaded over a paltry
5-10MBit cable or DSL connection from the Internet or, worse, dial-up
(eek!)).

PostScript is being supplanted by PDF these days, as far as I
can tell. The ASCII-ness of PostScript is actually, in my opinion,
one of its attractions. You know why. :-)

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.

Quantcast