Trying a custom handler for several math fields

[Richard Gaskin]

Vaughn Clement wrote:

> I see your point about possible damage. But consider the current effort to
> autosize screens to manage the Android device apps. Would this cause the
> same problems as your describing for legacy apps?

I believe the way resolution independence is designed in v6.5dp forward 
should minimize hindrance with legacy code - from the Release Notes (p11):

    Since all of the updates are internal, the end LiveCode developer
    should see no major changes: Where possible, we've tried to match
    previous behaviors as closely as possible.

In general, the team does an unusually good job of preserving backward 
compatibility (ever talk with Python fans about moving from v2 to v3? 
<g>).

Where an enhancement is both unquestionably more valuable than previous 
workarounds and where it could not be implemented without some cost to 
backward compatibility, the team will draw attention to those in the 
Release Notes so developers can make any modifications needed for them.

In the 15 years I've been working with this engine, I can recall only 
maybe three cases where an enhancement lost backward compatibility.


> I am starting to see a trend in the conversation in the How To email
> that is out to defend LC to protect the standards of usage.

It may be more helpful to think of it as defending the scripters who 
rely on LC rather than LC itself.

This engine was first born in '92, and over the decades the community 
has built up enormous collections of scripts, many of them critical to 
the revenue of the businesses that rely on them.

Any change that risks altering the behavior of 20 years of community 
code is a decision that needs to be weighed with extreme caution.  In 
the best case it will cost us hundreds of dollars to update code; in the 
worst case it can be cost-prohibitive and destroy a business.

Thankfully, RunRev is as cautious about such proposed changes as those 
of us who rely on their engine, so a good balance favoring backward 
compatibility wherever practical seems to be pretty well maintained.


> I am not  saying this is good or bad, but I wonder if this will impede
> the future growth of what was once a very simple product named HypeCard?

HyperCard is actually a pretty good example here:  while LC maintains 
much of the same event-driven simplicity that made HC so enjoyable, it 
also supports at least three times as many messages for much more 
refined interaction control.

The same goes for properties, commands, and even the range of native 
objects and the mechanisms for extending the message path:  LC has 
retained most of what HC offered, but has gone much, much further to 
provide capabilities HC never dreamed of - and on six times as many 
platforms.

I was once hired by a company to enhance some of their internal HC-based 
tools to write a bunch of complicated scripts which ultimately did 
nothing more than provide workaround ways of getting things like groups 
and custom properties into HC.  I advised them at the outset, and 
several times throughout the project, that if they just ported to 
LiveCode they wouldn't need me at all.  But they insisted on sticking 
with HC, and insisted on paying me to write built-in LC features in 
cumbersome workarounds within HC.  And when HC eventually stopped 
running on Macs they had to port it later anyway.

HC was a great tool in its day, but today we're in a very different 
world.  The things that made HC simple to learn also made it very 
limited:  monochrome, single-stack standalones, dialogs and palettes and 
even color had to be driven from externals, no vector graphics, only one 
background group, and on and on - not to mention being able to deploy 
only for the second-least-popular OS on the planet after desktop Linux.

Today's developer needs associative arrays, Internet connectivity, 
database support, etc.  LC does have a higher learning curve than HC, 
but in a world where more people are typing JavaScript right now than 
the sum of all xTalkers ever, LC does a reasonably good job of balancing 
capabilities with learnability.

It can get much better - lots of room for improvement.  And with the new 
"open syntax" initiative (something only REBOL ever achieved among 
scripting languages, far beyond HC's wildest dreams) , we can expect a 
lot of powerful new capabilities in syntax that gets ever more simple as 
it goes.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys