Conference hydra::amiga_v1

>    A version of OS/2 -- to be released later this year by IBM -- 
>    will also have 32-bit power.  But OS/2 is designed for computers 
>    built around chips made by Intel Corp., Santa Clara Calif., while 
>    Microsoft now promises that future Windows systems will run on 
>    any computer hardware.

Hmm, shame about OS/2, but I wonder if that last statement means they might
just develop Windows for Amiga?!

john

    
    I wonder what percentage of Pee Cees can actually _run_ Windows?
    
    If you want to see a magnificent piece of programming, check out
    GeoWorks Ensemble for the PC.  It makes Windows look like a joke, and
    runs well on just about any hardware.  Too bad that no one takes it
    seriously; every mention that I've read of it had great praise followed
    by regret that it would never take off!  Talk about self-fulfilling
    prophecy!
    
    Ed.

    
================================================================================
Note 5957.1                        O/S 2 Dead?                            1 of 1
EXIT26::STRATTON "Reason, Purpose, Self-Esteem"      47 lines  29-JAN-1991 21:03
                             -< No, OS/2 not dead >-
--------------------------------------------------------------------------------
| Subject: OS/2 Statement
| Date: Mon Jan 28 12:38:02 1991
| 
| This was just released over the news wires:
| For more information contact:
| 
| Microsoft Corporation              
| Marty Taucher                                 January 28,
| 1991
| (206) 882-8080
| 
| Waggener Edstrom
| Pam Edstrom
| (503) 245-0905
| 
| 
|                 Microsoft Fully Supports OS/2
| 
| 
|      REDMOND, Wash. -- Jan. 28, 1991 -- Microsoft denies the
| today's Wall Street Journal article alleging that Microsoft is
| dropping OS/2.  Microsoft and IBM are continuing the joint
| development of OS/2.  Microsoft continues to service, support
| and sell OS/2.  Microsoft is continuing to develop
| applications for OS/2 adding to the 11 OS/2 applications
| currently available from Microsoft.
| 
|      "The operating system market has multiple segments with
| varied requirements," said Bill Gates, CEO at
| Microsoft.  "For customers needing high-end capabilities,
| deploying OS/2 applications or pursuing IBM's SAA direction,
| we market and support OS/2.  We will continue to enhance it in
| the future and enable it to run Windows applications."
| 
|      Microsoft will outline plans for OS/2 and Windows at a
| seminar held at Microsoft tommorow.
| 
 
 
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
Received: by decpa.pa.dec.com; id AA18374; Mon, 28 Jan 91 16:36:42 -0800
Received: by uucp-gw-1.pa.dec.com; id AA01805; Mon, 28 Jan 91 16:10:14 -0800
From: microsoft!jerryp
Message-Id: <[email protected]>
To: ranger::curless
Subject: OS/2 Statement
Date: Mon Jan 28 13:30:23 1991
    

The roomer column in Amazing had a blurb about Windows being developed
for the 68000 series. It also stated that CBM really takes to this Idea.
Of course if you own an amiga this only makes it nicer.

    before you all get too excited :-)  Remember that AmigaBasic
    was written by them.  Any news on when it will be fixed so that
    it can run on the A3000?
    
    I assume by 68000 series they mean to have a common source that does
    everything with just the cpu, no custom chips needed - just need
    a video driver.  Like in the ibmpc version.
    
    To get reasonable speed, just get a faster cpu.  And watch the mouse
    pointer get redrawn constantly when you scroll text under it.
    
    I suspect the real question is how much effort is Microsoft willing
    to spend on OS/2 given the success they have had with Windows 3.0.
    The more features they add to Windows, the less attractive OS/2
    becomes.
    
    Dave

-.1 stated what I started to think. The only Microsoft product
on the Amiga is a pretty poor attempt, i.e. Amigabasic.

I can't imagine a good implementation being done for the amiga,
now a Mac on the other hand...

regards
	Mike

    Having only one software platform to design for - Windows - is very
    attractive to PC developers.  Then you don't have to worry about system
    differences that make "porting" difficult.  sigh...
    
    Of course, Motif & X Windows could make the same claim.
    
    Should be interesting to see how it turns out.
    
    I suspect its just a matter of time until .0 becomes true.
    Its interesting to note that the marketing might of IBM and Microsoft
    combined failed to convince the PC users that multitasking was useful
    when you could get task switching for far less cost.
    
    dennis

     According to an article in the Boston Globe, Microsoft expects
     Windows to be the best selling software package of all time.
     From memory, they have sold 2 1/2 million since intro and expect to
     sell six mill this year, which would beat out Lotus 123, on the
     market for 7 years. I may have the numbers off a bit but you get the
     idea. Microsoft is on a BIG role with windows. The Globe was saying
     that they have a lot of clout, and have become the standard setters.
     FWIW, the article said that Microsoft was winning the market by
     providing what customers want rather than by the Machiavelian 
     techniques favored by IBM.
     
     I also wonder about how committed they would be to OS/2, Amiga
     even MAC. Can't they get everyone hooked on windows and then
     just build another operating system that they own to go under it?
     They don't sell hardware so they don't care if the Japanese
     start selling super computers for $500 that wipe out Apple
     Commodore & Atari (IBM, DEC)...
     
     Dave
                        

    
    There have been lots of not-so-subtle accusations that Microsoft
    deliberately led their competitors down the OS/2 path, then suddenly
    dropped Windows 3 and a bunch of their _own_ outstanding W3
    applications (Word, Excel, Project, Powerpoint) on the market.
    
    Maybe Bill Gates could teach Jack Trameil a few things about 'business
    is war'?
    
    Ed.

X/Motif.
X/Open Look.
Windows.

I don't know what the Europeans are cooking up, but I'm sure they've got
their own ideas about what a "windowing system interface" standard should
be.

The nice thing about standars is that there are so many to choose from. If
even one of them were as usuable as intuition, I might even be convinced
to choose one.

	<mike

> The nice thing about standars is that there are so many to choose from. If
> even one of them were as usuable as intuition, I might even be convinced
> to choose one.


You must be refereing to WB 2.0.

john

re .11

Actually, 2.0 isn't critical. It only makes one relatively minor change
in usability. I find either 1.3 or 2.0 more usable than the default
windows/motif interface (they're nearly identical), and that more
useable than Open Look.

Yes, 2.0 can have much prettier gadgets than 1.3. The Mona Lisa is much
prettier than either of them, but it still makes a lousy user interface.
And I want an interface to use, not hang on the wall.

If you're talking about the programmers interface to them, 2.0 isn't
anywhere near as useable as Motif (I dunno 'bout Open Look or Windows),
so my entire statement was false.

	<mike

What defines usability?

I think motif and intuition (with 2.0 look) are close. In fact without having 
seen gadtools, motif seems more usable in that the interface is more contigous 
across applications. DEC may have played a role in that with the DEC toolkits 
under DXM, and eventually with motif/DW V3.

I'm just curious. I feel that intuition and the workbench use of it are
lacking in many ways around user interface and "built in" applications and
application support.

john

[Put down soapbox; stand on it; enter philosophy mode...]

I define useability as the inverse of the amount of pain needed to get a
job done. For a window manager (Intuition, Windows, or Motif), that
job is managing windows.

This isn't all of the standards in question - but it's the part that keeps
me from running that part of the standard as a user. I dislike the way that
mwm does things - it just seems to get in my way. Open Look is even worse.

The buttons/menus/etc that are part of an application are just that - part
of an application. As such, comments on the ease of use of the "standards"
gadgets are bound to be tainted by the application; much like an spoonfull
of wine is tainted when you drop it into a barrel of sewage. [The second
half of the sewege distribution law holds in this analogy also - a spoonful
of unusable window manager (seweage) in a barrel of wonderful application
(wine) leaves you with a barrel of unusable application (sewage)].

From a programmers viewpoint, motif encourages you to follow a standard
useage pattern, by making that easier than going the opposite way. It
also provides a bucketfull ofvarious and sundry interesting gadgets for
you to use. If you do it the Motif way, and consider the job to be providing
the user with a tool and means of invoking it, motif is relatively
straightforward. If you don't want to do it their way, or want explicit
control over things - well, you bought into the work on your own.

GadTools provides a handfull of gadgets, with limitations on how they
interact. There is nothing to encourage you to use them in any specific
way. Or to make doing it "the right way" any easier. You're in the position
of having been bought into that work from the outset. It's probably best
I not continue listing the problems I perceive with GadTools.

	<mike

>                        <<< Note 4467.14 by MADRE::MWM >>>
> 
> [Put down soapbox; stand on it; enter philosophy mode...]
> 
> I define useability as the inverse of the amount of pain needed to get a
> job done. For a window manager (Intuition, Windows, or Motif), that
> job is managing windows.
> 
> This isn't all of the standards in question - but it's the part that keeps
> me from running that part of the standard as a user. I dislike the way that
> mwm does things - it just seems to get in my way. Open Look is even worse.

But mwm is user configurable.  Intuition configuration is alot of contrived
C code. And you don't have to use mwm if you don't want to, there are several
other window managers that all "plug in". Tossing intuition and it's wm 
functions means tossing workbench and most of the applications written on the
amiga. That, in my opinion, makes motif much more usable as a total system.
But that's my definition of usable.


> From a programmers viewpoint, motif encourages you to follow a standard
> useage pattern, by making that easier than going the opposite way. It
> also provides a bucketfull ofvarious and sundry interesting gadgets for
> you to use. If you do it the Motif way, and consider the job to be providing
> the user with a tool and means of invoking it, motif is relatively
> straightforward. If you don't want to do it their way, or want explicit
> control over things - well, you bought into the work on your own.
> 

And like you said, Intuition is an adventure to program to say the least.
"refined" systems like motif and X toolkits make things so much easier
and consistant. I've seen applications for the amiga that make no sense
at all as to  how they work - definetly *not* intuitive. The default object
creation mode is primitive. 


> GadTools provides a handfull of gadgets, with limitations on how they
> interact. There is nothing to encourage you to use them in any specific
> way. Or to make doing it "the right way" any easier. You're in the position
> of having been bought into that work from the outset.


But it's a start. It will allow applications to have the same look and feel
that the  big guys (DEC, Sun etc) have strived for in their windowing
standards - and without writing hundreds of lines of code to get there.

> It's probably best
> I not continue listing the problems I perceive with GadTools.
> 

that's been an interesting "debate" :-). Good points on both sides. I think
CBM has come a long way in making the amiga a professional looking and acting
system.


> 	<mike
> 

john

>> But mwm is user configurable.  Intuition configuration is alot of contrived
>> C code. And you don't have to use mwm if you don't want to, there are several

Well, 2.0 fixes a lot of the configuration stuff. It's been described as
"all your favorite hacks already installed". While not quite true, it's
a long step upward.

We're suffering from some semantic confusion. Motif is several distinct
objects; a library of routines for interacting with X, and a window manager
that uses that library being what's under discussion. There's also a spec
for an extension to the X protocols for talking to the window manager. As
I mentioned earlier, my "unusable" reaction is to the window manager. If
someone ever takes vtwm away from me, or writes a vmwm, I'll look at
configuring mwm to be "usable".

As I think I said, as a programmer, I find Motif more useable. As a user,
I find intuition more useable.

>>> It's probably best
>>> I not continue listing the problems I perceive with GadTools.

>> that's been an interesting "debate" :-).

You've only seen 1/3rd of it, unless you're on BIX. Largely, it was a
miscommunications problem, and I'm _much_ happier than I was after the
first round. I wish I know what was going to happen, so I could decide
whether to continue the efforts _I've_ got underway to solve the problems
discussed there.

	<mike

>                        <<< Note 4467.16 by MADRE::MWM >>>
> 
> >> But mwm is user configurable.  Intuition configuration is alot of contrived
> >> C code. And you don't have to use mwm if you don't want to, there are several
> 
> Well, 2.0 fixes a lot of the configuration stuff. It's been described as
> "all your favorite hacks already installed". While not quite true, it's
> a long step upward.
> 

I just wish they would get it to us users to try :-)


> We're suffering from some semantic confusion. Motif is several distinct
> objects; a library of routines for interacting with X, and a window manager
> that uses that library being what's under discussion. There's also a spec
> for an extension to the X protocols for talking to the window manager. As
> I mentioned earlier, my "unusable" reaction is to the window manager. If
> someone ever takes vtwm away from me, or writes a vmwm, I'll look at
> configuring mwm to be "usable".
> 

I see your point and agree. I've gotten used to mwm and although there are
some things that bug me, they don't keep me from liking it more than 
intuition. I should say there are more things about intuition that bother
me so it's the worse of the two (to be fair, it's all of the user interface
components to "workbench" that I don't like)

> > >>> It's probably best
> > >>> I not continue listing the problems I perceive with GadTools.
> > 
> > >> that's been an interesting "debate" :-).
> > 
> > You've only seen 1/3rd of it, unless you're on BIX. Largely, it was a
> > miscommunications problem, and I'm _much_ happier than I was after the
> > first round. I wish I know what was going to happen, so I could decide
> > whether to continue the efforts _I've_ got underway to solve the problems
> > discussed there.
> > 
> 

Actually I only caught the tail end on usenet,  but enough to see what the
issues were. I have to question weather the featturs or functionality missing
in GadTools was oversight/matter_of_developers_opinion(CBM) or just plain
lack of time and a best shot effort for V1. I tend to think (after the smoke
cleared) that CBM has honest intentions of making GadTools provide more of
the behaviour you spoke of (and rightly so), but simply don't have the time
and/or resources just yet.


> 	<mike
> 

john

>> I see your point and agree. I've gotten used to mwm and although there are
>> some things that bug me, they don't keep me from liking it more than 
>> intuition. I should say there are more things about intuition that bother
>> me so it's the worse of the two (to be fair, it's all of the user interface
>> components to "workbench" that I don't like)

Hmm - I don't think Motif has anything like the "workbench" in place. But
others are filling that gap. I do agree with you - the 1.3 workbench is
just about unusable. 2.0 is much better.

>> Actually I only caught the tail end on usenet,  but enough to see what the
>> issues were. I have to question weather the featturs or functionality missing
>> in GadTools was oversight/matter_of_developers_opinion(CBM) or just plain
>> lack of time and a best shot effort for V1. I tend to think (after the smoke
>> cleared) that CBM has honest intentions of making GadTools provide more of
>> the behaviour you spoke of (and rightly so), but simply don't have the time
>> and/or resources just yet.

It is now pretty clear that GadTools is a best effort before release
The problem is, Peter assumed that everyone knew that, and never
bothered to state it explicitly. I assumed that, since there was no
indication that some problem was being addressed, Peter would answer an
explicit question about it indicating whether or not it was going to be
addressed. What I got were reasons as to why I didn't need the functionality,
or pointers to workarounds. (Hmm - I may go back and say that on the net...)

	<mike

    I can see why windows is selling so great. It has a captive audience of
    millions of dos users starving that were starving for a GUI. Some
    people in the shop installed windows on monday,ans removed it on
    tuesday. It seemed their modest system of 4meg of ram,and 40meg drive
    (386) did not have enough resources left over to run many of the
    applications they wanted. Comparing windows to wb 2.0 is actually an
    insult to 2.0 . Sure they are both graphic user interfaces but even
    with some of the problems discussed 2.0 is a league ahead. As for
    useability how can you even compare a hack like windows to intuition.
    Windows can still hardly chew gum,and walk at the same time. If any
    feel intuition is tough to develop for then windows will be hell. 
    I may not be a programmer but in this instance I have the advantage.
    I own sas/c,and the rom kernal,intuition manuals. Not being a
    programmer I was able to at least follow the manuals,and open a window.
    A developer(msdos) I deal with through work has a set of window
    manuals,and it does not take a programmer to determine which
    enviornment is the easiest to develop for,and that includes the
    overhead of multitasking. This man is very good at what he doe's and he 
    is even daunted by windows. If you want to compare apples,and oranges
    fine, but frankly I am amiss at how many people don't see windows for
    what it really is "Window Dressing". At least os/2 is a viable os, and
    with Presentation Manager I can multitask. Windows is the biggest con
    since the PC. 
    							bill

I've had an Amiga since day 1 (developer's kit), and observed a lot of the
trouble programmers used to "normal" micros had adjusting to it. Turned out that
two things were problems: (1) folks who simply had no graphics background and
were intimidated by the fundamental graphic orientation of a GUI; and (2) those
who simply couldn't "grok" the operation of a multitasking OS. It was both
amusing and frustrating for someone who was coming from a VAX background.

At the time (and since then) I attributed the problem to Commodore's marketing
the Amiga as a PC instead of a low-end workstation, thus attracting the wrong
pool of programmers/developers. Now I believe that OS/2 faced the same quandary,
with your basic PC programmer quite used to his/her task having the whole
machine to play with. From the user's point of view, OS/2 was slow and big, and
a population of users not aware of the benefits of multi-tasking could only
compare drawbacks to benefits they had to take on faith.

Windows, on the other hand, is smaller and faster, and removes the need to
understand multitasking to develop new applications, as well as the need to
totally restructure existing single-threaded applications to multitask. It's no
wonder that it's beating OS/2 up.

As to the comparison between Workbench and GUIs such as Motif, the basic
approaches to providing an interface are quite similar, IMHO- as far as the
windows/graphics part goes, anyway. The distinctions Motif and its ilk have are
(1) they include not only a GUI, but inherent support for transparent
client-server network operations, and (2) their architecture is built around not
only a set of standard interface routines to create and manipulate an interface,
but also a set of standard GUI *objects* and guidelines on how the interface
should be presented to the user. Workbench has the latter, but it's not as
strongly pushed as Motif/Xwindows/DECwindows are; I haven't seen GadTools, but I
understand that it's at least a first cut at the equivalent of the X Toolkit. I
don't see client-server coming down the pike for Workbench in the foreseeable
future.

Windows for the Amiga? Not a problem, but why bother? The real problem in
porting a PC program to the Amiga will probably most often lie in restructuring
it to allow for multitasking and to remove the hardware-dependent code so
beloved of many MS-DOS developers. I personally feel that in the long run the
"Window Wars" will end up with all interfaces migrating (at whatever speed)
towards the evolving OSF/Motif standard, with the OS following at a slower pace
moving toward OSF Mach1 (the future incarnation of Unix/Posix).

(Remember, you heard it here first!)

Now back to spectating...

Cheers,
	Bob

Ok folks, my local part time radio shack salesman friend, who works very 
closely with both Microsoft and Intel in his real job, told me some interesting
news last night...

Microsoft is currently working on DOS 5.0 (no big surprise, right?). 

Well, DOS 5.0 will have it's OWN GUI which will be "windows like". DOS 5.0
will have a built in task switcher. Running the then current version of
Windows on top of DOS 5.0 will provide "true multitasking".

john

    Meanwhile, we are slowly coming up toward the level of formal Macintosh
    UI standards.  Herewith from Usenet...
    

From: [email protected] (Peter Kittel GERMANY)
Newsgroups: comp.sys.amiga.misc,comp.sys.amiga.programmer
Subject: Amiga User Interface Style Guide
Date: 6 Feb 91 11:59:34 GMT
Organization: Commodore Bueromaschinen GmbH, West Germany
Lines: 20
 
 
Just got the list from Addison-Wesley "New books Jan-Apr 91".
On p. 24, we find:
 
Amiga User Interface Style Guide
by  Commodore-Amiga Inc.
April, 208 pages, $25.25
 
The Amiga is known for its unique, highly interactive user interface.
This addition to the Amiga Technical Reference Series provides the
first definitive description of the design principles that make the
Amiga's user interface effective, efficient and easy to use. The
Amiga User Interface Style Guide details all the standard elements
of the Amiga user interface. It documents the conventions that should
be followed when writing applications for the entire line of Amiga
computers, including the new Amiga 3000.
 
-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk

    
    But will it have pull down screens? :-)
    
    It should be interesting to see how well they pull it off.  Windows
    has been very successful, selling over 2 million copies.  But that's
    a very small percentage of installed base.  It sounds like they
    realize that, and with 5.0 are aiming giving you the wonders of
    multitasking without the overhead of the WINDOWS GUI.
    
    Dave

Personally, I think if I had GUI Windows I'd fire my housekeeper...(nyuk)

    
    Just to add my $.02...
    
    I think Windows may be the way it is in large part from a fear of the
    mighty Apple legal department.  However, there are some nice concepts,
    at least from a user's standpoint.  For example, the desktop organizes
    applications by 'program group', as opposed to physical directories. 
    This is, in effect, a graphical alias, which has been announced by
    Apple for their system 7.0.
    
    You can also launch batch files from the desktop, like the Amiga's
    IconX, something that the Mac doesn't do.  And their file requestor
    supports filters.  All in all, it is a pretty good effort, considering
    previous tries.
    
    Ed.
    
    

The comment about installing windows on day 1, and chunging it on day 2
reminds me of a note from a local trade rag. Seems that retailers are
selling 4 times as many copies of windows as they are of all windows apps
combined. The speculation from the source of this figure was that windows
was sitting on the shelf next to the apple II.

>> I personally feel that in the long run the� "Window Wars" will end up
>> with all interfaces migrating (at whatever speed) towards the evolving
>> OSF/Motif standard,

That's a scary thought. Motif has been tagged as suffering from "Second
System" problems - it's got more bells and whistles than any one person
could possibly want, but most of them are unusable. I love some of the
flexibility. I think the way it interacts with the world is crocked.

Or, to quote others, "Imagine what OSs would  be like if we'd standardized
on one in 1959."

	<mike

    	And now "GeoWorks" has popped up with ITs entry to the DOS/GUI
    rodeo. Their entry costs more than Windows but includes a number of
    Apps as a starter kit. I doubt if it is curently set up to do multi-
    tasking but the software it is based on, GEOS for the C=64, can now do
    Task Switching (compliments of third-party hackers) so anything is
    possible. After all, it runs on a 4MHz/.5Meg XT (or better) so it OUGHT
    to have a bit more oomph than the original. I suspect that the geoWorks
    package will be the favorite among PC/XT/AT/386SX users regardless of
    how many copies of Windows sell to 386/486 owners. Still, it doesn't
    really do what a Mac or an Amiga can - it just helps keep things simple
    for we who need it.

Re: .26

>Or, to quote others, "Imagine what OSs would  be like if we'd standardized
>on one in 1959."

Thank goodness the world waited until the '70s when UNIX as invented! :-)

I once went to hear a talk by Thompson at MIT.  Thompson said one of
the professors had said to him, "I hate you.  UNIX stopped all research
in operating systems."  Thompson apologized.

>>	 I personally feel that in the long run the� "Window Wars" will end up
>> 	with all interfaces migrating (at whatever speed) towards the evolving
>> 	OSF/Motif standard,

>>>That's a scary thought. Motif has been tagged as suffering from "Second
>>>ASystem" problems - it's got more bells and whistles than any one person
>>>could possibly want, but most of them are unusable. I love some of the
>>>flexibility. I think the way it interacts with the world is crocked.

>>>Or, to quote others, "Imagine what OSs would  be like if we'd standardized
>>>on one in 1959."

Well. folks, this is the real world. GUIs have been shown to be a "good thing,"
productivity-wise, and they're with us to stay. Regarding standardization, to
be useful a GUI has to do several things:


(1) Show a good score on the scale of "allows->encourages->requires" consistent
interface styles;

(2) Allow developers to do what they need/want to with a minimum of contortion;

(3) Allow users to do the same;

(4) Present an interface which is relatively consistent with other products with
which users are familiar.


The first three are where all the debates about good-better-best (or use the
opposites, if you're inclined to be negative) lie; the latter has to do with
market penetration more than with relative judgements of "goodness." I think the
existence of the PC proves my point.

Once a "standard" such as a GUI or OS is chosen, the arena for combat has been
defined, and the real fun starts! Then, instead of competing with apples and
oranges, the major players push, poke, and prod at the *same* product to
influence it toward their needs/wants. I happen to think that OSF has the best
shot at producing standards for GUI and OS which are both technically adequate
and acceptable to the industry players at large. The force which is driving
the standards process faster than would otherwise be deemed wise is the
realization on the part of major software purchasers (like *real* big-bucks!)
that standards are a "good thing."

A fellow I used to work for used to love saying "In the future we'll be using
a language with pointers, record types, standard I/O routines and a number of
low-level features- and it will be called FORTRAN." The point is, it's not what
you call it, but what it is/does. Getting everybody into the same room to argue
and produce a single way to do things is, in the end, superior to allowing major
vendors (e.g., Sun, HP, Microsoft, DEC, IBM) to simply say "I don't like your
game, so I'm going to my room and play my own game." Developers lose, the
customers lose, and a lot of human endeavor which could be put to better use is
lost.

Anyway, I've put in more than my nickel's worth. Interesting topic, standards.

Cheers,

	Bob

>> I once went to hear a talk by Thompson at MIT.  Thompson said one of
>> the professors had said to him, "I hate you.  UNIX stopped all research
>> in operating systems."  Thompson apologized.

The professor exagerates - but not by much. The comments by Bob in .29
are relevant in both cases. Oddly enough, there's been some talk in
comp.society.futures about windowing systems, and an interesting article
(included below) on OS developement (included below) landed in my
mailbox recently.

The problem with OSF/Motif - and X in general - is not that it's missing
features; it's that critical parts of it are arcane and unusable. I'm not
sure that the resource mechanism can be deleted from it in any reasonable
way.

	<mike

This is an excerpt from Dick Gabriel's paper, "Good News, Bad News, and
How to Win Big."  The "MIT guy" and "Berkeley guy" mentioned herein are
Dan Weinraub and Bill Joy.

- ---------- cut here and glue this to the inside of your forehead ----------

2.1    THE RISE OF ``WORSE IS BETTER''

I and just about every designer of Common Lisp and CLOS has had extreme
exposure to the MIT/Stanford style of design. The essence of this style can be
captured by the phrase ``the right thing.'' To such a designer it is important
to get all of the following characteristics right:

  + Simplicity -- the design must be simple, both in implementation and
    interface. It is more important for the interface to be simple than the
    implementation.

  + Correctness -- the design must be correct in all observable aspects.
    Incorrectness is simply not allowed.

  + Consistency -- the design must not be inconsistent. A design is allowed to
    be slightly less simple and less complete to avoid inconsistency.
    Consistency is as important as correctness.

  + Completeness -- the design must cover as many important situations as is
    practical. All reasonably expected cases must be covered. Simplicity is
    not allowed to overly reduce completeness.

I believe most people would agree that these are good characteristics.  I will
call the use of this philosophy of design the ``MIT approach.''  Common Lisp
(with CLOS) and Scheme represent the MIT approach to design and
implementation.

The worse-is-better philosophy is only slightly different:

  + Simplicity -- the design must be simple, both in implementation and
    interface.  It is more important for the implementation to be simple than
    the interface. Simplicity is the most important consideration in a design.

  + Correctness -- the design must be correct in all observable aspects. It is
    slightly better to be simple than correct.

  + Consistency -- the design must not be overly inconsistent.  Consistency can
    be sacrificed for simplicity in some cases, but it is better to drop those
    parts of the design that deal with less common circumstances than to
    introduce either implementational complexity or inconsistency.

  + Completeness -- the design must cover as many important situations as is
    practical. All reasonably expected cases should be covered.  Completeness
    can be sacrificed in favor of any other quality. In fact, completeness
    must sacrificed whenever implementation simplicity is jeopardized.
    Consistency can be sacrificed to achieve completeness if simplicity is
    retained; especially worthless is consistency of interface.

Early Unix and C are examples of the use of this school of design, and I will
call the use of this design strategy the ``New Jersey approach.'' I have
intentionally caricatured the worse-is-better philosophy to convince you that
it is obviously a bad philosophy and that the New Jersey approach is a bad
approach.

However, I believe that worse-is-better, even in its strawman form, has better
survival characteristics than the-right-thing, and that the New Jersey
approach when used for software is a better approach than the MIT approach.

Let me start out by retelling a story that shows that the MIT/New-Jersey
distinction is valid and that proponents of each philosophy actually believe
their philosophy is better.

Two famous people, one from MIT and another from Berkeley (but working on
Unix) once met to discuss operating system issues. The person from MIT was
knowledgeable about ITS (the MIT AI Lab operating system) and had been reading
the Unix sources. He was interested in how Unix solved the PC loser-ing
problem. The PC loser-ing problem occurs when a user program invokes a system
routine to perform a lengthy operation that might have significant state, such
as IO buffers. If an interrupt occurs during the operation, the state of the
user program must be saved. Because the invocation of the system routine is
usually a single instruction, the PC of the user program does not adequately
capture the state of the process. The system routine must either back out or
press forward. The right thing is to back out and restore the user program PC
to the instruction that invoked the system routine so that resumption of the
user program after the interrupt, for example, re-enters the system routine.
It is called ``PC loser-ing'' because the PC is being coerced into ``loser
mode,'' where ``loser'' is the affectionate name for ``user'' at MIT.

The MIT guy did not see any code that handled this case and asked the New
Jersey guy how the problem was handled. The New Jersey guy said that the Unix
folks were aware of the problem, but the solution was for the system routine
to always finish, but sometimes an error code would be returned that signaled
that the system routine had failed to complete its action. A correct user
program, then, had to check the error code to determine whether to simply try
the system routine again. The MIT guy did not like this solution because it
was not the right thing.

The New Jersey guy said that the Unix solution was right because the design
philosophy of Unix was simplicity and that the right thing was too complex.
Besides, programmers could easily insert this extra test and loop. The MIT guy
pointed out that the implementation was simple but the interface to the
functionality was complex. The New Jersey guy said that the right tradeoff has
been selected in Unix -- namely, implementation simplicity was more important
than interface simplicity.

The MIT guy then muttered that sometimes it takes a tough man to make a tender
chicken, but the New Jersey guy didn't understand (I'm not sure I do either).

Now I want to argue that worse-is-better is better. C is a programming
language designed for writing Unix, and it was designed using the New Jersey
approach. C is therefore a language for which it is easy to write a decent
compiler, and it requires the programmer to write text that is easy for the
compiler to interpret. Some have called C a fancy assembly language. Both
early Unix and C compilers had simple structures, are easy to port, require
few machine resources to run, and provide about 50%-80% of what you want from
an operating system and programming language.

Half the computers that exist at any point are worse than median (smaller or
slower). Unix and C work fine on them.  The worse-is-better philosophy means
that implementation simplicity has highest priority, which means Unix and C
are easy to port on such machines.  Therefore, one expects that if the 50%
functionality Unix and C support is satisfactory, they will start to appear
everywhere.  And they have, haven't they?

Unix and C are the ultimate computer viruses.

A further benefit of the worse-is-better philosophy is that the programmer is
conditioned to sacrifice some safety, convenience, and hassle to get good
performance and modest resource use. Programs written using the New Jersey
approach will work well both in small machines and large ones, and the code
will be portable because it is written on top of a virus.

It is important to remember that the initial virus has to be basically good.
If so, the viral spread is assured as long as it is portable.  Once the virus
has spread, there will be pressure to improve it, possibly by increasing its
functionality closer to 90%, but users have already been conditioned to accept
worse than the right thing.  Therefore, the worse-is-better software first
will gain acceptance, second will condition its users to expect less, and
third will be improved to a point that is almost the right thing.  In concrete
terms, even though Lisp compilers in 1987 were about as good as C compilers,
there are many more compiler experts who want to make C compilers better than
want to make Lisp compilers better.

The good news is that in 1995 we will have a good operating system and
programming language; the bad news is that they will be Unix and C++.

There is a final benefit to worse-is-better. Because a New Jersey language and
system are not really powerful enough to build complex monolithic software,
large systems must be designed to reuse components. Therefore, a tradition of
integration springs up.

How does the right thing stack up? There are two basic scenarios: the ``big
complex system scenario'' and the ``diamond-like jewel'' scenario.

The ``big complex system'' scenario goes like this:

First, the right thing needs to be designed. Then its implementation needs to
be designed. Finally it is implemented. Because it is the right thing, it has
nearly 100% of desired functionality, and implementation simplicity was never
a concern so it takes a long time to implement. It is large and complex.  It
requires complex tools to use properly. The last 20% takes 80% of the
effort, and so the right thing takes a long time to get out, and it only runs
satisfactorily on the most sophisticated hardware.

The ``diamond-like jewel'' scenario goes like this:

The right thing takes forever to design, but it is quite small at
every point along the way. To implement it to run fast is either
impossible or beyond the capabilities of most implementors.

The two scenarios correspond to Common Lisp and Scheme.

The first scenario is also the scenario for classic artificial intelligence
software.

The right thing is frequently a monolithic piece of software, but for no
reason other than that the right thing is often designed monolithically.
That is, this characteristic is a happenstance.

The lesson to be learned from this is that it is often undesirable to go for
the right thing first. It is better to get half of the right thing available
so that it spreads like a virus. Once people are hooked on it, take the time
to improve it to 90% of the right thing.

A wrong lesson is to take the parable literally and to conclude that C is the
right vehicle for AI software. The 50% solution has to be basically right, and
in this case it isn't.

But, one can conclude only that the Lisp community needs to seriously rethink
its position on Lisp design.  I will say more about this later.

    re:.30
    
    Great article, except they forgot one thing: time to market
    
    You may not have enough time to do it "right" or to debate the 
    tradeoffs, you just pick whatever is the fastest to implement.
    
    Dave

    re: "they forgot one thing: time to market"
    
    No, no.  That's what baselevels and beta releases are for.  You release
    these at the originally announced market dates, and periodically there-
    after.  This can continue for as long as it necessary, just like it is
    for WB 2.0.
    
    8^}
    

    no, that's extended field testing.. :-)  Where you get customers
    to pay for that priviledge.
    
    I was referring to where you release the product on time, but it
    just doesn't seem to work right or is missing a number of features.
    
    That way they don't accuse you of vaporware :-)  And it teaches
    consumers about the wonders of great marketing.  You don't have
    to have a second release, you go out of business and then come
    back with a "totally new" product that is strangely like the old
    one.
    
    Dave
    

   Quoted from .30...
    
    	Unix and C are the ultimate computer viruses.
    
   I love it !

	That article was one of the more interesting things I have read lately.
Let me be nasty for a minute and ask the question, "How long has it taken the
'New Jersey Approach' to produce an operating system acceptable for wide spread
commercial use?" If we ultimately have to put in 90% of the right thing, does
the design not become complex? How much grief do the users go through in the
process?

	I would argue that the optimum point lies somewhere in the middle.
Probably somewhere in Connecticut. :~}

    re .35:
>Let me be nasty for a minute and ask the question, "How long has it taken the
>'New Jersey Approach' to produce an operating system acceptable for wide spread
>commercial use?"
    
    Do you mean MS-DOS, Microsoft Windows 3.0, or Unix? ;^)
    
>How much grief do the users go through in the
>process?
     
    It really comes down to what is an acceptable level of grief for users.
    If its enough to do the job, then its "acceptable" for alot of users
    
    dennis