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