sysop@stech.UUCP (Jan Harrington) (02/21/88)
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. Since yours truly has volunteered to moderate the new group (should you all choose to approve it), I'm also going to be conducting the vote. Therefore, please MAIL votes to me; voting stays open for 30 days. Any comments you have to make about the group would also be welcome. I'll post summaries of how things are going to the net periodically. C'mon all you stack fanatics, vote your hearts out! Jan Harrington, sysop Scholastech Telecommunications ihnp4!husc6!amcad!stech!sysop or allegra!stech!sysop ******************************************************************************** Miscellaneous profundity: "No matter where you go, there you are." Buckaroo Banzai ********************************************************************************
webber@athos.rutgers.edu (Bob Webber) (02/23/88)
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)
lim@cit-vax.Caltech.Edu (Kian-Tat Lim) (02/23/88)
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). 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. >... 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). I'm sure that HyperCard stacks will be of interest to non-Mac-owners; Apple's intention is surely to sell more Mac hardware once people see what can be done with it. Note that your statement doesn't necessarily imply that non-Mac-owners will be able to use HyperCard stacks on their machine or that 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). Does this mean that non-Sun-users should/do have Suntool emulators on their machine? >[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.] On the positive side, it says that the HyperCard designers were humble enough to realize that they couldn't think of all the possible applications it could be used in, so they provided a relatively easy-to-use method of extending the HyperTalk language that is transparent to the end-user. On the negative side, it says that they left out a few features exemplified by the most-commonly-used additions (XCMDs and XFCNs). Note that the HyperCard User's Manual is actually quite small. I imagine you are referring to one of the various HyperTalk books; as far as I can see, the primary reason for their length is that not only are they describing a complete new language, but also they must teach message-based programming to a generally sequential-thinking, procedure-based world of programmers. >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? -- Kian-Tat Lim (ktl@wagvax.caltech.edu, GEnie: K.LIM1)
chuq@plaid.Sun.COM (Chuq Von Rospach) (02/24/88)
>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. here we go again. >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. A standard justification. Not THE. >CLEARLY that is wrong here -- everyone has the same hypercard program! True, but... >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. >While we may be stuck with binary groups for some systems due to historical >reasons, there is no need to create yet another one. 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. >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. >[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.] 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. >By the way, those of you who read comp.risks are already aware of the >viruses that have already appeared in some hypercard stacks. 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. As usual, Webber is posturing and attempting to obfuscate the issue. All he really does, however, is show his ignorance of the software, of the purposes of the group. This is another case of Webber trying to wedge the network into his own warped view of reality, to the extent that he's willing to crippile its utility if it suits his purpose. Which simply means, as usual that his arguments are meaningless, and like Webber in general, should be ignored. Chuq Von Rospach chuq@sun.COM Delphi: CHUQ There is no reason for any individual to have a computer in their home. Ken Olson, President, Digital Equiptment, 1977
isle@eleazar.Dartmouth.EDU (Ken Hancock) (02/24/88)
In article <960@athos.rutgers.edu> webber@athos.rutgers.edu (Bob Webber) writes: >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. I'm sorry, but I really must disagree. The fact is that many mac owners DO NOT use HyperCard. I for one use, it but I'm not going to take the time to download every stack in sight. The recent Esperanto stack that came though is a good example. 15 parts! Considering that backlog that comp.binaries.mac is experiencing, 15 parts is a HUGE ammount of time/space spent on a single program. Had that been posted to a comp.binaries.mac.hypercard, fine. The fact is, that stacks are large. They take a lot of time. For those people on the net who do not use hypercard, it's silly to make them have to wait an extra month to get some program because huge stacks are hogging time/space. Ken -- Ken Hancock | UUCP: isle@eleazar.dartmouth.edu Personal Computing Ctr. Consultant | BITNET: isle@eleazar.dartmouth.edu __________________________________/ \____________________________________ DISCLAIMER: If people weren't so sue-happy, I wouldn't need one!
webber@topaz.rutgers.edu (Webber) (02/25/88)
[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)
webber@topaz.rutgers.edu (Webber) (02/25/88)
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)
chuq@plaid.Sun.COM (Chuq Von Rospach) (02/26/88)
[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....]
steele@unc.cs.unc.edu (Oliver Steele) (02/26/88)
In the left corner we have: >webber@topaz.rutgers.edu (Webber) In the right, stands: ]chuq@plaid.Sun.COM (Chuq Von Rospach) >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 [...] ]can't be translated to ascii readable anything, and without them, the ]scripts Webber is doting on are useless. >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. Mr. Webber, please post a reasonable stack (such as astronomy, dinosaurs, diskbox, esperanto, macintalk, notepads, or periodic-table, all of which are archived at Sumex) in your proposed text-only format, or give us the specifications for programs to convert to/from your text-only format, or give us the specifications for your text-only format. This will end the discussion once and for all and will be a great boon for those of use working on other hypertext systems. If you are talking through your hat, I am sure that there are Macintosh owners in your vicinity who would be happy to let you examine one of the previously listed stacks long enough to come forth with a proposal for a language of sufficient clarity and expressive power to do what you intend. [To Mr. Von Rospach's claim that the conversion from HyperTalk to a more common language is non-trivial, as HyperTalk and C differ in a few control structures:] >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. I fail to see what object-oriented programming has to do with appliances (or why a hypertext system shouldn't run on one). Are Bell Labs and Microsoft similarly guilty of said heinous crime, in their advocacy of object- oriented languages and an event-loop to handle the user interface? >Any programmer could cons up the >scripts in HyperTalk that would create the same stacks as a non-programmer >hacks together. Perhaps you should direct your efforts in the direction of a HyperTalk-to- C converter. Such a creation would answer all your petitions. Please be sure to make it portable, and post it when you are done. >If hypercard is any >good, its stacks will be of interest to many people other than mac owners >[...] >(as long as the format is easily readable like the refer format is). Anyone with access to the net is free to download HyperCard files for use on the HyperCard emulators which have been promised for other machines. It would indeed be preferable that the stacks be in some more universal format: we await such a format. ]Accusing [HyperCard] 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! A valid point. I am sure that the universal ASCII HyperFormat on which we are fast converging will fix such language deficiencies... >[Viruses are n]ot so much a failing of hypercard stacks, so much as a >general problem with accepting binaries in any system. Are you proposing that we discontinue all binary groups? Else I see not why this point is relevant. >Your little tirade on obsfucation was amusing. I enjoyed it too. Good work, Chuq! >----- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber) ---------------------------------------------------------------------------- Oliver Steele ...!uunet!mcnc!unc!steele steele@cs.unc.edu "Never underestimate the power (a departure from of human stupidity." -- LL my usual signatures)
chuq@plaid.Sun.COM (Chuq Von Rospach) (02/27/88)
[In general, I refuse to have battles of wits with unarmed people. So I'm going to try to answer Webber's few points of unfact and then drop it before this gets out of 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. I suggest strongly that rather than evaluate HyperCard by its reference manual, you evaluate HyperCard by playing with HyperCard. The weakest point of Goodman's book is the graphics. He basically shines it all on. Not surprising, since Goodman is an author and primarily text oriented (as an aside, Goodman hired an artist to do the graphics and design for HIS StackWare products Focal Point and Business Class. And, I might point out, having written a review of Focal Point for Macintosh Horizon, the advantages of that package are the logical graphic interface, not any of the underlying whizzies. But I digress). To go back into Unix equivalents, what you're doing, Webber, is evaluating Unix based on Kernighan and Ritchie. The White Books is a great reference on C, but it's not what I'd call exciting reading, and it's definitely not a good way to evaluate the wonders of Unix. Your knowledge of the system is too limited to make a reasonable judgement. Go find a Mac at Rutgers. I know there are some there. find hypercard, and work with it. Especially grab Laura's story, the stack Bill Atkinson wrote for his daughter. then tell me Hypercard is textually oriented. It isn't. Another area you've ignored completely is sound. A major (and growing) proportion of HyperCard stuff is the 'snd ' routines. That's an area that is very Mac specific. How are you going to play this stuff with your awk script? >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. No it's not. See above. They may be the areas that are of interest to you, but it's not a good idea to generalize your personal interests into the interests of the population as a whole. Especially when you don't know what you're talking about. >The issues are really >simple. Very. Do what's good for the Macintosh people, or do what's good for Webber. >Usenet is based on Unix which is grounded in a philosophy of >open systems, machine independence, and knowledgeable users using >sophisticated tools. Usenet happens to be a transport device that Mac people use to transfer information and programs. If you look at the numbers, there are about as many people reading Usenet for the Mac as for Unix these days. So trying to say this is a Unix network doesn't work anymore. It's a network that happens to be hosted primarily on Unix boxes. >Binaries are closed, system dependent, and based >on hiding the workings from the user (for their own good, of course). This is a loaded comment. First, HyperCard stacks are open and completely accessible to the user. The only reason they qualify as a 'binary' is because they aren't limited to printable characters. HyperCard is really the next generation of source, because it includes not only the 'code' (scripts) but an entire environment that can be taken apart, played with, re-used and hacked on -- including pictures, sounds, graphics, movements, various objects like buttons and fields, and data. You're insistence on focusing on the scripts and data to the exclusion of the rest, especially the time spent on design and placement by the stack programmer (both of which would go bye-bye under your proposal of posting only component parts, and both of which are critical parts of the success of HC stacks) show you don't care about what's good for the users of this stuff, you only care what's good for you. And, personally, I'm here for the general good, not the good of a single selfish individual. >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. This is your bias. If you want to talk about only posting stuff that is of use to the widest populations (Hmm. Webber, are you a Marxist? What a concept....) then we should get rid of the Unix groups, and only allow softwaare and soruces on the net. There are LOTS more Mac's out there than Unix machines, and lots more Mac users. And Unix software is notoriously unportable between different flavors of Unix. Macintosh software, on the other hand, would serve a very large segment of the computer using population, and would work on all Macs. To carry this to a ridiculous extreme, there are zillions of IBM-PC's out there. Not to mention Apple ]['s. Maybe we should refuse to carry any software that doesn't run on MS-Dos. That's the way to his the really large segment of the population (although you'd have to start worrying about PC vs. XT, EGA vs. CGA, etc, etc, etc, I'm sure it could be worked out). This, of course, is insane. All Webber is really saying is "I can't use it, so you can't do it" -- I'm not particularly worried. It's been a long time since I've thought it was possible to please everyone all the time, so I don't bother any more. I just try to do the best I can. The best we can do here, of course, is to make hypercard stacks available to the many hypercard users, just like we've suggested. Nothing, of course, is stopping Webber from using the HC stuff. If he really wants it, he can borrow a Mac with HC and unpack the stacks himself. or write a Hypercard translator for his wonderful Unix machine. Or, gasp, simply use HyperCard on a Mac somewhere. Webber, if you want HyperCard stuff on your Unix box, I suggest you go and write something that'll read a HyperCard stack and pull it out for you. Don't force us to do your dirty work for you, especially when all it will really do is make the stacks useless to everyone else. Look around you. you may not have noticed it, but you're not the only person on this network. Quit acting like you are. Chuq Von Rospach chuq@sun.COM Delphi: CHUQ There is no reason for any individual to have a computer in their home. Ken Olson, President, Digital Equiptment, 1977
howard@cpocd2.UUCP (Howard A. Landman) (02/27/88)
In article <43182@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: >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. What's wrong with stacks that disassemble themselves? >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". No. >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 What's wrong with stacks that reassemble themselves? >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. Yes, that's the better way. >All so you can look at it and say 'that's nice.' No. >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. Get off the "madness and badness" kick, Chuq. Webber is not insane, he's just frustrated at watching megabytes of data flow by in a format that's utterly useless to him, when a little attention might have made it otherwise. Many stacks *DO* contain large amounts of data which could be transmitted differently. I recently decided to post a HyperCard stack of Go game references. The main people who would want this are all on rec.games.go. Should I clutter up comp.sys.mac.hypercard with this? Posting the stack would have been > 250 KB (not allowing for stuffit compression). Instead, I spent a few hours writing and testing a script to dump all the fields to a UNIX text file, posted THAT to rec.games.go with a pointer in the hypercard group, and began preparing to post the EMPTY stack (about 24 KB uncompressed) on comp.sys.mac.hypercard. This makes much more sense. It *WAS* more work for me, no question about it, but the number of people who can use the data is now at least 10 times greater. I saw that as valuable. (For those who are anxiously awaiting the stack itself, which is a nice simple example of how to dump/restore the bulk of a mostly-text stack to a file, you may have to wait for a while. It seems that the HyperTalk command: read from file f until newline simply DOESN'T WORK. It merrily scans right past a newline and stops 10 or so characters later in the middle of a word. Loads of fun. It may take me a while to work around this.) Note that, *IF* I ever get this to work, all the user need to do is get the stack and the text file onto his mac and push the "Text to stack" button. Not quite as bad as you make it out to be. The script even counts errors and reports them, so you know whether everything went O.K. or not. -- Howard A. Landman {oliveb,hplabs}!intelca!mipos3!cpocd2!howard howard%cpocd2.intel.com@RELAY.CS.NET
sbb@esquire.UUCP (Stephen B. Baumgarten) (02/27/88)
In article <43182@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: >[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] Nice rebuttal, Chuq. This guy really *is* a pinhead... -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." ...!cmcl2!esquire!sbb | - David Letterman
svpillay@phoenix.Princeton.EDU (Kanthan Pillay) (02/27/88)
In article <18326@topaz.rutgers.edu> webber@topaz.rutgers.edu (Webber) writes: (in response to Chuq's posting) > >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. Usenet based on Unix? How do you figure this? The majority of users who access Usenet here at Princeton use an IBM3081 mainframe. A unique case, you say? Nope. The driver that we use here for Usenet is also used at many other IBM sites around this country. Try telling all of those users that they should be using a Unix machine and you'ld be asking for trouble. Try telling them that Usenet is _reserved_ for Unix machines, and then you would _really_ be in hot water. I use a Unix machine, yes, but I am not so self-centred to insist that all people who access Usenet's information be "knowledgeable users". Talk about arrogance! >Binaries are closed, system dependent, and based >on hiding the workings from the user (for their own good, of course). Own good has nothing to do with it. I can appreciate Bill Atkinson sitting tight with the source code for HyperCard. It's a bit difficult translating this to Unix terms. Simply, you need to be a Mac user to understand. >While some people are willing to tolerate binary groups because of the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Tolerance has nothing to do with it. If you don't want to receive the binary groups at your site, you're free to do that... >general ``potential'' of micros, this is mostly because the typical >micro binary would be useless to anyone else as it is just an attempt ^^^^^^^^^^^^^^^^^ The C source code posted to comp.sources.unix is useless to the majority of users here at Princeton. I don't hear them complaining. >to implement standard functionalities in a particularly restrictive >environment. Restrictive by your standards. I can pick up my Mac and tote it around the world, as can all those Mac users out there. You want to tote around your workstation? And my Mac gives me complete access to the Unix 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) What does that have to do with Mac users? Surely it should be the responsibility of the (I assume) Unix users ... sorry, knowledgeable users, to take the trouble of downloading such files to his/her Mac, converting them to Unix-usable forms, and then distribute these in the appropriate places? Needlessly obscure format? Sure, from a Unix perspective it would be obscure, but I don't hear Mac users lining up to shoot Bill Atkinson because he hasn't released the source code for Hypercard. You're out of line by attempting to restrict the way others should use the net, Webber. I'll take the binaries as is, thank you very much. You find a way to translate those stacks on your own time. Kanthan. -- Do I really need a signature?
webber@athos.rutgers.edu (Bob Webber) (02/29/88)
In article <1866@phoenix.Princeton.EDU>, svpillay@phoenix.Princeton.EDU (Kanthan Pillay) writes: > ... > Usenet based on Unix? How do you figure this? The majority of users who > access Usenet here at Princeton use an IBM3081 mainframe. A unique case, > you say? Nope. The driver that we use here for Usenet is also used at > many other IBM sites around this country. Try telling all of those users > that they should be using a Unix machine and you'ld be asking for > trouble. Try telling them that Usenet is _reserved_ for Unix machines, > and then you would _really_ be in hot water. They should be using Unix machines (really). But no, Usenet isn't RESERVED for UNIX machines. But it was started on them and ran for the most part exclusively on them for some time now. Non-unix machines can hardly be viewed as other than guests on the net. > Own good has nothing to do with it. I can appreciate Bill Atkinson > sitting tight with the source code for HyperCard. It's a bit difficult > translating this to Unix terms. Simply, you need to be a Mac user to > understand. I am not asking for the source to HyperCard, just disclosure of stack formats. > The C source code posted to comp.sources.unix is useless to the majority > of users here at Princeton. I don't hear them complaining. Why, can't they read a C manual? One of the first C compilers was for IBM machines - did they later give up on them as a lost cause? Translating C to Cobol or PL/1 or Fortran is no problem for anyone who is so inclined. All the necessary information to do it is very easy to come by. > >to implement standard functionalities in a particularly restrictive > >environment. > Restrictive by your standards. I can pick up my Mac and tote it around > the world, as can all those Mac users out there. You want to tote around > your workstation? And my Mac gives me complete access to the Unix > environment. I can tote around my Psion Organizer too, so what. The environment on a Mac is more restrictive than it was on a PDP-11/45 running unix (it has little to do with hardware and alot to do with who the people who packaged it decided they wanted to target). > What does that have to do with Mac users? Surely it should be the > responsibility of the (I assume) Unix users ... sorry, knowledgeable > users, to take the trouble of downloading such files to his/her Mac, Hmmm. How do you feel about having Macs used as machines to port around Sun4 binaries? Of course, any Mac user who wanted could just download them to their Sun4 (prices getting closer and closer...). ----- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)
webber@athos.rutgers.edu (Bob Webber) (02/29/88)
In article <43313@sun.uucp>, chuq@plaid.Sun.COM (Chuq Von Rospach) writes: > [In general, I refuse to have battles of wits with unarmed people. So I'm You are much too cautious. I would give you 50-50 odds in a battle of wits with an unarmed person. Of course, against an armed person, you haven't a prayer. ... > I suggest strongly that rather than evaluate HyperCard by its reference > manual, you evaluate HyperCard by playing with HyperCard. I already spent $20+ just to find out what Hypercard is all about. How much to buy a copy of HyperCard and a Mac with enough memory and disk space to make it usable? Perhaps we should start The Webber Education Fund (a great mind is a horrible thing to waste). [These days I target my spare hardware cash for homebrew projects -- commercial computer makers add too much overhead for my tastes given the current chip market and availability of system source.] > The weakest point of Goodman's book is the graphics. He basically shines it > all on. Not surprising, since Goodman is an author and primarily text Ah. So there are people other than Webber who have this wierd view that graphics and sound aren't the key parts of Hypercard? [Believe it or not I was not impressed by your example of scanning book covers and recording author's pets for each book in a bibliographic index -- I guess there are some things you just won't understand until you have had to use a Mac for a few years.] > good way to evaluate the wonders of Unix. Your knowledge of the system is > too limited to make a reasonable judgement. Regardless of my judgement of the utility of HyperCard as designed, there still remains the issue of the vote at hand which is: Should net resources be targetted to encourage people to distribute information (be it textual, graphic, or sonic) in formats that are not freely available? I SAY NO. > Go find a Mac at Rutgers. I know there are some there. find hypercard, and > work with it. Especially grab Laura's story, the stack Bill Atkinson wrote > for his daughter. then tell me Hypercard is textually oriented. Macs we have plenty (used to be one in my office -- I saved the box, scrap cardboard has its uses). I checked in our MicroLab and no one had heard of a HyperCard manual -- (previous experience with other Mac software has taught me not to go near anything that doesn't have a manual). > is very Mac specific. How are you going to play this stuff with your awk > script? If it is barking dogs, I will just manage to live without it. If it is something worth listening to, I know someone who has a Kurtzweil hanging off a Mac who might be prevailed upon (but so far I have heard of nothing that leads me to believe this will be necessary). > Very. Do what's good for the Macintosh people, or do what's good for Webber. Do what's short-term good for a portion of the Mac people on the net or do what is clearly long-term and short-term good for all the non-Mac people and perhaps long-term good for the Mac people? > Usenet happens to be a transport device that Mac people use to transfer > information and programs. If you look at the numbers, there are about as > many people reading Usenet for the Mac as for Unix these days. You forget to factor in the relative states of documentation of both systems. > This is a loaded comment. First, HyperCard stacks are open and completely > accessible to the user. The only reason they qualify as a 'binary' is > because they aren't limited to printable characters. They qualify as binary ONLY because their format is not publically available and hence unusable to any one not owning a copy of a system that they were generated. All binary postings I have seen have consisted of printable characters. Most binary postings have this same flaw (and I have already earlier protested all binary groups), but HyperCard binaries differ from other binaries in that they have the potential to contain information useful to non-Hypercard users. As stated before, most people tolerate the other binaries because they really have no interest in the information that is hidden within them. > you. And, personally, I'm here for the general good, not the good of a > single selfish individual. Ah, where have I heard that before? It is lines like this that give me hope that people will see through your mascarade behind the cloak of presumed expertise. > This is your bias. If you want to talk about only posting stuff that is of > use to the widest populations (Hmm. Webber, are you a Marxist? What a > concept....) then we should get rid of the Unix groups, and only allow > softwaare and soruces on the net. All the talk and soc and misc groups distribute information in publically available formats. Of the sci groups, only in sci.crypt have I seen information in a non-publically available format (i.e., someone posted a couple of encryption puzzles). Except for the comp.binaries groups, everyone else distributes in publically readable formats. > This, of course, is insane. All Webber is really saying is "I can't use it, > so you can't do it" -- I'm not particularly worried. It's been a long time True. Fundamentally that is the objection to proprietary formats, they are useless to people who aren't paying tribute to their inventors. Think what things would be like if Usenet news and mail formats were proprietary. > Webber, if you want HyperCard stuff on your Unix box, I suggest you go and > write something that'll read a HyperCard stack and pull it out for you. > Don't force us to do your dirty work for you, especially when all it will > really do is make the stacks useless to everyone else. Well, at least we agree trying to make HyperCard binaries usable is dirty work. Give me the specs for the binary format and I will write utilities that extract useful data from them. However, I don't have time to develope a working knowledge of Mac internals to be able to reverse-engineer hypercard stacks just because the some irresponsible people want to use it as a format to pass around images of their pets (in full stereo sound). ------ BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)
jwhitnel@csi.UUCP (Jerry Whitnell) (03/01/88)
In article <18326@topaz.rutgers.edu> webber@topaz.rutgers.edu (Webber) writes: > >> >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). Fine, Bob. All you have to do is write a little utility that extracts the textual parts from a binary hypercard stack and puts them in whatever format you want. All the information you want (the text and the Hypertalk code) is stored in the stack, so it should be easy to get at. Then you can have what you want, we Mac user's can have what we want and everybodys happy. But please don't expect us to support you. We have are Macs and can use the information as it comes. If you want it in some other format, you translate it. >----- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber) Jerry Whitnell Been through Hell? Communication Solutions, Inc. What did you bring back for me? - A. Brilliant