All this talk about DataBases

[Chipp Walters]

Probably Richard, Jacque or Ken will jump in here and correct me if
I'm wrong. But, as I recall, the primary reason for writing MetaCard
as a total RAM based product was it made it lightning fast. And to
this day, it is still a very fast programming environment. In many
ways, significantly faster than HyperCard.

Remember, the first platforms MetaCard ran on were UNIX based, which
had virtual memory, so there wasn't a big problem regarding having too
little memory. Also, having  RAM based stacks virtually eliminated the
dreaded stack corruption so prevalent in HC and SC. How many times did
any of us lose data to that particular problem!

While Bill Atkinson certainly was a very talented programmer, and
HyperCard at that time probably demanded a disk-based and Assembly
programmed effort, it was probably not the best choice for programming
languages concerning serviceability. SuperCard, which came later, was
based on a bit easier to maintain language, and while not quite as
fast as HC, was very respectable in terms of performance.

I have as much respect...if not more, for Scott Raney's efforts taking
the best parts of HC, speeding them up significantly and architecting
a solution for multiple platforms. You only need be around during the
MC days to recall what a perfectionist and stickler for details (esp
bugs) he was. His journey and product has lasted much longer than
HC's, partly because of architecture, partly because of business
savvy, and mostly because it solved problems in ways no other software
did.

Also, let's not forget, before the Mac there was Xerox PARC, and their
own 'lamer' version of MacPaint. Before HyperTalk, there was
SmallTalk. I only mention this because in some way or another, all
software is derivative. Don't get me wrong. Andy and Bill were two of
the brightest lights ever to program.

On 5/29/07, Scott Kane <scott at cdroo.com> wrote:

> I'd be curious to know why RR decided to
> change the behaviour of how stacks are read (from file as opposed to loaded
> fully into RAM).  I suspect it would be possible to work around this, I
> believe Rob Cozens does something of the sought with Serendipity, but the
> question is whether it's really worth while given it's all there already
> with a "real" database.