On 10 Nov 2006, at 15:37, Bernard Devlin wrote:

Hi Dave,

I'm not sure if you intended this email to come to the list (some stuff in it sounds oddly private), but since it is now in the public domain, I'm going to reply to it. I'm not sure if I'm getting all the mail that goes to the list, so apologies if I'm posting out of context. Also, as it's a long reply, I'm going to split it into sections (the list doesn't like messages above 15kb).


>>
There is definitely a problem with "silly" bugs and lack of a clear
way of finding answers to problems within the Rev environment - in
short it takes a long time (more than necessary) to become a RunRev
"expert".
<<
If a bug affects you, then yes it is annoying. But in 3 weeks of intensive development, I came across 1 bug. The advice on how to fix it was readily available by dropping in to chat with my chums on ChatRev (indeed I felt very stupid for not thinking how to solve it for myself). It wasn't a show stopper, but could well cause a new user to doubt the power of Rev. As for your other remark about how long it takes to become an expert - I have dabbled in Rev for the past four years, committing myself instead to developing web applications. Well, after 4 years I've come to the conclusion that I have wasted far too much time trying to get reasonable UIs working in those web applications (I was using what became the dojo toolkit before AJAX was invented as a word/concept). I have achieved far more in three weeks with Rev than I could have ever achieved in 3 weeks of web development. In fact, I'm re-working an entire client-side toolkit (that was previously written in Java by a famous company with some of the best developers in the world), and I'm adding features to it that they never had (such as broadcasting change notifications to other users based on what data they are currently viewing). One of the things that I have wanted for a long time in Rev is integration with a VCS - so I've written an application to convert Rev stacks to XML and back again, so that they can be under version control. I'm a long way from being one of the Rev experts to be found on this list, I would estimate that over the past 4 years I've spent less than 5% of my programming time using Rev, yet I would say that I'm able to achieve more in Rev than I am (for example) in languages like Javascript or Java, where I've spent considerably more time.

A lot of the problems I have encountered in RunRev haven't actually been "Show Stoppers" as such because there is a workaround available, however I decided early on that to be really efficient in RunRev you need to develop your own framework (or use a 3rd party system), if you do this right you can obtain the maximum code and screen design re-use. The problems that I found were because I was doing things that probably had not been tested and probably doing things that 95% of RunRev Scripters/Programmers don't do!


I just don't know what you mean by "there is definitely a ... lack of a clear way of finding answers to problems within the Rev environment". The documentation is actually some of the best I have seen (try using some Java libraries where all you get is an API). There is this user group (where requests for help rarely go unanswered) - I know official fora of some companies where 20% of requests for help go unanswered.

For instance, do you know that the following statement:

put the cp1 of this stack into me

in a function in to the field script, will, under certain circumstances fail and set the field to empty?

I wanted to be able to use "me" in this way so that the code was completely context-free. I had maybe 10 windows to put together and I wanted to make sure that this basic idea would work. I found that it worked sometimes! So asked for help from the list and eventually found out a work around. Now, from the documentation, tell me what the workaround is! (Clue: I know of two ways). This was not a show stopper in the sense that I couldn't just drop my idea and make my code more context sensitive which would mean I'd have to do more work and have more bugs, so I couldn't get on and develop my code until I knew the answer, which after a few days discovered thanks to help from the list. In this case the delay led to frustration, especially when I knew the answer, which was (as are most answers!) simply to implement!

All the Best
Dave



_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to