Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!cornell!uw-beaver!mit-eddie!ll-xn!ames!aurora!labrea!rocky!rokicki
From: rokicki@rocky.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: AREXX and ICP
Message-ID: <632@rocky.STANFORD.EDU>
Date: Thu, 1-Oct-87 14:20:50 EDT
Article-I.D.: rocky.632
Posted: Thu Oct  1 14:20:50 1987
Date-Received: Sat, 3-Oct-87 06:33:01 EDT
References: <267@mitsumi.UUCP> <3939@well.UUCP> <20098UH2@PSUVM> <28070@sun.uucp> <2391@cbmvax.UUCP> <838@sugar.UUCP>
Reply-To: rokicki@rocky.UUCP (Tomas Rokicki)
Organization: Stanford University Computer Science Department
Lines: 76

> The last thing the Amiga needs is another programming environment, with
> more hooks that people have to make to their programs if they want them
> to be competitive. One of the things Apple did right was force
> developers to stick to the standard user interface. The Amiga has two
> standard interfaces right now: the workbench, and the CLI. I like this,
> although I think that it could have been done without forcing two
> programming environments on people (yes, I know something about the
> history behind it and understand that there really wasn't much in the
> way of alternatives).

I disagree.  The Amiga certainly needs a standard for communication among
programs, one that the global single clip-board does not address.  Because
the applications that will be interfaced cannot be forseen, it should be
programmable, preferably by the user.

The Amiga also needs a standard macro language that all applications can
share, once again, user programmable.  Then only one macro language need
be learned, and everyone is happy.

One thing that must be understood is that there are different levels of
users.  The novice feels right at home with the workbench, because of
its visual nature.  Expert users usually feel encumbered by the workbench;
it is much faster to type a command than to point and click, point and
click, oh, there's the program, point and click.  I think putting both
interfaces on the Amiga was a major win.

But we still need a scripting language; the CLI stuff just isn't smart
enough.  Every major operating system that I know about has developed
a powerful scripting language; Unix has shell, IBM has REXX, VMS has
DCL, etc.  One of the uses of this scripting language, of course, is to
present a cleaner interface to the end user.

> In any case people should be encouraged to develop tools and
> applications that fit in with the existing CLI and Workbench unless
> there's an overriding reason not to. REXX as a script language is
> probably really useful for some people...maybe even me. REXX as a
> new programming environment with custom ports and stuff is overkill.
> REXX as a device (REXX:) is better. It's still not perfect, because
> maybe other scripting languages would be better for other people
> (icon, or awk, or sed, or...). What's wrong with a CLI:?

People should definitely build tools that work with CLI and Workbench.
But there are many things that cannot be done with CLI or Workbench.
The thing is, REXX should be there if you need it; if you don't, good,
don't use it.  Other people will.  Why is REXX with custom ports
overkill?  I don't understand that at all.  If you think REXX would be
good as a device, you are missing the main point of REXX.  How can a
device invoke primitives from a program?  Normally, a device acts
strictly as a slave to a program; REXX and a program can interact at
different levels, with the program as a slave to REXX, vice versa, or
with the two of them communicating much more on a peer basis.

Other scripting languages will always be good for other people.
But, REXX exists, works well in the Amiga environment, and gives
one an incredible amount of power.  Today.

> Finally I think people at C=, and C= in all its corporate glory, should
> be discouraging people from making the Amiga even more of a mishmash of
> operating systems than it is. While encouraging people to develop
> standard tools and applications that fit well together, of course.

And what better way to encourage standard tools and applications that
fit well together, then by proscribing and supporting a standard and
programmable means of communication among tasks?  This is a problem
that won't go away be pretending it doesn't exist, Peter; until a
standard is agreed upon, people will continue to write non-cooperative
tools or tools that cooperate in incompatible ways.

It's really that simple.

> Instead of discouraging people who are trying to keep what conceptual
> integrity remains intact.

The conceptual integrity shall remain intact, perfectly intact.
It will just be made more powerful, extended for those of us who
need such extensions.