Rev_rant part 1

[Bernard Devlin]

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.

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.  There is ChatRev - a nice, cosy  
place where some very knowledgeable people hang out - if I'm stuck  
and really impatient I go there, and after a few minutes of chatting  
I've got the information I need (sometimes at 7am, other times at  
11pm).  You can get official technical support from Runrev at a  
fraction of the price of other companies.  You have access to  
bugzilla.  You have 2 Rev conferences a year that you can attend.

I thought a couple of weeks ago that some of libURL seemed badly  
documented, and after asking for help (which I received within  
minutes) I realised it was my own mis-reading (the use of 'it' as a  
keyword does sometimes have its drawbacks).  A couple of days ago I  
thought that the pErrors caught in a try/catch was badly documented.   
Turns out it is a little obscure, but again, in almost no time at all  
I had one of the users here pointing me to a library he's written  
that would help me in this regard, and which does more than I would  
probably even have imagined I could need.

Bernard