Path: utzoo!attcan!uunet!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Computers for users not programmers
Message-ID: <4898@mentor.cc.purdue.edu>
Date: 31 Jan 91 14:32:47 GMT
References: <4724@mentor.cc.purdue.edu> <12953@lanl.gov>
Sender: news@mentor.cc.purdue.edu
Lines: 58

In article <12953@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> From article <4724@mentor.cc.purdue.edu>, by hrubin@pop.stat.purdue.edu (Herman Rubin):
> > [...]
> > What does happen is that the user is taught that what the guru has put in
> > the language, system, etc., is what the computer is capable of.  The user
> > is deliberately kept from even finding out the capabilities of the hardware,
> > and then the hardware is built in such a way as to make these capabilities
> > difficult and expensive.
 
> You have just vehemently agreed with me!  Learning about the hardware
> and figuring out how to make better use of it is _one_ of the things
> that _is_ worth learning about.  It's all those poorly designed and
> fairly week UNIX 'tools' that are hard to learn, hard to use, and don't
> do much that's worthwhile that I object to - I don't want to be stuck
> using what some 'guru' tells me to use either.
 
> Simple, easy to use, access to the guts of the machine is a worthy
> goal for OS design.  I agree wholeheartedly with you on this.  It's
> only one of the worthy goals though.  Some people already have excess
> capacity on their machines and don't need to push performance any
> more.  These people have different goals than you do.  Strangely,
> one of the few thing that you have in common are that the UNIX style
> of tools hold you both back (for different reasons).

I have not agreed with you.  Access to the guts of the machine has been
made purposely difficult in all systems which I have seen recently.
It is not for OS design only; user applications need what the gurus,
information suppliers, etc., have not seen fit to make available to
the users.  Then the next stage of hardware designers leaves out operations
simple in hardware and very messy and costly in software.  In many cases,
the design of the 50s with modern technology would outperform the present
stuff.

> So, the point about designing systems for people instead of training
> people for systems is this: systems should be designed to make it
> easy to perform those tasks which people want to do.  You want to
> engage in 'full contact programming' - so the system be designed to
> allow you to do that.  It should _NOT_ be designed to _require_
> everyone else to use the machine the way you want to.  Similarly,
> other users have different needs and the way they work should not
> be forced upon you.  This brings us to the UNIX tools/pipes/shells
> crowd: who want to force _their_ way of woring onto _everybody_.

I believe the systems are doing too much already.  A compiler, editor,
etc., should not be part of a system.  Loaders of fully compiled files,
file manipulation, job allocation, etc., are needed.  The system should
make provision for flexible inclusion of the others.

The UNIX guys are not the only ones.  It is not UNIX which requires 
executable files to have a designation .exe.  The UNIX loaders which
I have used do not restrict object files to have a .o designation.
Try to get documentation for the guts of a machine written with the
idea that an intelligent user will do something which was not anticipated
by the manufacturer or vendor.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)