cmcmanis%pepper@Sun.COM (Chuck McManis) (05/11/88)
Several people have called for cloning certain aspects of the Macintosh
`paradigm' here and frankly I am a bit amused by it.
The biggest question is of course "Did you just wake up after a 5 year
period of sleep?" No? (Just kidding folks) Apple has *millions* of dollars
in the bank and nowhere to spend it, but lawyers can spend it so they
seem to give them free reign. Basically, throwing lawsuits out like I
might throw out those little plastic bags 3.5" floppies come in. Regardless
of your or my feelings on the merits of these cases, the people being sued
*must* defend themselves (or lose by default) and that takes many precious
resources that neither you, nor I, nor Commodore, nor anyone have to spare.
IBM can shut down innovation by stuffing 10 year old technology down our
throat as "standard", Apple stifles innovation by suing everybody in sight.
Basically, it is in their best interest to do so.
So when people spout off with "Let's clone HyperCard!" or "Lets clone
QuickDraw!", or even "Let's not reinvent the wheel, lets steal Mac
Resources!" I can only suggest that it is a waste of time. If your
activity ever came close to being a commercial success you would lose
real big, real fast.
Rather than ask "How can we do this Mac thing on the Amiga?" ask instead
"How can we solve the problem that this Mac things solves better?" A
case in point is user interfaces.
User interfaces are designed to be intuitive things that you and I can use
to get something done with the machine. By applying the principle of least
astonishment, we can demonstrate that it is good for things that do similar
things have similar user interfaces. (This does not imply that different
things have similar user interfaces.)
The IBM PC has the user interface of CP/M and a zillion computers before
it. You sit looking at a prompt and 'tell' the computer what to do using
something very roughly approximating an english sentence. On the Macintosh,
they use the user interface that was pioneered by Xerox as part of an
effort to change how humans saw computer/human interaction. Unfortunately,
when they borrowed the "look and feel" they seemed to have lost the
"reason and function" of that user interface.
Now on the Amiga we have a user interface that has a little of both in
that one is window oriented and the other text oriented. But we also have
the capability of *throwing out* the systems idea of a user interface and
supplying our own. If it SOLVES THE PROBLEM, then it will be accepted as
an improvement.
One of the things that Xerox pioneered, and Apple lost, are of course
Objects. Objects are those things that the computer works on and does
reasonable work on. In nearly every computer universe concieved these
Objects are named. Now many people have discussed object oriented systems
so I won't go into them in great depth here, the point being that this
is the PROBLEM, that the user interface is trying to solve. How to
convey to the computer what Actions to perform on what Objects to
accomplish some Goal.
This of course is an open ended problem that has many solutions, but what
the Amiga can try to do is move it's user interface toward solving the
problem, and as I don't think either the Mac or the IBM PC solve the problem
to well, there is little likelyhood of doing something that those monoliths
will be doing.
Consider the following random thoughts ...
What is an icon? It is a handle on an object that the user can point too.
What is a window? It is a manifestation of an Active Object that gives
visibilty to the internal actions/properties of an Object.
How do you activate an Object? You give it something to work on by dropping
another object on to it.
How do you control an Object? Through it's opened window.
What does an Object do when you drop another object onto it that it
doesn't understand? It burps it back at you.
How do you create an Object? By dropping something on another object or
"kicking" it.
Same goes for "cloning" an Object, just drop is on a copy machine.
Some things you and I do to/with computers that could use this system ...
Want to edit a file? Kick a TextFile progenitor and it pops out a raw
text file Object. Drop the text file Object into an editor and change
its contents and properties (like it's name). Drop the Text File Object
on to the Compiler Object, if it understands the Text file (it has the
"C" property, although it could be a "Modula 2" property) it burps
out and Object Code object and maybe a TextFile errors object. Kick
the "NewObject" generator again and tell it has the property of an
executable. Now Drop that object, the ObjectCode Objects, and some
LibraryObjects into a LinkObject. It burps out a the ExecutableObject
again but now it does something useful.
I am sure you get the drift by now. This would be an all graphical system
that could do lots of stuff. The nice thing is that you can do this type
of design and brainstorming on the Amiga and have a reasonable chance of
it working with the existing system. Anyway, this has drawn on a bit to
long, bottom line : If you want HyperCard, Resource Forks, and QuickDraw
then buy a Mac for chrissake! Don't ignore this stuff and say "Oh we
don't need QuickDraw, cause we are better!" instead say "What problem was
Apple trying to solve with QuickDraw? Could I do it better? What doesn't
it solve? How can I use their experience to profit my design?" Think
forward, not backward.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.fiddler%concertina@Sun.COM (Steve Hix) (05/12/88)
In article <52787@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > One of the things that Xerox pioneered, and Apple lost, are of course > Objects. Well, not quite. Objects have stayed at the back of the picture at Apple, but have never quite gone away. They are doing most of their system work now in Object Pascal (with Object C, or C++, or whatever they're calling it this week, coming up on the outside). There are rumblings to the effect that their upcoming versions of the finder and it's successors will be more object-oriented. The finder currently is somewhat that way now, btw: You bump an object, and it (the finder?) looks for something that can deal with the object. It's got a long way to go, but they are thinking in that direction.
harald@leo.UUCP ( Harald Milne) (05/12/88)
In article <52787@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > Several people have called for cloning certain aspects of the Macintosh > `paradigm' here and frankly I am a bit amused by it. So am I. > Rather than ask "How can we do this Mac thing on the Amiga?" ask instead > "How can we solve the problem that this Mac things solves better?" A > case in point is user interfaces. Yes! Yes! Isn't that why we are here? > Consider the following random thoughts ... > Some things you and I do to/with computers that could use this system ... > Want to edit a file? Kick a TextFile progenitor and it pops out a raw > text file Object. Drop the text file Object into an editor and change > its contents and properties (like it's name). Drop the Text File Object > on to the Compiler Object, if it understands the Text file (it has the > "C" property, although it could be a "Modula 2" property) it burps > out and Object Code object and maybe a TextFile errors object. Kick > the "NewObject" generator again and tell it has the property of an > executable. Now Drop that object, the ObjectCode Objects, and some > LibraryObjects into a LinkObject. It burps out a the ExecutableObject > again but now it does something useful. Even better, recognize the file type, ala the BSD file command. Handle all aspects of this type as appropriate. Remove all notions of compilers, linkers and such drudgery. This is the object, do what is supposed to be done! Oooh. I like it! Object oriented OS! -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business!) UUCP: uunet!ccicpg!leo!harald
doug-merritt@cup.portal.com (05/14/88)
Harold Milne writes: >Even better, recognize the file type, ala the BSD file command. Handle >all aspects of this type as appropriate. I have written such a command for the Amiga, although it's a lot smarter than the Unix file command ("BSD" is overly specific, it's been supported on 100% of all of the Unix variants since at least version 6). It does a good job of recognizing just about any file type that *can* be recognized. And a few that can't. :-) About 120 different major types (e.g. IFF, english, spanish, mail), plus their subtypes (text with CR, ANIM, tool icon) and parameters (e.g. 47x53x3 image). Anyone interested? --- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug