bzs@WORLD.STD.COM (Barry Shein) (02/05/91)
What are we going to do about these Unix window systems? Oh, when they
work, they're ok, they even usually manage to produce a few rectangles
on my screen and place interesting things, mostly text, within them.
But once something goes even slightly wrong, watch out!
I gave up on NeWS a long time ago because I decided life was too short
to try to read or produce postscript code, FORTH on steroids.
So I tended to focus on X11, but it's clear that it's completely out
of control.
Something wouldn't work today because some resource was set wrong, it
even complained, but it wasn't clear what it was that was setting it
this way to make it so unhappy, or how to fix it.
The error message didn't even leave me much clue what I might do to
override the bad value, let alone what a good value might look like.
Just some cryptic string followed by "bad value", and it gave up. I'm
not sure I would have been placated with merely a better error
message, I suppose it would have helped.
I glanced at my .Xdefaults file and realized it had grown quite a bit,
a quick wc -l revealed that it indeed had almost 600 lines of obscure
syntax in it. And apparently this wasn't enough to make it through
today.
I remember some number of years ago expressing my disgust with IBM's
OS/JCL because there were about 185 things you could say to a DD (sort
of like a file open()) statement. Well, here it is, 1991, and now I
have basic utilities approaching 1000 options. This is progress?
Perhaps I should take back what I ever said about OS/JCL?
In fact, an .Xdefaults file looks quite a bit like JCL on steroids, to
use that metaphor again, perhaps that's why IBM finally broke down and
endorsed Unix?
Unix's original appeal was its simplicity.
The open() call, for example, took two arguments, a file name, and a
mode (read, write, both.) Ok, later they added a third argument, but
that was mostly so you could get rid of another, somewhat redundant
function (creat()). Fair enough.
Compared to OS/JCL and other systems of its time, this was awesome
brilliance, it even worked. This brilliance was compounded by the
myriad things you could feed an open statement (files, pipes, devices)
without warning, and the resultant I/O statements (read, write) would
pretty much behave predictably, independent of what you had opened.
Being able to do this from the shell was almost a religious experience
(not almost, it was a religious experience.)
There are two schools of thought, it seems, in designing applications:
One extreme says that you sit down and think very hard about what
people will want to do with your application and try to minimize any
need for customizing. You "own the problem", and try to write a piece
of software that solves the problem at hand.
Many Unix utilities exhibit this property, although more than a few
have grown obese with flags. But, even an incredibly flag-obese
application like "ls" has maybe 30 options, of which I usually use
less than 5 except on very rare occasion. I never feel like I have to
understand the other options when I don't need them. I don't see "ls"
complaining "you forgot to set the -X flag, you lose!"
The other extreme says that everything must be customizable, that you
don't really solve a problem with an application, you invent a new
language in which every user of your program can solve their own
problems.
It's a sort of puerile Zen approach, where every question is answered
with a new question:
Master, how shall I obtain function key nirvana?
How did you obtain mouse-button nirvana, grasshopper?
The syntax is similar, only different.
These are the application programs which must use extensive files to
manage their options in (oh, they may also have 50 or more flags on
the command line, but a lot of those flags only control where to go
looking for the real settings I want to use today.) You couldn't begin
to type the options on a command line.
These applications have system global files, user private files,
methods for including other files into their files so you can manage
these burgeoning files, conventions for running the files through
preprocessors, filters, macro expanders, make, and other tools to help
conditionalize their effects, private libraries with dozens of files
to help you further customize your own files, log files, large manuals
explaining the syntax of all (well, some) of these files, built-in
help facilities and hypertext navigators to help you find all the
options you might want to set today, point and click applications
who's only purpose is to set options, etc etc etc.
So, here I am wasting a few hours trying to figure out which string in
which value in which of a few dozen files has made my window manager
sick.
A window manager!
What a stupid thing to spend time on!
Who cares about 500 options to allow me to control whether the green
and mauve root menu with 3D highlights which pops up when I hit
ALT-CTL-MOUSE-3 displays "Resize" as the first item on the menu or
"Raise Window"? Or exactly what stipple pattern my scroll bars will
have (chosen from several provided or I can sit and make my own
stipple patterns with the scroll-bar-stipple-pattern-editor!!! Wow!
Now if I can only figure out the stipple-pattern syntax...)
Choose one, wire it down.
If your choices are awful, well, I won't use the software. If they are
merely good, I probably will use your software. If they are very good,
I will rave to my friends about what wonderful taste you have and how
they should all immediately write large checks and send them to you so
we can all share in this experience.
But don't try to convince me that you have provided me with a
redecorated home when all you really have done is left the address of
the local furniture store and a large book on the chemistry of paint.
I think we are being played for idiots, my friends. "The Emperor's New
Clothes" comes to mind.
Something has to change.
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDdennis@CS.WASHINGTON.EDU (Dennis Gentry) (02/05/91)
Date: Mon, 4 Feb 91 22:49:18 -0500 From: bzs@world.std.com (Barry Shein) To: info-futures@world.std.com If your choices are awful, well, I won't use the software. If they are merely good, I probably will use your software. If they are very good, I will rave to my friends about what wonderful taste you have and how they should all immediately write large checks and send them to you so we can all share in this experience. Have you tried a NeXT? They made many excellent choices with their window system (and many other pieces of their system), I think. And made it easy for software developers (perhaps not always end-users) to make good choices. If you think it's distasteful to be an X end-user, you should write an X program some time. Just the thought of it gives me a frission. (Please, this is not an invitation to start the "we want X on NeXT," "No we don't," "Yes we do" flamefest in this mailing list, which would be an inappropriate place for it.) Perhaps you weren't talking exactly about aesthetic choices, but I think aesthetic choices are important, and NeXT did a superb job at that, and at least a good job (I think excellent) with everything else. Dennis Disclaimer: I liked NeXT's choices so much that I now work for them, but of course I'm speaking only for myself.
bzs@WORLD.STD.COM (Barry Shein) (02/05/91)
Actually, yes, I've used NextStep (and I've probably written more
lines of window code than most people you know, so this isn't just an
end-user view, tho I think the end-user situation is particularly
ugly, when I program I expect some amount of complexity.)
I found the NeXT to be interesting, but it's unfortunate they got
involved in Objective C which remains "yet another lousy objectish
programming language". It's too bad people think this sort of thing is
"object-oriented" programming.
Their application developer, whatever they call it, is also
interesting, but demonstrates how hard this sort of thing is. A small
change to the interface often invalidated or confused all the work
thus far (at least in my experience.) It was also quite hard to do
anything that they hadn't explicitly anticipated, and that set seemed
a little limiting. I don't think these were merely bugs, I think they
were up against a fundamentally difficult problem!
Most frustrating was the realization that all their demo programs (at
least at the time) were basically building bitmaps in memory and
blit'ing them to the screen, totally avoiding most of their own
interface. I quickly found out why, it was the only way to get a crisp
update. And I thought *I* was doing something wrong...sigh.
HOWEVER...it would probably be a good idea for everyone interested in
these sorts of systems to take a good look at the NeXT.
And then think about what these interfaces should be.
Well, now I've flamed just about all window systems for Unix I think,
that's some sort of accomplishment for one day :-)
Seriously, I was flaming all the OS's in 1977 also. In retrospect, I
think I was right to do so. Dissatisfaction is the mother of invention.
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDkent@parc.xerox.com (02/07/91)
Well, yes. LOOPS was wonderful. The Lispms were/are pretty wonderful, too. Smalltalk was/is great. Cedar is fairly wonderful in many ways. Hypercard is fairly wonderful in some ways, but not nearly as nice as its inspirations. Is there a common thread here? Yes, I think so: they're all highly integrated systems that were created by a person or a small group of people with a tight vision, high energy, and a lot of cycles. (Most of them are also single-address-space systems, which is a bad idea but a great implementation environment.) X is a system that's waiting to have that kind of energy poured into it. So far, all we've really had is a baroque toolkit design and a lot of corporate jingoism and positioning for market share. Trestle seems to have promise as a complete rethinking of the toolkit layer. Tcl is another step in the right direction, even though I don't care for the language that is used (all the power of the csh with all the flexibility of the csh, to slightly twist an oft-quoted phrase). By all means, let's keep this discussion going. But the answer lies in the doing; some person or group of people has to dig in, throw away, and rebuild. Doing it in a multiple address space environment just makes the problem that much more interesting. chris
etj90@ecs.soton.ac.uk (Jordan ET) (02/07/91)
I got completely lost in that one. I am dead impressed by the description of the application, but what is/was it called ? Is it still available ? For the Amiga ? Information would be gratefully received.
janssen@parc.xerox.com (Bill Janssen) (02/07/91)
In article <91Feb6.105354pst.3142@thrale.parc.xerox.com> kent@parc.xerox.com writes:
So far, all we've really had is a baroque toolkit design and a lot
of corporate jingoism and positioning for market share.
So true. The thing that people seem to miss is that there is no real
difference (on an idea level) between OpenLook and Motif -- there is
only one kind of interface that can be built with either.
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304ray@bcstec.boeing.com (Ray Allis) (02/08/91)
Barry Schein says... >I realize everyone is going to jump up and down and say ooh ooh you >can do *exactly* that with (fill in favorite interface builder.) > >All I can say is, probably not, you'd have to use it to understand. That certainly has been my experience. I have not been able to describe what made LOOPS so exceptional without an actual living system at hand. I got to play with Smalltalk-80 when PARC first let it out; on a Xerox 1100 (the Dolphin, successor to the Alto). The Smalltalk Language book was still in galley proof. It was a mind trip for me and for my managers. Rapid prototyping was the buzzword, but it was the graphic interface that made the impressions. But "Real Work" was done in LISP. LOOPS was "beta test software" almost grudgingly made available to us. I used the system for about two years on my 1108/1109/1186's. It is far and away the best programming environment I've seen. But Xerox gave the impression of reluctance to admit it existed, and it didn't spread far. LOOPS was more than object-oriented; it was a multi-paradigm system with objects, rules, LISP and "active variables", all available at an interactive graphic interface. As Barry noted, the browser was a graph of the object inheritance tree. The nodes were (usually) classes, and clicking the mouse on them allowed inspection and editing of class and instance variables, etc. Of course you could manipulate almost anything about a running program and see the effect immediately. I think it was the interface that made the system so remarkable. These days "Scientific Visualization" is a hot topic, because it's productive to help a person *see* data as shape and color. There is good potential for new insights. The LOOPS interface allowed you to *visualize* the structure and dynamics of the program or system you were building/studying, in pretty much the same way. The current "window managers" don`t have the same goal, and certainly nothing like the same results. > ... but I think it illustrates what object-oriented >programming was originally conceived to be. It became something rather >boring. Too true. Maybe it's time for "Computer Program Visualization"?
fozzard@alumni.colorado.edu (Richard Fozzard) (02/12/91)
In article <654@bcstec.boeing.com> ray@bcstec.boeing.com (Ray Allis) writes: > >Maybe it's time for "Computer Program Visualization"? This idea didn't die with LOOPS, and maybe there will be a renaissance. On the Mac, there are two interesting visual programming environments: VIP and Serius89, both claiming some kind of object-orientation. VIP has even been discussed in the virtual reality issue of Release 1.0 - a sort of industry insider's comp.society.futures newsletter. I have no experience with either - anyone else? rich -- ======================================================================== Richard Fozzard "Serendipity empowers" Univ of Colorado/CIRES/NOAA R/E/FS 325 Broadway, Boulder, CO 80303 fozzard@boulder.colorado.edu (303)497-6011 or 444-3168
reschly@BRL.MIL ("Robert J. Reschly Jr.") (02/12/91)
Bravo! <hrrumph> -Bob
mwm@wse.dec.com (Mike Meyer, My Watch Has Windows) (02/21/91)
Hello agan, Barry. I've been meaning to reply to this for a couple of weeks, and just kept getting distrated. Anyway... >> That's not buggy applications which don't properly accommodate >> different screens. That's an expression of a real philosophy in X that >> the end-user can set all these things so why bother to think about >> them? Take it as an example of what's wrong I think this is wrong. Not that X isn't broken, but the implication that the application writer should worry about building the interface, and the end-user should have limited power to change it. If that's not what you're implying - well, I want to wave my ideas around anyway, and this is a good chance :-). The reason application writers shouldn't worry about interfaces is that progammers are notoriously bad at interface design. They tend to build interfaces that make lots of sense - to someone who knows the internals of the program, and thinks like the programmer. My beta testers complain about such things regularly. I then see other programers doing the same things I corrected (and curse at them, because I like the interface my beta testers forced me to build). Second, the end user should have as much flexibility as possible - the more, the better. I claim that emacs is so successful not because it offers an incredibly overgrown set of tools, nor because it's the perfect editor, but because it allows anyone with a little smarts to build an editor to their taste. I feel the same should apply to the user interface parts of a windowing system. >> What I'm looking for here is, what will be the third generation of >> windowing systems? How will we get back to some sort of rational set >> of primitives and away from the burgeoning laundry lists of features >> which belie no wisdom about the underlying goals, just zillions of >> little knobs to turn in a frantic attempt to make everyone happy (and >> succeeding in making no one happy.) Others have claimed that X, underneath the layers and layers of cruft, isn't a bad set of primitives for a windowing system. I'm willing to believe that - because I'm more interested in the layers and layers of cruft, and fixing them, than I am in what actually happens to render a pushbutton. In other words, replacing xtk, motif, /usr/lib/X11/app-defaults, and .Xdefaults with something useable, rather than trashing X completely. I've been working on a system that would do just that - except I'm not using X as a base. The key insight is that many applications don't really need to deal with a "user interface" per se. They need to get values from the user, display data, and act on commands issued by the user. If you let "get values" include file selection boxes and text editing widgets, a broad range of applications fit the paradigm. For such programs, the application divides cleanly into an "application", and a "user interface". The application has entry points for the commands, code to display data, and hooks for setting values. The UI has gadgets for issuing the commands, setting values, and drawing areas for displaying the data. The application really doesn't care about the UI, only about the values and commands that come back from it. Using what I'm working on, a typical application has two parts, ala a Macintosh. However, the "resource fork" is a spec for the _entire_ user interface. The equivalent of a "resource editor" would allow a user to re-arrange the entire interface - moving or deleting menus, turning radio buttons into mutex menu selections or cycle gadgets, putting commonly used commands on keystrokes or control panel buttons, etc. The format of the "resource fork" will be public, so anyone can write an editor for the thing. There are already a couple of different editors under construction. Tieing the two forks together will be the library that actually implements the UI based on the spec. The application will - naturally - depend on the library. Some of the strings in the GUI will also depend on the interface, and those wouldn't normaly be edited. For each library, there's a file of the same format as the resource fork (so the same parser can be used) that's used for setting defaults for applications that use that library. This isn't really much different from the app-defaults approach that can be taken with X. The major differences are that it forces an application to use this approach, and that the "resource database" isn't a collection of baroque strings with obscure precedence rules. It may be possible to build such a system on top of X; I'm not trying to. In fact, I'm working in a single-user environment. A multi-user environment has some obvious extensions with not-so-obvious flaws in them. <mike