Xref: utzoo comp.sys.mac:13190 news.groups:2620
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!plaid!chuq
From: chuq@plaid.Sun.COM (Chuq Von Rospach)
Newsgroups: comp.sys.mac,news.groups
Subject: Re: Call for votes: comp.binaries.hypercard
Message-ID: <43182@sun.uucp>
Date: 25 Feb 88 18:17:03 GMT
References: <454@stech.UUCP> <960@athos.rutgers.edu> <5534@cit-vax.Caltech.Edu> <18323@topaz.rutgers.edu>
Sender: news@sun.uucp
Reply-To: chuq@sun.UUCP (Chuq Von Rospach)
Followup-To: news.groups
Organization: Fictional Reality, uLtd
Lines: 173

[and now, class, today on Mr. Chuqui's neighboorhood we again examine how 
 nasty, obnoxious people can ignore reality, twist the facts, and attempt to
 rewrite reality to fit their own goals irregardless of the needs of others.
 To wit, another rebuttal of one of Webber's rantings]

>[For those actually interested in what can and can't be done with hypercard,
>I recommend Goodman's The Complete Hypercard Handbook.

Nice book. Not complete, but well done. Doesn't cover XFCN's or XCMD's at
all, for instance. 

>While micro users
>seem to prefer to transfer core images

It isn't a core image. it's a stack. You probably don't understand the
concept, because old-fashioned machines like those you use aren't capable of
this sort of stuff.

>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.

Wrong. 

What you're saying, Mr. Webber, is because it would be more convenient for
YOU to see this stuff as component pieces, you want all the HyperCard
writers in the world to:

o disassemble their program into component parts
o write instructions on the re-assembly of same
o post component parts to the net.

All so, if you feel like it, you can take a look at it and say "that's nice.
Too bad Unix doesn't do this sort of stuff".

Then, you expect the readers to:

o download each component part
o read the instructions
o put it all back together
o get it right

You completely ignore the fact that many of these stacks (for instance, the
esperanto stack) are filled with data. So, you could add the stpes of
figuring out how to export all the data, format it for packaging, and import
it back into the stack, all without munging the data.

All so you can look at it and say 'that's nice.'

Webber, you're insane. Or simply selfish and stupid. I'm not sure which.
hyperCArd stacks are written for HyperCard, not for your specious enjoyment.
If you want to play with them, buy a Mac. but don't suggest that the mac
folks should go out of their way to make their software useless for everyone
simply because it doesn't fit your reality. Your reality is skewed and
selfish.

>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).

HyperCard is not a database. HyperCard is not Hypertext. You show your
ignorance.

>It is a shame that they use bitmap graphics rather than object oriented

Now, we watch as Webber uses the argument "I don't like the design of this,
even though I've never used it, so it has to be bad". Let me point out that
the Goodman book, which Webber uses above, has sold over 700,000 copies to
date, and Apple's figures that I've seen show that HyperCard has already
been put into use on over 20% of the Macintoshes in the installed user base.

Personally, what Webber thinks about HyperCard means squat. Lots of people,
on the net and throughout the country, use and like HyperCard. This group is
being put together to service them, not to be turned into a personal
stomping ground for Webber. 

>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).

It's obvious Webber hasn't looked at many HyperCard stacks. There's a strong
mix of graphic and textual oriented systems. There are even games, including
a version of Shanghai, an arthurian jousting simulation, and graphic/text
adventure games. 

As to the SF stack he mentions (which I happen to be the developer of) he's
showing his ignorance. Primarily textual? Why? One thing HyperCard would
allow me to do, for instance, is use a scanner to digitize the cover and put
the cover into the database. Or add digitized pictures of the authors. Or
perhaps their pets and houses. Webber, you don't know what you're talking
about. you're thinking in terms of yesterday. So please, shut up and don't
bother us folks who're trying to put together tomorrow.

>The
>relatively few backgrounds needed for a given stack implementation
>(after all, who has time to hand ``paint'' thousands of cards) can

Lots of people. Again, he's showing amazing ignorance about what IS
already being done.

>(although even if you had to just
>uuencode the macpaint images, that is no reason to pass around the
>entire application as a binary).

Again, his ignorance. He's equating that the parts are the sum of the whole.
Not true. As I mentioned above, there is the little matter of all the
development time involved in putting the pieces together, setting up the
interactions and links, and getting them placed properly.

Put this in a Unix context. From now all, all postings to comp.sources.unix
will be made one function at a time. After all, I might want to use that
function in something else, and we certainly don't want me to have to go
looking for it. 

Oh, and while you're at it, we won't ship Makefiles anymore. They can't be
used on all systems. So you'll have to figure out how to put the pieces
together into a program, and what the compile line ought to look like. 

Now, wouldn't that just please the Unix folks a whole lot?

>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).

bullshit.  I'd say, from the stuff I've looked at, that something like 60%
of the stacks have XCMD or XFCN extensions in them. Most are pretty trivial,
like doing an SFGetFile. Some, like ResCopy, give HyperCard the power to do
most of the practical functionality of something like ResEdit. And I dare
Webber to come up with a practical applciation of ResEdit on a Unix box....

Again, off to a Unix context. Since Unix is such a nice system, there's no
reason to give it extensibility. so simply go and boot your Unix kernel, and
toss out /bin, /usr/bin/ and /usr/ucb. you don't need it -- if it isn't in
the kernel, it is a Bad Thing.

>On my system, awk is interactive and event-driven!

that's nice. What's this have to do with the discussion? Why don'y you go
program Awk and leave the rest of us alone?

>And, of course, there
>are many other tools if I don't feel like using awk.

Oh, he's really in seventh heaven, now!

>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's not obscure. There are more hypercard systems out there than Unix
boxes. The fact that Unix can't read that stuff isn't Unixes fault, Webber.
If you want it, go write it! It's been done for binhex, for xbin, for
packit, and now for stuffit. 

if you want it, go get it. Nobody is stopping you. but don't make us do your
work for you.

Webber, you again show your ignorance, your selfishness, and your
unwillingness to worry about anything except your own interests. Please do
me, and the net, a favor, and go be obnoxious somewhere else.

[It's a beautiful day in the neighborhood, a beautiful day in the
 neighborhood....]