Xref: utzoo news.groups:2621 comp.sys.mac:13191
Path: utzoo!utgpu!water!watmath!clyde!rutgers!topaz.rutgers.edu!webber
From: webber@topaz.rutgers.edu (Webber)
Newsgroups: news.groups,comp.sys.mac
Subject: Re: Call for votes: comp.binaries.hypercard
Message-ID: <18326@topaz.rutgers.edu>
Date: 25 Feb 88 11:08:47 GMT
References: <454@stech.UUCP> <960@athos.rutgers.edu> <42857@sun.uucp>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 71

In article <42857@sun.uucp>, chuq@plaid.Sun.COM (Chuq Von Rospach) writes:
> ...
> >By promoting ascii-readable hypercard stacks (databases), it becomes easier
> >for people to write awk scripts for processing stacks on normal unix systems.
> 
> Except, of course, that the major components of a HyperCard stack, the
> graphics, backgrounds, layout, icons, buttons, XCMDS and XFCNS, can't be
> translated to ascii readable anything, and without them, the scripts Webber
> is doting on are useless. Webber, as usual, is showing his total ignorance
> of the subject at hand.

Having read Goodman's The Complete Hypercard Handbook, I see the graphics
aspect of a typical stack is rather minimal and that HyperTalk gives a
reasonable amount of functionality.  The real value of a stack is in the
textual information stored there and the interconnections between that
information that are also stored there.  The graphics, backgrounds, ...
that you dote on are primarily the hype of hypercard and not its substance.

> Yeah there is. you can't post Hypercard stacks in any other format. You
> certainly can post hypercard scripts, and I encourage people to do so, but
> what Webber is proposing is like telling people that instead of posting the
> entire program, they can only post the library routines, leaving main() as
> an exercise for the reader.

Absolutely not.  HyperTalk can handle the main() as well.  This isn't the
way the Apple people encourage you to use their system but they are still
wrapped up in appliance computers.  Any programmer could cons up the
scripts in HyperTalk that would create the same stacks as a non-programmer
hacks together.

> >If hypercard is any
> >good, its stacks will be of interest to many people other than mac owners
> 
> Except, of course, that Hypercard only runs on a mac.

It is not necessary to run Hypercard to extract info from a stack anymore
than it is necessary to have troff to make use of bibliographies passed
around in refer format (as long as the format is easily readable like the
refer format is).

>...
> Again, Webber shows his ignorance. HyperCard was designed to be extensible.
> Accusing it of failure because people use its extensibility is like accusing
> C of being a bad language because people use things like libraries. 

?  On my computer, the libraries are written in C!

>...
> One hypercard stack. And the folks who did it are well known psychotic
> paranoids. And accusing Hypercard stacks because of a single virus incident
> is rather silly, since viruses can (and have been) installed in programs
> under many operating systems and environments, including, I might point out,
> Unix. So this is a non-argument.

Not so much a failing of hypercard stacks, so much as a general
problem with accepting binaries in any system.

Your little tirade on obsfucation was amusing.  The issues are really
simple.  Usenet is based on Unix which is grounded in a philosophy of
open systems, machine independence, and knowledgeable users using
sophisticated tools.  Binaries are closed, system dependent, and based
on hiding the workings from the user (for their own good, of course).
While some people are willing to tolerate binary groups because of the
general ``potential'' of micros, this is mostly because the typical
micro binary would be useless to anyone else as it is just an attempt
to implement standard functionalities in a particularly restrictive
environment.  However, with hypercard, you are beginning to develope
structures that would useful on non-micros.  To purposely pass such
information in needlessly obscure formats is really quite improper.

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