On 21/04/2004, at 1:02, Norman Winn <[EMAIL PROTECTED]> wrote:


Norman

I am aware of responses already from Ken Ray and James Richards to your comments below but, as author of the key programming step I find excuse to add my own perspective.

I am a user assessing Revolution as a replacement++ for Filemaker. I am also assessing other tools so am following this discussion with interest. Here are my observations:
There has been a recent thread on Filemaker and RR. If you missed it you should look it up as well.

1) Can any of you consider this to be a fair comparison?
Yes. Perfectly. It was up there on the web site for the same time for everyone and, so far as I know, posted to all the lists. I assume that the RB players paid it no attention as the game appeared already won. In any case it took me very little time after I got hold of real data to work out a solution and another day before I had time to publish. As I have written previously I think winning "it", the simple speed comparison, does not matter.
You, the 'you' being probably the best RR programmers on the planet, have had a couple of weeks [sic] to optimise RR's algorithm.
Sorry, because there is no reason you would know, but this is hilarious; at least for me, not for my brilliant colleagues. I have not programmed anything for sale or direct profit since selling my small business at the end of the eighties. For me, RR is a handy scripting tool replacing awk for one-off manipulations of patterned data and HyperCard for small applications which help me either in my business or my hobbies. I know practically nothing of its multimedia or visual design capabilities, for example, and never read those posts.
Has the sense of justice in anyone pushed them to pass the challenge to the RB list?
You know now that Ken said as much. You might also look up my response to his post to see that in my view all of this is fairly unimportant anyway. See also Richard Gaskin's posts on the topic.

2) One of the suggested strengths of Revolution is the simplicity of getting things done. Why should such a common task take such a lot of optimisation to produce the best results? Are not the 'out of the box' solutions i.e. those that will be produced by the average user, a fairer comparison?
As Ken pointed out, the challenge was not "What does it do?" but "This is what it does; make it go faster". The actual text from Chris' first post is "...try to tweak them to run faster. The object is ... to create the fastest code..."

3) On a more positive note, the possibilities of optimisation have revealed to me a rich programming environment underlying the IDE,
Now we come to the important point, at least to me. The original problem set by Chris used artificial data. Ken Ray promptly blew that away by exploiting the enormous redundancy using a keys comparison. I wrote to Chris asking for some real test data and at about the same time he put some up on his site. Seeing data patterns, I exploited this and an alternate Rev command to more or less settle the issue. Chris tried some tests on real real data and before and after this Monte Goulding and Brian Yennie published what I call production optimisations, which exploited possible repetitions in serial analyses.

Note the thread in this: optimisation is a function of the data you face, more than the tools at hand. Richness of the tool set makes more optimisation opportunities available. Here, we optimised speed. Remember those other two in the impossible triangle, cost and quality?** They too can be optimised with Rev, which is partly why I enjoy using it.

Hope you make a sound product choice which satisfies your application needs, is enjoyable _for you_ to work with and is well supported on its user list.

regards
David

**(Old programming/engineering saying: You want it fast, high quality and cheap; any one is easy, you can get two, but you can never have all three)


Norman Winn
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to