Refactoring is your friend / moving from 6.x to 9.x

[Curry Kenworthy]

Howdy LiveCoders,

I'm very happy to see people succeeding, optimizing, and coming back and 
LiveCoding. That's heartwarming.

But I'm making one of my rare appearances here, chiming in lest this 
thread end while consisting only of celebrating extra work that was put 
in to overcome slowdowns. To me putting in double work (or 1.x work) to 
achieve the result is not ideal.

Therefore, while I'm very happy people are back on track and "OK" - 
while I share in their relief and renewed optimism - I don't think it 
rises to the level of celebration. Quite the reverse. That would be 
celebrating a model where requiring more work to produce fewer results 
(or repeated work to achieve the same result) is considered a good 
thing. I consider that a bad thing.

Objective, repeatable testing has showed that LC 9 is considerably 
slower than LC 6 in a number of areas. In 2 years, LC has become twice 
as slow at some basic tasks. This pretty much negates the benefits of 
Moore's Law (and similar advances driving current and future hardware) 
and deprives coders and users of what would otherwise be a trend toward 
(offset a bit by OS flashiness) general 1.x improvement in performance 
over time. And that's passive gain; any work on code improvements would 
yield a multiple of performance.

Likewise, in 2 years LC has required one heck of a lot of refactoring. 
That may be fine and dandy for people who write loose and sloppy code 
the first time and love rewriting everything, but it's not quite so cool 
for responsible, experienced coders who do it right the first time, and 
build reliable and optimized code to last as a smart value for their 
clients and customers. If you love retyping, redoing, and refactoring 
every 2 years, along with multiplied costs, then I totally understand 
the celebration. Personally I don't love that model. My ideal is just 
the opposite - smart code that is built to last and already optimized 
and reasonably well written from the start.

Imagine all the hours, dollars, pounds, and euros spent on refactoring 
for 7/8/9 - multiplied by all the projects and clients. It's staggering. 
I'm confident that a good portion of that was avoidable. And STILL the 9 
engine is slow and has more bugs and arbitrary problematic changes than 
it should.

For my own addons, with VERY few exceptions, it has been due to LC's own 
bugs and arbitrary changes when they have broken or had problems. LC 
breaks it, I have to fix it. That's OK now and then, but it's not OK 
when LC gets sloppy, because when it's one person against a team, it 
becomes faster for a team to make a mess and break things than an 
individual to follow behind for clean up and repair. And one of those 
very few exceptions was a slowdown that another person added to my code 
when I permitted them to tweak the project, something I rarely do; I 
write very few bugs myself and that's how I like it. Don't you?

Sometimes I'm slower than ideal in following and repairing the breaks 
with my own updates, but it's a team vs one situation, updates go 
through a process, and the "one" is not the one doing the breaking. (Hi 
Klaus, old buddy old pal.) More updates are close, BTW - I have a little 
less extra steam for updates after my regular client work during winter, 
but it'll pick up again in the spring.

How much time and money have you put into your own 7-9 refactoring and 
debugging? Minus your bad code, of course. (If you're thinking "it all 
needed refactoring anyway" that's not proving your point, it's proving 
you were very naughty when coding.) :) For any code riding on top of 
another layer, as ours does, it makes sense to minimize engine and 
syntax breaks as much as reasonably possible. Otherwise some of the 
advantages of the layered environment are lost. There will be some 
breaks over time with generational improvements, but we're way over the 
ideal. And a steady loss of performance over time is just not a good 
thing in any possible universe. (Well, maybe a universe with inverse 
physics.)

Can we survive with this model? Heck yeah. Here we are, at least a good 
number of us. Was it ideal? Not in your wildest dreams. Here I must note 
that we have a lot of bad examples from the big industry players. They 
are taking planned obsolescence to extremes to make big bucks, in 
software as well as hardware. They don't mind if you have to pay N times 
(or work a reasonable amount of hours multipled by N extra times) to 
achieve the same results. They love your money more than they love YOU 
the person. I'm the opposite. I care about YOU - all of you, LC Ltd and 
the entire community.

So when people are frustrated and depressed and give up and then come 
back and try again and put in some renewed time and energy, I get it. 
I'm happy too. But I'm locally happy, for them as an individual, not 
globally happy for us as a community. Because this is inefficient. I'm 
not a very emotional person. I don't get depressed and give up and then 
come back. Very steady, always here, always proceeding with LC client 
projects (first) and addons (second). Not swayed by the ebb and flow.

But I do hate to see lost performance, and wasted energy is my nemesis; 
I hate it and make no apologies for doing so. I don't love to put in 
renewed time and energy to re-accomplish the same results; I didn't go 
away emotional and mad, so there's no "make up love and kisses" 
emotional joy in the extra work for me. It's just extra work to redo or 
fix X for LC's wild changes instead of pursuing new project Y. With 
extremely few exceptions, what I code is build well the first time, 
fairly well optimized and build to last without further expense to 
yourself EXCEPT when wantonly broken by others! Likewise when I'm the 
middle layer, I try not to break your code quickly or unnecessarily. I'm 
proud to embrace that model and wish others would do so.

What would be the results of a different model where the need to 
constantly redo is avoided? Less time wasted redoing the same things 
means more time to pursue OTHER things - less repetition, more 
achievements. Fewer of the same products, more different advances and 
variety of products to help the community. Less cost per client, more 
happy clients. Less time refactoring and (only if you write it well the 
first time) more time for new features and new projects. More carefully 
written code means fewer unnecessary bugs to start with, less noise and 
more signal for LC and our own projects. That's true for us, yes, but 
ALSO for LC itself. Any deficiency in LC (the underlying layer) is 
multiplied across hundreds or thousands of projects. Lots of time and 
money involved. Besides saving us a ton of time and money, imagine what 
LC itself could achieve.

And yes, absolutely yes - code can be written better without added time 
and cost, just as you could hire two people to work N hours on a home 
repair and one result could be excellent and sturdy, while the other is 
shoddy and crumbles at the first touch. For the same price, two 
completely different qualities and approaches of the work. To get back 
to the performance topic, if the engine were kept in shape, optimizing 
your code would be multiplied by the optimized engine, or AT LEAST we 
wouldn't have to fight to overcome slowdowns every N years.

Hmmm, it's one of those really tough choices...more results for less 
work, or more work and good old repetition for fewer results? Which 
model would I prefer? Wow, decisions decisions. That's may take some 
time to decide, so I'll go back to lurk/work mode, while I ponder that 
question at length.

I know people can rationalize their joyful extra work and expense until 
their dying breath, or point out examples of other IDEs that do it too. 
(Two wrong are always right, right? And their are no shortage of big bad 
examples these days.) Ha ha, but good luck justifying your extra work 
redoing the same task instead of using that time to accomplish something 
else you've always wanted to do! Convince yourself of that. Of course a 
few people may have buckets of time and energy on their hands and that 
would make it hard for them to see the difference. Then again, what goes 
around comes around; those who don't value energy and time are very 
unlikely to be good optimizers or excellent coders. I value both very 
highly, and it's no coincidence that I'm not a sloppy coder. Love good 
code, and fast reliable code to boot. In the engine as well as at the 
scripting (or "building") layer. Good code everywhere. Happy New Year to 
LC Ltd and every LC user! ;)

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/