Thank you Allen. I plead guilty to not having fully studied the user guide which is the closest thing to comprehensive documentation. At least I scanned it carefully (more than you can say for most programmers)! The Guide takes a worm's eye view of the territory, not a bird's eye view. It reminds me of the old Inside Macintosh books. I tried to learn Mac programming from those books (thick as they were) and got absolutely nowhere. A magazine article hit the nail on the head when it paraphrased the Mac API as the assembly language of interface programming. I work as a professional software engineer and know several languages, compiled and interpreted. Learning curves are not mysteries to me; I know what they look like. The real point I am trying to make is that a dictionary-style documentation, or slew of examples, is the hard way to learn anything. I could tell you to learn the English language by reading the dictionary. Technically speaking it covers everything you need to know, but then again -- it doesn't. The Guide takes an approach that is just barely one level above a dictionary. It categorizes REBOL thingys into groups of thingys without saying what makes a REBOL program a REBOL program. There needs an architecture discussion to lend coherence to the whole situation. Especially useful would be - background philosophy (why REBOL? what's better about it? white paper time!) - comparison with another language doing the same task (esp. Perl which seems to be the main competition -- comparative examples are often the most important) - visual block diagrams instead of words (show me the chain of evaluation in a flow chart not a dictionary presentation which asks me to reconstruct the flow based on dry definitions) - clarification of the 31 flavors of REBOL (/core, /view, /whatever /else) - what are they, when are they planned to ship, what is the price tag, why so many flavors - clarification of exactly what things are done behind the scenes and how (memory alloc, run time typing, etc.) These suggestions are given in a spirit of constructive critique. The point here is to convey the mind of the language designer to the readers. Then examples will fall neatly into place. Mark -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 27, 2000 7:15 PM To: [EMAIL PROTECTED] Subject: [REBOL] REBOL and e-commerce Re:(5) Hi Mark, All Rebol scripts are documentation, don't look for all your answers in manuals, spend time reading the example scripts, each one is a mini how-to document. [snip]
