Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!bc
From: bc@Apple.COM (bill coderre)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: HyperCard Vs System Versions Anyone?
Message-ID: <47019@apple.Apple.COM>
Date: 2 Dec 90 19:12:16 GMT
References: <1990Nov24.235328.10009@sics.se> <2801@polari.UUCP> <MbJip0G00UhW04UMJS@andrew.cmu.edu>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 74

Brian Patrick Arnold:
|No offense to the wonderful HyperCard team and users striving for a
|stronger, better, faster HyperCard, but experience tells me you
|shouldn't even be using HC if (script) performance is an issue.  The
|relative tradeoff of upgrading is nothing compared to your decision to
|use HC over something else.  "Hmm, abysmal performance or
|worse-than-abysmal performance, hmm...I'll pick abysmal performance..." 
|HyperCard is great for some tasks, but if you can use an analog watch to
|time the performance of a script, it's time to consider the alternatives.

Although Hypercard stacks do not run as fast as compiled programs,
there are many applications where this is not a problem.

For instance, any application which is, essentially, just a user
interface to a complex data structure, or a front end for an
application running on a mainframe, will prove eminently suitable to
Hypercard development for the following reasons:

	Hypercard is fast enough -- users rarely are made to wait
	(careful app designers will only make users wait when the
	users expect to wait -- for instance, when the user presses
	the "Save" button)

	There is the possibility that time-critical code segments can
	be commissioned as XCMDs, which will drastically increase
	performance and are much easier to write than C or Pascal
	Macintosh applications.

	It has a dramatically quicker turnaround than any other 
	programming language. A new programmer can begin work in 
	days, and an experienced programmer can bang out a FUNCTIONAL
	proto in mere hours. 

	It requires drastically less code to be written than other
	programming languages.

	It insulates the program from the Mac Toolbox.

	It provides for a very standard user interface, easily.

	It provides applications which run on most all Macs, first
	time.

	It has a better debugger than other programming languages.

	Thanks to gurus like Harry Chesley, complex interprocess
	communication (like TCP-IP or SQL) can be implemented as
	easily as any other function call.

When I was called onto a "demo tomorrow" contract, I used HyperTCP and
MitemVIEW to send SQL queries to a (huganic) database service. By the
end of the afternoon, I had all the queries in and was putting the
company logo onto cards, and polishing the interface. In contrast, the
X windows + Motif guys (four of the best in the area, I was told) were
rebuilding the Unix kernel again. Late that night, the other groups
were using MY stack to test their queries. When the queries changed, I
was back on line within MINUTES. 

Program speed? One second response overhead for any transaction, which
usually took between 5 and 15 seconds each. Assuming C runs at the
speed of light, I paid 16% extra (maximum) to write my code in
Hypercard.

There is more to programming than processor speeds and code
optimization. Although some hackers would never admit it, a simpler
program is always a better one. Hypercard programs are simpler to
maintain, upgrade, and debug than many others. Sure Hypercard is not
as fast as C, but if the program in question is not filled with
complex, iterative calculations, Hypercard will be nearly as fast as a
compiled application. And the program will be delivered much sooner,
and with much more user feedback, than a custom app.

bill coderre
former Hypercard consultant
not an apple spokesperson