Thousands of cards (Was RE: very strange rev behavior)

Richard Gaskin ambassador at fourthworld.com
Fri Mar 5 08:09:41 EST 2010


Jim Bufalini wrote:
> OK... time for a dumb question. What kind of application would have 5,000 or
> 10,000 cards? Is it because the application is using cards to hold records
> of data instead of using a database? Otherwise, I can't even imagine it.
> Also, wouldn't an application with a stack with this many cards be a huge
> memory hog?

The problem is that you've been making software too long. :)

If you've ever shipped a version 2.0 of something, you realize very 
clearly the traditional benefits of separating code, UI, and content, so 
you can enhance the UI without affecting the user's data.

But HC made it very convenient to store data on cards, and out of the 
box provided no way to work with any database at all (SQLite hadn't even 
been invented yet).

Bill Atkinson said more than once that "HyperCard is not a database", 
but the convenience of using it as one encouraged people to do so.

Memory wasn't an issue, because HC paged from disk.  Remember, it was 
designed to work in early Macs, back when 2 GB of RAM was an 
unimaginable dream.  Paging from disk meant only a limited number of 
cards were in memory at any given time (though the frequency of 5454 
errors -- file corruption -- told the other half of the story, the 
inherent complexity and potential brittleness of paged systems for 
anyone who didn't make a religion of compacting regularly to rebuild the 
file).

So flash forward:  20 years later, HC has been dead for more than a 
decade, Rev is growing, and there are a lot of legacy systems built in 
HC looking for a new home.

But as you know, Rev loads the entire stack file into memory at once, 
which gives it a certain robustness and contributes to its excellent 
performance, but means that storing 20,000 cards in a stack just isn't 
practical.

Dr. Raney was nothing if not pragmatic, so optimizing his structures to 
accommodate that many cards was not something he ever bothered to invest 
time in because it only encouraged people to things that would lead to 
other problems down the road (like making a v2.0 that enhances one's UI).

So this means that while Rev's support for the HC file format makes it a 
good choice for porting legacy HC stacks, in many cases those stacks 
need to be restructured to make good use of it.  This often means very 
fundamental changes, like moving the data out of the UI, which are 
unintuitive for someone coming from a system where that wasn't needed.

I believe there are so many benefits in separating code, UI, and content 
that it's well worth the effort, and the clients for whom I've ported 
large HC stacks have been pleased with the results Rev offers.

But I also recognize it's a bit of a head-scratcher when you do it for 
the first time.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv



More information about the use-livecode mailing list