Hi Paavo, Just tonight, a reader from my site wrote to say that in the past, all =20 the documentation he had previously read had led him to misunderstood =20 the syntax of a simple 'if expression, originally thinking that the =20 conditional evaluation needed to be placed in brackets (which made =20 every condition always evaluate to true...). Even things like that =20 can be tripping blocks for newcomers, so I agree that obfuscated code =20 can be totally unfathomable.
With that said, it is important to recognize common code patterns and =20 Rebolisms that are fast and short in expression, even if they're hard =20 to read at first. I don't know that common (more difficult to read) =20 syntax necessarily needs to be avoided and replaced with obvious =20 patterns. (If they're common, they _should_ be internalized). =20 Instead, what I missed in the beginning with Rebol was more documented =20 examples ... I mean the kind of detailed, line by line documentation =20 needed to understand each expression, as well as the overall structure =20 of a script. I love the idea of maintaining a collection of useful, classic =20 programs that demonstrate common techniques and solutions to typical =20 problems and situations. Having a clear English language =20 translation/explanation of any code, no matter how unreadable, can =20 make it much more friendly to digest and internalize. If I were to =20 put forth the effort, instead of rewriting examples to make them more =20 readable, my suggestion would be to just write lots of more detailed =20 explanation - LOTS more. Anyone interested in making Rebol more accessible to others could =20 potentialy help by adding detailed documentation to scripts that are =20 in the public domain. Anytime someone has an "aha" moment, =20 understanding how a certain expression or code pattern works, in the =20 example where it occurred, notating that realization would undoubtedly =20 help others down the road... I'm sure that line-by-line explanations =20 of more code from rebol.org would help average new users dramatically. =20 Anyone can help with that sort of thing - and the wiki sites are =20 great resources for creating repositories of analyzed and notated code. If anyone is interested in starting a project like that, we just need =20 to copy over a few scripts to a chosen wiki, and add our own comments. =20 As an example, I put Frank Sivertson's Rebtris, up at =20 http://en.wikibooks.org/wiki/REBOL_Programming/Examples . I wonder =20 how long it would take to get such a script completely notated... Quoting Paavo Nevalainen <[EMAIL PROTECTED]>: > > We have a tendency to produce code, which is ultimately fast or short > in expression. It is so since we maybe compete a bit which each other, > which may lead to bizarre code from the beginner's point of view - and > from the point of view of any non-reboled person. And even a "personal > programmer" have to cope with others nowadays.... > > So, it could be useful to rewrite some "classics" again readability in min= d. > Some examples could come in two versions, prototype or documentatory > version, and optimised production code. I could help in that process, whe= n > R3 is ready (I know I am a simpleton, so obviously I am not the one who > produces the optimised code ;) ) . > > -- > 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.
