Xref: utzoo comp.sys.mac:13173 news.groups:2614
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!hao!boulder!sunybcs!rutgers!topaz.rutgers.edu!webber
From: webber@topaz.rutgers.edu (Webber)
Newsgroups: comp.sys.mac,news.groups
Subject: Re: Call for votes: comp.binaries.hypercard
Message-ID: <18323@topaz.rutgers.edu>
Date: 25 Feb 88 10:11:27 GMT
References: <454@stech.UUCP> <960@athos.rutgers.edu> <5534@cit-vax.Caltech.Edu>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 85

[For those actually interested in what can and can't be done with hypercard,
I recommend Goodman's The Complete Hypercard Handbook.  While micro users
seem to prefer to transfer core images (probably because they can't comprehend
the notion that a 500meg disk could ever fill), all the tools are available
to transfer hypercard stacks as a few background macpaint images, some textual
databases, and some hypercard scripts in what is essentially a ``source'' 
format.  This usage of hypercard is discussed under the term hypertalk
as well as appendices on exporting and importing data.]

In article <5534@cit-vax.Caltech.Edu>, lim@cit-vax.Caltech.Edu (Kian-Tat Lim) writes:
> In article <960@athos.rutgers.edu> webber@athos.rutgers.edu (Bob Webber) writes:
> >By promoting ascii-readable hypercard stacks (databases), it becomes easier
> >for people to write awk scripts for processing stacks on normal unix systems.
> 
>If you knew much about HyperCard, you would realize that the foundation of the
> program is its graphics capability.  In particular, each card contains two
> full-screen (-window for Mac II's) bitmap planes.  It is simply not efficient
> to convert this to an "ascii-readable" form, and without the graphics,
> the stack is essentially useless.  HyperCard is most emphatically *not* a
> simple database (although it may be used as such), and the idea of processing
> a stack with an awk script is almost ludicrous (since interactivity and an
> event-driven programming style is also a HyperCard fundamental).

QUITE WRONG.  If you knew much about databases, you wouldn't call them
``simple.''  Most of the hypertext literature appears as a subset of
the database literature which includes non-relational structures and
user interface matters (although I can understand how a typical micro
database system could give a rather limited notion of what databases
are all about).

It is a shame that they use bitmap graphics rather than object oriented
(i.e., modelled on macpaint instead of macdraw), but then Apple sells
memory upgrades and hard disks, so one can't expect them to be too
concerned about this.  Although I am sure you could cons up a stack
that is nothing but gratuitous graphics, most useful stacks will
contain substantial textual information (e.g., the editor of
otherrealms has spoken of a bibliographic sf stack which will
doubtless contain little graphics and the developers of hypercard are
busy converting a library's card catalog into hypercard format).  The
relatively few backgrounds needed for a given stack implementation
(after all, who has time to hand ``paint'' thousands of cards) can
easily be stored in readable form (although even if you had to just
uuencode the macpaint images, that is no reason to pass around the
entire application as a binary).  Of course, one can use external functions
to implement custom animations on each card, but to do this you are using
so much non-hypercard code that you have something much more akin to a
traditional binary (certainly not something common enough to require a 
group of its own).

On my system, awk is interactive and event-driven!  And, of course, there
are many other tools if I don't feel like using awk.  While the environment
is program-rich, it is data-poor as with most of the net.  This is a major
reason for objecting when people want to use massive net resources to transfer
data-rich files in obscure binary formats.

>It might be possible to create a format which would include the stack contents
>in a transportable (though probably not ASCII) way; this might allow stacks to
> be ported to an Amiga or Atari ST or Sun workstation.  Of course, this would
> require an implementation of HyperTalk and probably all of HyperCard on the
> foreign system, certainly a non-trivial task.

Actually, not all that big a deal on a Sun where you have Common Lisp with
hooks out to the windowing software.  There is a big difference between 
implementing hypercard on a Mac and achieving comparable functionality on
a Sun 3.

>...
> they need to be able to; rather, I foresee people saying, "Gosh, I wish I had
> bought a Macintosh so I could use this stuff!"  (Sorry for the pro-Mac bias.)
> As a parallel, I know some people who think Suntools is the greatest thing
> since sliced bread (and not all of them are Sun owners/users).  

Actually I would think few of them would be Sun owners.

>...
> >By the way, those of you who read comp.risks are already aware of the
> >viruses that have already appeared in some hypercard stacks.
> 
> Those of you who read comp.risks are also aware of the viruses that have
> appeared in IBM PC executables; should we discontinue posting of those, also?

Of binaries?  You ask me?  Of course discontinue those to.  While it
is true you can hide viruses in source also, the vast majority have
shown up in systems where users accepted binary without source.

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