Making the move...

[Richard Gaskin]

Marielle wrote:
> What you get with Java, Ruby, Ajax that you don't get with runrev is  
> the following.
> 
> 1) Re-usable LIBRARIES.
> 
> Honestly what I have read recently on how revolution is so much  
> superior to Director or Java is just a *BIG* joke. Agreed, revolution  
> let  you write stuff rapidly. But you have to write the same stuff  
> again and again and again and again. But what java does is let you  
> write it ONCE and REUSE it again and again and again.

Coding for reuse is a choice. There's a lot of Java out there that can
barely be used, let alone reused. :)

I rarely write the same routine in Transcript more than once, and every 
app I write is completed with considerably higher ROI than the last 
because of the ease of reusing code libraries.  In my most recent 
project I would estimate that some 70% of the code base is in reusable 
libraries.

There's even a Scripter's Scrapbook that Hugh Senior wrote in Rev to 
encourage even greater code reuse (with a jaw-droppingly complete 
feature set) at <http://www.flexiblelearning.com/ssbk.htm>.

Stephen McConnell's "Code Complete 2" offers a great insight into coding
for reuse (among many other things), and just about anything from him is
chock full o' good ideas.

I've touched on reuse in my presentations at Rev conferences, and it
would probably be useful to also address this in greater depth at
revJournal.

In the meantime, "Extending the Runtime Revolution Message Path" at
<http://www.fourthworld.com/embassy/articles/revolution_message_path.html>
introduces the mechanics of implementing libraries, and my Handy
Handlers series at <http://www.revjournal.com/tutorials/index.html>
discusses the style side of crafting handlers with an emphasis on
generalized reuse.

It should be noted that while the specifics of coding for reuse in
Transcript often rely on mechanisms unique to the language, those
mechanisms are simple to work with (e.g. "start using libMyStuff") and 
the patterns governing reuse are pretty much the same as for other 
procedural languages (error-checking params, conscious source-to-dest 
param order, useful defaults for optional params, etc.).

Any developer thinking ahead and exercising a little self-discipline can
get the same level of benefit of code reuse in Transcript as in just
about any procedural language, arguably more so in many cases given
Transcript's self-documenting nature and the simplicity of using library
stacks.

That said, there's a fine line being drawn here.  On the one hand you
seem to request a professional level of self-discipline from those who
publish libraries, while elsewhere suggesting that Rev be used by more
newcomers and non-professionals.  As long as there are people who
haven't yet made a million mistakes, they will code in ways that don't
prevent them. :)


> 2) Rich and easy to access documentation
> 
> If you want to use a java library written by somebody else, simple,  
> you get access to the API online and you know what method to call and  
> how. You don't need to know *anything* about the inner workings of  
> the library. Why is it? Because some some conventions have been  
> created which let you comment your script in a very efficient way,  
> where the API doc can be automatically generated from these comments.  
> http://java.sun.com/j2se/javadoc/. There is *NOTHING* even close to  
> this in revolution.

Again, this is a matter of choice on the part of the developer.  Some
are simply more diligent documenters than others.

While the number of lines needed to extract APIs from a Java code base
is so great that Sun needs to provide a tool for it, getting a list of
handlers from a script in Transcript can be done in just a few lines
(see the MC IDE's Script Editor or Geoff Canyon's post at
<http://lists.runrev.com/pipermail/use-revolution/2006-March/078496.html>).
  Modifying those routines to also include params would be trivial.

But for such extraction to be useful the key is to provide meaningful
parameter names.  Remember that Java's a typed language so the
prototypes will tell you more about a param than its name alone will.
So again, this is a choice and some do it better than others. K&R-style
single-letter arguments won't tell you very much. :) (A few tips on
naming conventions are shared at
<http://www.fourthworld.com/embassy/articles/scriptstyle.html>).

Taking this notion one step further, the Rev Interoperability Project
(RIP) at <http://groups.yahoo.com/group/revInterop/> offers guidelines 
for libraries to include API documentation, and in a way that makes it 
relatively simple for a single doc-reader stack to easily display the 
API for any RIP-savvy library.

Conventions exist for both Java and Rev; they're only as useful as they 
are adopted, and Java is used by more professionals for whom the 
benefits of self-discipline pay bigger dividends.


> 3) Member's sense of investment in making their work freely available
> 
> Yes, you can do fantastic stuff with revolution. But you have to  
> start from zero and do everything by yourself.
> Because of all the effort, it is only worth it if you plan to sell  
> your application to a small numbers of high-paying clients.

Exhibit A: RevOnline

Exhibit B: <http://dmoz.org/Computers/Programming/Languages/Transcript/>

Exhibit C: Dozens of other resources that can be pulled up in Eric
Chatonet's wonderful search tool.

Many of the libraries available offer free use, and some are even open
source.

> So Richard, why is it that sourceforge project you are admin of is  
> still empty? It was registered in 2001.
> http://sourceforge.net/projects/opn-repository
> "A project to create a publicly accessible library of handlers for  
> the xTalk family of languages. The immediate aim of this project is  
> to create a robust library of handlers for the cross platform  
> Metacard/RunRev xTalk family of products."

I didn't set up that group, and was made aware of my status there as an
"administrator" only last week when I got an expiration notice from the
site.  That must have been set up in the early days while we were
fleshing out the workflow for the MC IDE.

The MC IDE project lives at <http://groups.yahoo.com/group/MC_IDE/>.

The discussion list of its ongoing development is at
<http://www.mail-archive.com/metacard%40lists.runrev.com/>.

A summary History and Roadmap of the MC IDE project is at
<http://www.mail-archive.com/metacard@lists.runrev.com/msg10627.html>.

To date we've had more than a dozen contributors to the MC IDE project,
and have had fresh releases nearly every quarter.  Klaus Major, Ken Ray,
and myself are working on parts of it right now.


> I had a chance to see David's (Bovil) library of handlers: Very  
> impressive.

He does good work.  Let's call that Exhibit D. :)


> 4) Structure that encourages and facilitates collaboration
> 
> You can, in fact turn your work into reusable libraries, with a bit  
> of experience in writing such stacks. People like Eric, Scott, and  
> many others have very generously contributed high quality demo  
> stacks, but the number of libraries available is just ridiculous  
> compared to the ones on rubyforge/sourceforge. In sharp contrast with  
> the ruby and java community, these libraries are not shared, there is  
> nothing like rubyforge or sourceforge where you can easily provide  
> information about your project and receive feedback on them. There is  
> nothing like rubyforge or sourceforge where you can get to know of  
> the existing projects and get to propose your collaboration.

Have you tried emailing the developers?

Constellation used BaseMap; RevIPC, mmgen, and RIP use Yahoo; the MC IDE 
project uses Yahoo for file distribution and a list hosted by RunRev for
management discussion.  Developers are free to choose what they like for
managing their work, and they do.

As for the number of libraries, the other languages you cite are either
gratis and/or open source.  Remember that many open source projects
represent a form of "socialized software", since the project took root
at publicly subsidized universities (which I like, BTW; I'd rather have
my taxes create livingry than weaponry whenever practical).  Java is an 
exception, but it isn't open source; Sun makes the investment for 
strategic reasons.

If you can get public funding or a major corporation to throw money at
RunRev Ltd to convert Rev to open source there may be an opportunity
there for all of us.

In the meantime, software remains expensive to create regardless of the
license it's deployed with, and not everyone has accumulated the
independent wealth needed to displace paying work with volunteer work
full time.


> On top, though it is possible to write libraries, there are aspects  
> of the transcript languages which don't really make it pratical to  
> consider flexibly using 20-100 libaries. Scott Raney recognized this  
> and was apparently planning to work on it. Hence, another *very*  
> important paragraph on the Metacard annoucement page (http:// 
> www.metacard.com/pi5.html) was:
> "The MetaTalk language will also be extended to provide a more full  
> featured object-oriented programming environment, which will allow  
> development of larger-scale applications with MetaCard. The key  
> tenants of object-oriented programming - encapsulation, polymorphism,  
> and inheritance - are already available in the MetaTalk language, but  
> must be extended before MetaCard will be as appropriate for large  
> multi-developer projects as it is for the single-user projects that  
> are presently its forte. "

As a proprietary product, neither Dr. Raney nor the current owners would
divulge details beyond the sort of high-level abstractions presented there.

That said, sometimes interesting things get discussed at NDA'd sessions
at Rev conferences.


I was about to delete this next paragraph and move on to more relevant
things, but it contains so many factual errors that it would be a
disservice to newcomers here not to address them at least in summary:

> In sharp contrast with the work initiated and planned by S. Raney,  
> what I have witnessed over the years is a readiness from runrev to  
> punish the ones who had made significant contributions to the  
> community. Richmond was banished for his views on opensource. 

That's not why Richmond was temporarily banned from the list.

Richmond  has been openly supportive of RunRev and their licensing 
terms; many others here hold much more passionate views of open source 
than he yet have never been banned.

While I disagree with the latest reasoning for his being banned, it had
nothing to do with his views on open source. If this isn't clear you may 
want to review the list archives.

> Ken's stackrunner has been recently not outlawed.

Not outlawing something is a bad thing?

StackRunner remains available at
<http://sonsothunder.com/devres/revolution/downloads.htm>.

> Xavier was attacked for preferring to use  a product  -- metacard
> -- that authorizes the  creation of true open source resource...

MetaCard hasn't been a product for many years; it's an add-on for the 
Rev engine.

Like any IDE or set of plugins, the MetaCard IDE is just a collection of
stacks which require the Rev engine to run.  The license agreement for
the MetaCard IDE makes its open source status explicitly distinct from
any terms for the engine needed to run it, and refers the reader to the
RunRev license for any questions about usage of the engine.

As for Xavier, he made a choice for himself and I respect him enough to
honor his decision.  You might do well to show him the same respect and
discretion, allowing him the courtesy of representing himself.

> I have heard that despite an official discourse of authorizing freeGui,  
> another open source project, Kevin in fact contacted Alain Farmer to  
> ask him to stop... or at least make sure it was not too successful.

FreeGUI remains available at <http://groups.yahoo.com/group/freeGUI/>,
languishing more for lack of interest than anything else.

Given its goal of providing a more HyperCard-like experience to
newcomers, I'm surprised more people haven't shown an interest in
contributing to it.  But it's there if they do.  I think it's a neat
project and would love to see some fresh blood flesh it out some more.


> 5) Equalitarian system where the contribution of each person is  
> valued the same way
> 
> In rubyforge, sourceforge, what counts in the quality of the library.

Maybe that's why so many projects there haven't had activity in many
months. ;)

> There is little information about the professional status of the  
> persons involved in each project. Profit and non-profit have the same  
> opportunity to have their initiative noticed. There is revonline, but  
> it's really nothing compared to rubyforge or sourceforge and there is  
> a 10MB limit anyway so you cannot really post anything but toy  
> projects there. 

Of what practical use would a library be if it weighs in at larger than
10MB?

As you noted, some Rev folks do use SourceForge for their libraries, and
there's nothing stopping anyone from using any other means of
distributing their work.

I mirror RIP at the revJournal site because I have a hundred megs free 
there; lots of room to grow, but I pity the person who would have to 
wade through 100 megs of stuff. :)


> FYI, in reality, something as good as google earth  
> has been realised long ago in our community. It has been advertised  
> on our lists. But this person didn't present himself as a  
> professional... because he was not one and he apparently largelly  
> ignored.  http://ddm.geo.umass.edu/. The excellent work of Jim Hurley  
> and others have suffered similar fates.

Jim, do you feel abused? :)

These developers are among the most celebrated members of our community. 
  The archives are full of "way cool!" commendations to these people, and
I believe Kevin has even demo'd Dynamic Digital Maps at a trade show as
the cool example project it is.

I do agree that more can be done, such as making the list of cool stuff
at <http://downloads.runrev.com/stacks_apps/> more comprehensive.

I had the pleasure of serving tiramisu to Richard K. Herz at one of our
Rev meetings here, where I thanked him for his wonderful contributions
with his Reactor Lab (see <http://reactorlab.net>).  That was the same 
night we honored Mark Talutto's birthday, who was also thanked for open 
sourcing his nifty presentation tool at 
<http://groups.yahoo.com/group/mmgen/?yguid=7661942>. If I could I'd 
send tasty desserts to all the folks who help show off what Rev can do, 
but I think the community does what they can to show appreciation for 
these contributors.

Hats off to the lot of them!

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com