All, I would echo Bernie's comments generally.
I went so far as to buy consulting time and travel to the Boston area so that an associate and I could meet with some folks who had used REBOL successfully in their consulting business, in pursuit of an experience that would help us "get" REBOL in an "aha" kind of way. The problem in my mind is this, FWIW. -- Time is short. -- REBOL is *very* unlike most mainstream scripting languages (I think). -- The promise of greater expressibility, reduced coding effort, etc., is only realized if you "get" the "REBOL way". We have some production REBOL code running in our company now. But we are much more confident investing time in becoming adept in Python going forward, for the following reasons: -- Python documentation is plentiful, such that I can read a *lot* about it as I get my feet wet. -- There is a strong and well-established Python community to get assistance from. -- The availability of modules to extend Python into many problem domains is impressive, and the documented use of these modules instills confidence in the attempt to use them. None of this is really a knock on REBOL. My instincts tell me that if I was an expert REBOL programmer, many challenges would be easier to engage than I anticipate will be the case with Python (especially with respect to GUI development needs). What I really wanted in traveling to Boston was to watch someone skilled in REBOL take me through a variety of simple challenges, all the while pointing out why this or that particular feature of the language allows for such an elegant solution. That is perhaps a lot to ask for in a 1/2 day day-trip where REBOL is not the sum of all the company's business focus. I believe that in order for REBOL to overcome the more "established" languages that tout serious productivity advantages, it will be necessary to explicitly demonstrate REBOL's elegance in comparison. It will have to be shown explicitly, for example, that designing a prototype group calendar application would look like this in Perl, like that in Python, and like this in REBOL. (Pick the best illustrative example challenges you like.) I do not subscribe to the idea that the greatest audience for REBOL adoption are green programmers looking for a suitable first or second language to master. Rather, proponents of REBOL should make the case for higher productivity directed precisely at those who successfully employ other languages. Take on the conversion challenge, I say. Don't merely put REBOL on a Linux distribution disk as if it might be a "toy" or experimental language to "give a whirl". Instead, make the bold claim and illustrate it; throw down the gauntlet as it were. If you convert skilled Python or Perl programmers (even a small but vocal group of them), I think much more is accomplished. The converts invest time and effort in pointing out the advantages to their respective language communities, and they can do so with considerable credibility. This is of course just my own instinct. If RT offered a very well-developed training seminar to illustrate the joys of REBOL in a variety of problem solving dimensions, progressively enabling an appreciation for Carl's achievement and vision, I'd be very interested in attending, as I and my employees will need to develop *lots* of software that accomplishes many diverse business functions in the years ahead. Any true competitive advantage is *very* compelling to consider. I am genuinely interested in the REBOL community's thoughts re how such comparative illustrations might be most effectively accomplished, if you subscribe to my POV at all. Just my 3c or so... -- Mike Michael Mastroianni President, Fluent Energy [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Gregg Irwin > Sent: Tuesday, July 12, 2005 6:12 PM > To: Bernie Schneider > Subject: [REBOL] Re: REBOL Tutorials > > > > Bernie, Steven, et al > > These are all good and valid comments about the state of REBOL docs. > In some cases there aren't any docs, and in other cases there are too > many docs scattered about and sometimes they're very similar. > > Examples tend to favor conciseness very heavily; good for > experts, not > for newbies. It's kind of a catch-22. People want to show > how it takes > very little REBOL code to do things, but that means leveraging REBOL > in ways that make it harder for newbies to understand. By using > examples that are easy to understand--because they look like examples > in other languages--it can be hard to see that REBOL is different. > And, yes, REBOL's flexibility is both a boon and a curse. :) > > The idea of embedded documentation is based on Literate Programming, > which could actually be a pretty easy thing to do in REBOL, with > make-doc; just have an emitter spit out the code sections as a .r > file. > > I can't say why REBOL clicks OK for some folks and not for > others, but > I *can* say that RT really does want to improve the state of REBOL > docs dramatically. There have been a lot of good comments here lately > and I'm trying to mark them so they don't get lost. > > If anyone has specific examples of docs for other languages that they > feel have helped them, pass them on to me, or post them here or on > AltMe. > > -- Gregg > > -- > To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject. > -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
