* Alessandro Manotti <[EMAIL PROTECTED]> [060503 05:06]:
> 
> I think direct help supplied by rebol (from console use ?) is the first ste=
> p.
> Then I hope developers of the dialects need to create the right
> documentation, as per any programming language!
 
  I use a dialect called 'ml developed by Andrew Martin. It renders
  html/xml content. Runs rings around Python HtmlGen.

  I'm rewriting my own sql dialect, which runs "on top off"
  mysql-protocol. It will make composing sql querys much easier.

  I'm a "part-timer", i.e., I write about equally in python and
  rebol plus javascript and some lisp. The glory of rebol is that
  you can (like lisp) actually process symbols (words) - and that is what
  enables DSL (domain-specific-language) approaches.

  The disadvantage of rebol is this:

  Code can very quickly become unreadable. Documentation is really
  helpful for me to learn how the real rebol gurus do things. Whereas
  python lends itself by it's own syntactical rules to extreme
  readability rebol's 'freedom' can quickly lead to obfuscation.

  I'm emberassed to say, that although I've never written a single line
  of perl code, I can very often better understand what my partner's
  perl code is doing than some *very high-level* rebol code.

  In my opinion, as the complexity of the resource (DSL, protocol,
  function etc) grows, so should the documentation grow.

  Here's a link to a python module that I've written. When you point
  directly to it, it renders its own documentation.

  http://www.wabo.biz/cgi-bin/py/fdb.py

  Python makes it easy to create modules this way, and it can be done in
  rebol too.

  MTCW
  tim

-- 
Tim Johnson <[EMAIL PROTECTED]>
      http://www.alaska-internet-solutions.com
-- 
To unsubscribe from the list, just send an email to 
lists at rebol.com with unsubscribe as the subject.

Reply via email to