Xref: utzoo comp.arch:4725 comp.lang.misc:1572
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ncar!gatech!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Universal OS (striving for flexibility)
Message-ID: <1088@mcgill-vision.UUCP>
Date: 9 May 88 23:07:26 GMT
References: <769@imagine.PAWL.RPI.EDU> <76700017@uiucdcsp> <843@actnyc.UUCP> <764@l.cc.purdue.edu>
Organization: McGill University, Montreal
Lines: 113

[> and >>> = Herman Rubin, cik@l.cc.purdue.edu]
[>> = Radford Neal, radford@calgary.UUCP]
>>> ... The language, shell, window, editor, etc. developers should try
>>> to find out everything that [anyone wants] and try to include it
>>> _all_.

This is a nice ideal.  However, it has problems.

- Just finding out what everyone wants will take forever.  I don't just
  mean a long time, I mean forever.  By the time you've finished asking
  everyone, the people you've already asked will have changed their
  minds, and new people with new opinions and desires will be here.

- The result will be unimplementable.  It will be so large that not
  only is it impossible for one person to understand the whole thing,
  but the number of people necessary to do it will be so large that the
  project will collapse under its own weight.  Read Fred Brooks' book,
  and imagine a system two orders of magnitude larger than what he's
  describing.

- Once implemented, even assuming it ever gets done, the result will be
  too large to run on enough machines to make it useful, and too slow
  to be useful even on the machines it will fit on.  (Perhaps not;
  hardware capacity and speed are exploding fast enough that by the
  time your project is done, it might be able to run.)

>> GAK!  Have you ever _tried_ designing, and implementing, a language,
>> editor, etc.?
> I am not in a position to implement a language.

Yet you try to tell the language designers and implementors their job?
I, too, believe current languages are imperfect.  I, however, realize
that there are probably reasons why this is true.  I have done some
preliminary thinking on designing and building a new language, and the
more thought I put into it, the more I realize why things are the way
they are.

> The major problem with the languages, editors, etc., is the fantastic
> number of conventions.  I doubt that there is any language which has
> less conventional notation than any branch of mathematics.

This is unclear.  "...has less conventional notation than...": does
this mean "...has notation which is less conventional than that of..."
or does it mean "...has less of conventional notation than..."?

Either way, so what?  I fail to see why you keep trying to draw
analogies with mathematics.

> The conventions of editors are worse; a given letter on one has a
> vastly different meanin from the same on another.

To draw an analogy of my own with mathematics, how many different,
incompatible, meanings does the `+' symbol have?

> Of course, one cannot include everything.  But one can facilitate the
> addition of those things.  Many mathematics papers introduce notation
> unknown to the reader.

This happens when programming, too: it's called defining a function (or
declaring a procedure, or whatever the idiom is for the language in
question).

> Some of this even persists.

This corresponds to what are called libraries.

>> As for "extensibility", it is much over-rated.  Somehow, it always
>> seems that the really useful modifications are beyond the
>> capabilities of the extension mechanism.
> This means that the extension mechanism is too weak.

Unfortunately, we don't know how to design a really general extension
mechanism, unless you count giving out the source code as providing an
extension mechanism.

> Most extension procedures are overly restrictive, and do not assume
> that the user wants to, say, introduce an operation which is not of
> the type envisaged by the language designers.

Most programs of any size introduce operations not envisaged by the
language designers.  They are called "functions".  For example, the
editor I'm using to type this, a derivative of Gosling Emacs, has an
internal operation which sets something called a marker.  The designers
of C, the language it's written in, did not explicitly provide for this
operation, but they provided a mechanism for defining this operation,
and it works.

>> A universal operating system will be designed when [...read the
>> original if you want the details].  If this should ever occur, the
>> universal model will be much more likely to encorporate _none_ of
>> the ideas of past "programming geniuses" than to encorporate them
>> all.

I agree with this, that the next truly great operating system,
language, editor, whatever, is much likelier to incorporate none of the
ideas of the past than to incorporate them all.

> I have specifically argued against the idea that there is even a
> complicated model of computer use that encorporates the needs of even
> a majority of the intelligent users, and the technology of today
> changes so rapidly that Radford's ideas can only produce obsolete
> systems.

Until the next genius comes along, we have to do what we know how to
do.  From what I've seen of your ideas, I don't expect them to produce
any sort of system, while if we keep doing what we know how to do, we
will keep getting useful (though imperfect) systems out.  I may be
wrong; someone may build a system based on your ideas.  But I'll have
to see it to be convinced.

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu