How do you handle the poor performance of LC 7?

[Richard Gaskin]

Andrew Kluthe wrote:

 > I totally understand what you're talking about there, but between
 > a full time gig, very young children, and freelance work at night.
 > I just don't know where I'd find the time to be effective at giving
 > them the level of detail that they need.

I hear you.  The only reason I'm in a position to volunteer as much time 
as I do is because I have a responsibility to my company and those of my 
clients, which are dependent on LC as the foundation of their product lines.

But LC is useful for a great many different workflows, and not all of 
them are as invested in it as the ones I help steward, so it's nice when 
folks have the time to submit reports but fully understandable if they 
don't.


 > In short, the request for us to invest this much time in helping them
 > figure it out is almost as stressful as the actual problems.
 >
 > The Us (community) vs Them (RunRev) that persists is the result that
 > most of the people started using this software when it was still
 > proprietary. It's a big step for many of us to transition to.

I've seen this dynamic before, and I believe it has less to do with dual 
licensing than the nature of development tools themselves.

I served on the advisory boards for Oracle Media Objects, Allegiant 
SuperCard, and Gain Momentum, and with each the relationship between the 
vendor and the community was in various ways challenging on both sides.

We had many long meetings between the Gain team, a team from Irix, and 
my client, just to try to get robust video playback, and ultimately 
someone one my client's team had to write custom C code to pull it off.

A number of critical features SuperCard developers relied on weren't in 
the engine at all but provided through externals, a good many of which 
were written by a team member in his spare time.  This meant funky 
syntax and design compromises, but they got us through the day well 
enough to move on to other challenges.

With quality, all of them faced a daunting task that's quite literally 
orders of magnitude beyond the scope of testing requirements for 
anything we build with these tools:

In the apps we make with xTalks, we use a subset of the language in very 
specific ways that constrain the range of possibilities the users will 
encounter.

But in the xTalk engines themselves, rather than providing "features" in 
the consumer software sense, they deliver thousands of tokens that can 
be combined and recombined in a combinatorial explosion of possibilities.

Of all the xTalks, the only one that came close to the scope of 
automated testing the LC team uses was HyperCard, but theirs was much 
more limited (and of course stopped being enhanced when the toolkit died 
20 years ago).

But since the range of possible combinations is large enough to be 
reasonably considered close to infinite, the scope of any automated 
testing can only accommodate a slender minority of all possible 
combinations.

They add to it as bugs are encountered, but given the nature of the task 
it can never be a replacement for live testing in the wild.  No 
automated test suite can be, for any product, which is why all software, 
from simple consumer apps to operating systems, rely on outside Beta 
testers as a critical component of quality assurance.

And despite everyone's best efforts, all software always has bugs, 
according to McConnel's research at the rate of about 15 to 20 per KLOC.


 > I'm sorry to say v7 is not a production quality toolset for those
 > without tons of extra time on their hands.
 > As a result, I have done no new development that wasn't a one off
 > utility for something simple in livecode since it went open source.
 > I'm too afraid to lose my lunch (or for users to lose theirs) to
 > these issues.

Which issues in the RQCC are yours?  I'd be happy to take some time to 
review them to see if they can be bumped up in the queue.


 > When one of my livecode apps needs an overhaul, I've been selecting
 > other tools/technologies to rewrite it in because of how long all
 > of this has been building up to and in the works.

I had considered a similar move myself for many years before LC went 
open source, since no developer tool has a chance of being taken 
seriously in the 21st century without at least an open source option.

But I've been unable to find any for which the cost of a complete 
rewrite is lower than the much cost of seeing a couple bugs fixed.

What language are you migrating your code to?


 > It seems like lately there has been this big move to say "Well,
 > there isn't actually a problem. People just aren't pitching in
 > to help us like they should."

I've heard sentiments like that from the community but not from anyone 
at RunRev, which is among the reasons I try to skim past vague 
complaints to focus on specific actionable issues, trying to sort 
through the noise to find the signal.

I'll be the first to say LiveCode is a FUBAR project, every bit as much 
as every xTalk before it, Ubuntu and most other operating systems, 
nearly every commercial app I've used, and the series of recent 
oops-we-missed-it-but-we'll-get-it-this-next-time releases from Apple, 
the most powerful tech multinational on earth, with the OS they depend 
on the most to power their wealth.

Software is hard.  And the more complex the system, the harder it is.

I just spend time lending a hand where it benefits my business to do so.

When I find the perfect dev tool that's every bit as productive as 
LiveCode but also entirely bug-free, I'll gladly ride my magic flying 
pony to pick up a copy.  But I fear that choice of vehicle is as likely 
as the destination. :)

So for now I just file a bug report and cut some code as needed to get 
through the day in a world defined by limitations.

Maybe I think to small, but I'm not alone.  I know some have encountered 
true show-stoppers in LiveCode for which no workaround can be found, but 
I also know a great many people shipping apps to thousands of happy 
users, so maybe my interest isn't entirely misplaced.

-- 
  Richard Gaskin
  LiveCode Community Manager