LC MISTAKES

[stephen barncard]

1. One have to remember that the Metacard engine roots go way back (1992)
before Revolution and Runrev.
Whatever Dr. Raney did a long time ago he did for a good reason and set the
stage for where we are at now and the absence  of a background layer has
been part of the design. I think he saw the limitations of the card model
and was trying another approach. Most of the import problems are for those
still clinging to the hypercard metaphor, where the cards are the database.
We are a long way beyond that now.

2. No software is 'bug free'. That's a myth.

3. There *were* some "deep pockets" that invested privately in Runrev a
couple of years ago, just before Mobile.

On Fri, Feb 1, 2013 at 3:42 PM, Joe Lewis Wilkins <pepetoo at cox.net> wrote:

> I'd like to take a completely tangential approach to this whole dilemma.
>
>
>

> 2.  Though I certainly appreciated the multi-platform aspects and a few
> other "tweaks"; I was flabbergasted to discover that RunRev had mangled the
> H/C framework by eliminating the Background layer in stacks, providing a
> very clumsy alternative method, so that the millions who could be adopting
> it from H/C would have to re-implement most of their legacy stacks. It just
> wasn't the same Object Hierarchy  any more. I tried to be



>
> So.... what should have been done? I realize that one of the Steves would
> be a hard sell; but, in some manner, Apple needed to get behind Revolution.
> We needed some really deep pockets, such as Woz to endorse Revolution so
> that the price for Revolution would be like H/C - you bought it once. Then
> it should have been developed to perfection as Revolution, probably up to
> the Intel Mac level and "bug-free". Once Macs switched to
>
> I realize that, in hind-sight it is fairly easy to see where things
> "might" be going; something that most of us would not have been able to
> anticipate in the moment, but the future of LC should have been better
> scripted so that RunRev was ALWAYS producing identifiable products that
> were capable of performing predictable applications; so the users ended
> with a list of products instead of an endless string of unreliable prodcts
> with a single name. Yes, there would be nominal charges for each new level,
> but the user would know that without the new "product", he/she could stop
> at any point. I know I'm glossing over many of the obstacles that might
> have been encountered, but I'm sure you all get my point.
>
> I feel confident that that a well structured plan similar to this would
> have brought a great many into the fold. I want my background layer back.
> Not going to happen, I know. (sigh)
>
> Joe Wilkins
>
>

Stephen Barncard
San Francisco Ca. USA

more about sqb  <http://www.google.com/profiles/sbarncar>