🚀 go-pugleaf

In article <454@stech.UUCP>, sysop@stech.UUCP (Jan Harrington) writes:
> As you know from Chuq's message, there is a proposal to create a new group
> called comp.binaries.hypercard.  The purpose of this group is to speed the
> distribution of Hypercard stacks without all the delay that currently 
> surrounds them and to help people who aren't interested in stacks avoid
> plowing through a many-part posting.

While it is natural to oppose the creation of yet another moderated group
or of yet another binary group, I would like to point out that this particular
binary group would be even worse than usual.

The standard justification for a binary group is that you can't count on
other users having the same system that the original software was developed
for.  CLEARLY that is wrong here -- everyone has the same hypercard program!
By promoting ascii-readable hypercard stacks (databases), it becomes easier
for people to write awk scripts for processing stacks on normal unix systems.
While we may be stuck with binary groups for some systems due to historical
reasons, there is no need to create yet another one.  If hypercard is any
good, its stacks will be of interest to many people other than mac owners
(and if not, mac owners will also quickly tire of it).

[Note: there are also people posting stacks that contain non-hypercard code
as a hybrid system.  Considering the size of the Hypercard manual, if most
people find it necessary to augment the system to make something useful,
that too says something about hypercard.]

By the way, those of you who read comp.risks are already aware of the
viruses that have already appeared in some hypercard stacks.

---- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)