How do you handle the poor performance of LC 7?

[Andrew Kluthe]

I'd still like to do other work in LC (less scale, less risk) but for
things like industrial control systems, warehouse management, etc. where
there are thousands or millions of dollars on the line, I guess it isn't
that 7.0 is really that bad as much as it was the wrong tool for us at the
wrong time. I had LC and walked around trying to build everything with it.
And I could build things really fast and it was good.

 Then I had to figure out how to structure larger applications considering
that livecode's stack format is a bit than most other tools. Andre did a
presentation at a runrev conference that inspired me to refactor some of
the big ones and make them much more manageable/testable almost like an MVC
kind of pattern.

I was hired to convert legacy visual foxpro programs into a more robust
system that could bring us into the present and was leaned on to sort of
build the programming teams and automate everything. Then we got a new set
of investors and could afford to write more of our industrial things
in-house and wanted to hire people who would be willing to work in LC. That
was hard to do. We wanted things like git repos once we got a bigger team
(before opensource when things like that were still hard for LC). I think
the decision boiled down to just wanting more mainstream processes for
development and being able to find programmers we didn't have to train from
scratch. So the decision was made to become a .Net shop and phase out the
livecode applications we had been using since then with .Net web apps and
desktop clients.

I guess you could say we just outgrew livecode's abilities at the time and
couldn't wait for the new ones to be available. It was more of a
convenience issue than than a showstopper for us. I keep waiting to go back
and show off some amazing new stuff the new livecode features introduce,
but so far I have been forced to keep waiting for that thing that can sell
us on doing some things in livecode still.

Yes, MS or Apple has waaay more resources than RunRev to do the things they
do, but damn if i wouldn't like it to be otherwise and still work everyday
in LC. Most of that reply to you, Richard, was just some back story on why
I feel the way I do. I reckon LC 7 is production ready depending on what
kind of (and what scale) production work you are talking about. The
attitude in our community is that livecode should be able to do anything
and everything. I'd agree with that. It's a great syntax. It's a great
concept. It works great for so many things. Maybe my things were just not
some of them. We had big ideas that started small, but now those big ideas
seem bigger than what we could do with it in a cost-effective manner.

On Fri, May 29, 2015 at 3:17 PM Richard Gaskin <ambassador at fourthworld.com>
wrote:

> 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
>
> _______________________________________________
> 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
>