On Fri, May 29, 2015 at 3:12 PM, Andrew Kluthe <and...@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 _______________________________________________ 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