LC MISTAKES

Joe Lewis Wilkins pepetoo at cox.net
Fri Feb 1 21:28:17 EST 2013


Steven,

No doubt you are probably right, but I'd have done it differently; which is why it didn't get done the way I think it should have been done. Hind-sight is always perfect. There were many stacks I created that raw neophyte, computer illiterate teen agers were able to use in a high-pressure situation with nary a need to slow down to make up for an occasional bug. They WERE "Bug-free" - on my end. HyperTalk was wonderful, but I can't speak for it; and Compile-It let me do some pretty powerful externals. Well over 100 in number. Not to say that there were no work-arounds with Compile-It. (sigh)

No question but what all things would be a lot different with the current hardware, but I'm giving up coding to write my bio and create some havoc! Thanks listers, it's been a great ride.

Joe Wilkins

On Feb 1, 2013, at 5:59 PM, stephen barncard wrote:

> 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>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list