Wake up Revolution

Bill Marriott wjm at wjm.org
Sun Nov 15 22:19:43 EST 2009


Colin wrote:
>> >If a thousand people experience great performance and one person 
>> >experiences very poor performance, would it not seem worthwhile to 
>> >consider the cause of the difference may lie with the system's 
>> >configuration?
>
> You can't use logic for this case, otherwise you would argue that if on a 
> particular machine you can open and run a stack without any issues in 2.9, 
> and if you open and run the stack in 4.0 you get two minute long lock up 
> of the machine every time you press a certain key, obviously 4.0 is the 
> only thing that was changed in the test, and so must be at fault.

Actually, one can and should use logic here. The former is an example of 
logic; the latter is, well, superstition. The difference is "sample size." 
If I buy two loaves of bread at the store, and one is stale but the other is 
fresh, I can make no logical inferences about the cause of the staleness 
even if superficial aspects like "expiration date" and "wrapper color" are 
the same and the only apparent difference is the brand. The fault could lie 
among a hundred different variables. You cannot compare two loaves and say 
with any confidence that "Brand X" is a better bakery than "Brand A." 
Neither loaf can be said to be representative of the larger population.

However if 999 loaves of Brand X turn up fresh and one loaf is stale, it's 
logically valid to infer there must be something about the unique 
handling/processing/delivery/storage of that particular loaf that has caused 
the problem. Perhaps the wrapper was torn while unpacking, or a 6-year-old 
kid with grubby hands opened it and stole a slice while it was on the store 
shelf, etc.

Mark wrote:
> Who says that thousand people experience great performance?! I, for
> one, don't.
>
> I am pretty sure that Inselfan did something that should just work in
> Revolution without problems and figuring out the source of the problem
> is a process that one should not have to go through with a development
> environment like Revolution in the first place!

Mark, I'm sure that if it took you minutes to hide/show the Tools Palette 
and anything more than milliseconds to navigate between cards, we would have 
heard from you about it before now. I would also say that investigating 
reasons for mysterious slowdowns in projects is an unavoidable task in any 
development environment, especially one like Rev which is designed for 
authoring/deployment on so many varied platforms. Having said that, a 
refresh of the IDE probably is needed -- for efficiency, to update the 
look-and-feel, and to exploit new features like behaviors --and is in the 
works.

In this particular instance there are so many variables and factors we do 
not know about the situation. Does this problem occur with all stacks or 
just the 16MB one? Is the Property Inspector open, and to what pane? Are 
there any third-party add-ons installed that have not been designed for the 
post-2.9 world?

It's also easier than ever to do testing, especially on Windows where you 
have Microsoft's Virtual PC 2007 and freely downloadable images of the 
Windows XP and Vista operating system. I'd really like to see what happens 
if Horst downloads one of those images, installs Rev 4.0 fresh, and tries 
his stack.

I'm not saying there definitely is NOT some obscure change made in Rev 4.0 
that causes this interaction. But I'm saying it hasn't cropped up before 
despite extensive usage by hundreds of other people. I'm confident that a 
configuration change will solve the problem, or failing that we will learn 
something about the particular usage scenario that needs to be addressed, 
either by the end user or RunRev. Without going through the troubleshooting 
process, we will never know. It certainly isn't fair to encounter something 
like this and throw one's hands up saying, "Ah, Rev 4.0 is obvious crap!"

Richmond wrote:

> There is a school of thought that RunRev have tried to expand the
> capabilities of Revolution rather too
> rapidly, without taking care of some 'nuts-and-bolts' glitches that have
> been around for some time.

Perhaps. But as someone who wrote just over three years ago that "Quality is 
Job #1," I have to disagree with this school. We've come a long, long way. 
RunRev spent more than a year and a half working on the 
free-for-almost-everyone Rev 2.9, which addressed hundreds of those issues, 
re-architected tons of internals, and brought the Linux edition up to speed 
with the other platforms. The result was a measurable, marked improvement in 
quality, and a more robust platform that has enabled much-needed 
"nuts-and-bolts" enhancements since then: the new tabbed script editor 
(3.0); the data grid and behaviors (3.5); and the Web plugin (4.0). All of 
which have been delivered on a predictable schedule with more far more 
external testing -- both in terms of number of users and length of 
testing -- than prior versions. At the same time, we have halved the retail 
price of the product and even introduced the free and highly capable 
revMedia edition while growing in profitability during a time of global 
economic uncertainty. We still have a ways to go. I realize that we often 
don't report status in a timely way in the RQCC, and not all the reports we 
want to have been fixed. There will always be issues with software; the key 
is choosing the right battles. Overall, we must be doing something right.

- Bill, RunRev marketing guy

 





More information about the use-livecode mailing list