How do you handle the poor performance of LC 7?

Trevor DeVore lists at mangomultimedia.com
Fri May 29 17:20:14 EDT 2015


On Fri, May 29, 2015 at 3:12 PM, Andrew Kluthe <andrew at ctech.me> wrote:

> ...
>
> It's not really an excuse to sit back and wait for someone else to find out
> the bugs as it is the hard reality of some people's situations.
>
> 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. Particularly, if we came
> to runrev/livecode to save us on development/prototyping time. Our
> community used to be so sure of the praises of livecode. It really was and
> will again sometime be a fantastic product. But I'm sorry to say v7 is not
> a production quality toolset for those without tons of extra time on their
> hands.
>

Hi Andrew,

I've been reading the responses to this thread and wanted to add some
additional thoughts. I understand where you are coming from and I don't
mean to argue against what you are saying. Each developer has different
needs and has different resources to allocate. Rather, I just want to add a
different perspective as the perspective most often shared on the mailing
list is from those experiencing problems with LC 7. I would like others
reading to know that there are people being productive with 7/8 right now.
It seems that the big issue that some have run into has to do with
processing large amounts of data. I don't do that within LiveCode itself. I
do a lot of work with arrays, however, and as Mark Waddingham has pointed
out, working with arrays is much more efficient in LC 7. I'm really
enjoying that. Now, I do see a slow-down in the IDE, particularly the
script editor, which I would like to see addressed, but that doesn't affect
my product.

I very much view my relationship with RunRev as a partnership rather than a
me vs. them. I've chosen LiveCode as my desktop development tool and I
believe in the vision that Kevin, Mark, and the team have for the product.
I've heard them discuss that vision over the 12 years that I've been using
LC. I see the changes being made in LC 7/8 as major steps in realizing that
vision. I love that LC is robust enough a tool for me to create my
products, while at the same time being easy enough to learn that I can
teach my young kids math and programming lessons using it. Because I
believe in that vision I don't mind allocating time troubleshooting bugs so
that the product can move forward. Most of the time those bugs are ones I
find while working on my product and they affect me directly. But not
always. Either way, I want the product to be the best it can be. I spend
more time tracking down my own bugs so every once in a  while it is nice to
track down a bug that somebody else has to fix :-)

Now, if LiveCode was sitting back on a buggy product and not trying to
improve it then I would have issues. As I've stated before, though, I watch
the work the team is doing via github. I also keep an eye on the bug
database. It gives me insight as to where LiveCode is headed and what is
being done to improve the stability of the product. What I see is a
commitment to making a great product. I see test frameworks being developed
(thanks Peter!), bugs being fixed, and time being spent with valgrind on
Linux to make sure there are no memory leaks. I also see these improvements
getting rolled into the steady builds being released to developers so that
we can get work done.

As I've reflected on the architectural changes made in LC 7, I see a
project which could very well cause a company to fail. It was a huge
project with few immediate or obvious advantages to developers. (Well, the
unicode improvements are quite significant to some. I still stop and smile
every time I write code in LC 7/8 that would have required workarounds to
support unicode in the past.) Like all major projects, it took longer than
expected. My bet is that many companies would not have been able to make
that transition. Given the nature of the transition to LC 7 I feel a little
extra sympathy for the engineers when I come across issues.

Currently I'm working on a major product upgrade that I started in LC 7 and
then moved to LC 8. I feel that it is far and away the best product I have
created in LiveCode to date. It looks fantastic! Widgets have made my
design work much easier and allowed me to create controls I couldn't
before. And it has full unicode support. I realize that I am more
adventurous than some but I've been releasing products with development
versions of LC for years. If I test my product and I don't run into any
issues then why not!

So to anyone thinking that they should steer clear of LC 7 because of what
you have read on the list, you should see how your project performs in LC
7. You may not see any performance issues at all. If you are using anything
less than 6.7 your apps look bad on high-resolution displays (Mac and
Windows). If you are using 6.7 your apps can still fail with unicode
issues. If you do get your app up and running in LC 7 (which may not
require any extra effort at all) then you are ready to go once you want to
dive into 8. And I think 8 is just awesome, even in its infant state.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.com    -    www.clarify-it.com



More information about the use-livecode mailing list