Richard Gaskin wrote: > 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.
Alright, this answers my question and why I said, "I couldn't imagine it." Yes, going back more like 26 years ago, SQLite wasn't invented but I was using DB and Rev (only that Rev was called Revelation which was a just released development language/environment for the original IBM PC by a brand new company called Cosmos and based on PICK, which had been around since the '60s). When I first heard of "Revelation by Cosmos," I wasn't sure if it was a programming language or a cult. ;-) But, from almost the very beginning of my developing applications for others, "code" was script in libraries (very similar to our Rev's script including chunks, no variable typing, amazingly similar built-in commands and functions, English like, optional variable declarations, and it too was script level compilation, so you ran and programmed at the same time), which was separate from the UI, which was just that, and which in turn was separate from data, which was in a PICK database. There was some mixing of script and database in that a database could have a "field" which was actually script. By this I mean, you could have a "field" called "FirstName" which was a script that returned word 1 of an actual field called "Name" that contained a full name, or visa versa, a "field" called "FullName" that was a script that returned the concatenation of FirstName & space & MiddleName & space & LastName or that did a calculation, etc. There was some mixing of script and the UI, in that there were "hooks" (there was no OS messaging in that day) that were triggered say entering an entry field or exiting that allowed calling say an "IConv" or "OConv" (In Conversion, Out Conversion) which would be a function in one of your libraries that say checked user input or changed the UI based on user input or opening or closing a window, etc. And, in that day, you did have to drop down to C occasionally to modify the engine (which they allowed) or write the equivalent of what we call externals. It is why, for me, finding Revolution was like "returning home" after over a decade of having left Revelation and working with "traditional" languages (with hours of re-typing variables) and SQL. I "knew" the Rev language and the concepts of chunks and scripting before writing my first line of Rev code. But... the lack of database was a big drawback and the idea of using text files or cards (which I considered the UI) to hold data was arcane to me and "just wrong" and so, while I did use text files, I never could bring myself to use cards to hold data and I didn't use Rev for anything "serious" until there was DB. In short, I had forgotten all this, because we've had DB for awhile, and it's why I was wondering what the heck anyone could be doing with 5,000 or 10,000 cards. ;-) Thanks for the history lesson, Richard, and the "memories." ;-) Aloha from Hawaii, Jim Bufalini _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
