Rev_rant part 1

[Dave]

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