Comments on: Making it easier for new users

A lot of the discussion on the "Try REBOL 3" blog was a bit off topic. Somehow a thread got started about the problems new users face and how certain simple actions are done. For example, how do you translate a character into its numeric representation?

Many of the questions were answered quite well by other users... but it does raise two questions in my mind:

1. would there be some value in a translation glossary?
2. do we need a "starter-kit" that includes helper functions?

Translation glossary

On the first, I'm thinking along these lines: a bunch of us in the community could build a web page on the wiki with a glossary such as:

Starter kit?

For the starter-kit, we could provide a module of common functions to do things that users have done other ways in other languages. I've been reluctant to do that in the past, because it allows users to avoid learning the best way to do such things.

But, for example, consider the substr function that is used to copy part of a string.

In REBOL we do this with:

str: copy/part start end

where start and end are the series indexed to the range over which the copy should occur (but end can be an integer length as well.) What's important here is that you can see that this is a copy, and you can use copy various ways.

A user familiar with substr from some other language would want to write:

str = substr(fullstr, index, length);

Of course, the user may not consider where the index came from or how the length was determined. For example, the index is quite often the result of a search:

str: copy/part find fullstr "xyz" 10

or, using the substr function:

str = substr(fullstr, strpos(fullstr, "xyz"), 10);

So, that's what's really going on most of the time. Examples shown in manuals of:

str = substr("abcde", 3, 2);

never actually happen in real code. Most of the time, you need to call other functions to get the required arguments.

Hmmm....

Well... now that I've written this example... perhaps it's better just to add that to the glossary table. It's probably better that users truly learn what a series is, and not use index numbers everywhere.

Please share your thoughts on this topic. And, if you know of a web page that already includes this information, post it, and we can add it to the main docs page.

28 Comments

Comments:

Carl Sassenrath 29-Sep-2009 13:13:36	Should I move the related comments from the "Try REBOL" blog to here? Would help unclutter that other discussion.
Carl Read 29-Sep-2009 16:30:36	I think moving comments from post to post is a really bad idea. What if someone links you the comments? Threading's a good way to handle things going off-topic. A good example: Oh look, browser war... I doubt you've time to tweak your blogging code to manage threading though, so leave it as is until you need to handle thousands of comments.
Carl Read 29-Sep-2009 16:42:45	Tags might be a good idea though. One set for your posts and another for comments that've gone wayward.
Grant Rettke 29-Sep-2009 22:34:07	You ought to set up a guide, something like this: http://docs.plt-scheme.org/guide/index.html that highlights everything in the newest version. It is still mysterious to outsiders like myself why REBOL is so great. It deserves a Guide.
-pekr- 30-Sep-2009 6:32:07	Grant, R3 Docs are emerging under following link. It is a wiki, so user with high enough ranking (taken from R3 Chat system) can edit docs, enhance it, etc. http://www.rebol.com/r3/docs/index.html We still need to make docs better, but it is a good start indeed. RebDoc wiki is kind of mess right now, and should be purged imo :-)
Edoc 30-Sep-2009 6:36:56	Perl or Java might be good code references if you want to attract old-school developers, but I would also consider Javascript and PHP, because web devs/designers know them, and they typically work in environments with more toolset flexibility.
Edoc 30-Sep-2009 7:20:17	Another thought. I would also consider creating a comparison table of regular expressions to REBOL parse. Cover simple cases of validation such as: IP addresses, email (basic ones), URLs, social sec #'s, credit cards, ISBN numbers, USPS/UPS/FedEX tracking #'s, UPC codes, patent numbers, FAA airplane registration codes, IATA airport codes, dates, FCC equipment ID's, ZIP codes, area codes, phone numbers, vehicle VIN numbers, hex colors, user names, the "h" web microfomats (e.g., hCard, hCalendar and others), and REBOL datatypes. If you want to really give newbies a boost, I would consider making the most common datatypes and micro-formats and issuing these as a standard rule-set library available with all distributions.
-pekr- 30-Sep-2009 8:23:48	Carl, such table can be a good idea, as we have already some "translation" tables, look into the bottom of the page of the following link: http://www.rebol.net/wiki/Datatype_Notes Those tables might be helpfull to users, as that way they know, what results they can expect when converting datatypes. Do you think such tables could/should be part of official R3 docs? Maybe different formatting is needed, but generally those could be usefull. The content is dated though ... As for helping newcomers to adapt, apart from solution conversion table, it could be part of categorised How-To, One-liners, etc. docs. Or, it could be part of Concepts. Simply put - at each Concepts category end, you could introduce How-to, or Notes, or Did you know? section, where some things could be pointed out. So in Object concept section, we could e.g. point out, that subobjects are shared on creation. In Series section, you could point out Substr or other frequently looked up "idioms". And if some things are really idioms, we should think to add them in special modules. The worst thing is, that with some such idioms, though there might be xy ideas, of how should they work, and we could end-up adding xy refinements, making it slower, bloated, and supporting bad REBOL coding practices, instead of pushing new users to learn REBOL concepts to his/her advantage :-)
Hostile Fork 30-Sep-2009 8:46:47	It doesn't hurt to have a lot of these mappings. I suggest doing this in a way that you can generate views based on which languages someone wants to see. As for how to prioritize, JavaScript is probably the most universal language right now. Everyone on the web has to deal with it at some level, no matter what they're using server-side. People still using PHP and Perl are probably not very interested in things that are different and exciting... so if you've got that JavaScript baseline covered then maybe you should focus on Python and Ruby. There's probably a certain value to covering LISP, in terms of having an empathetic audience... Would be nice to map into multiple Rebol solutions. "Terse" and "Verbose"... for instance. I think the all-in-one-line-with-no-parentheses style is overemphasized to new users at the moment. Sometimes its good to call subexpressions out into their own variables in order to make examples clearer. xyzPosition: find fullstr "xyz" str: copy/part xyzPosition 10 ...then offer "the subexpression is not necessary, however": str: copy/part (find fullstr "xyz") 10 ...then say "plus, because find knows it takes two parameters, the evaluator doesn't technically need the parentheses. though this can be tough to read at first, with experience it becomes natural as our ability to parse English sentences--and is preferred by many Rebolers": str: copy/part find fullstr "xyz" 10 Also, remember fresh eyes looking at this won't grasp how it could possibly be a good idea to use a slash in a name instead of inventing "substr" and calling it done. So take the time to point out that the same copy routine works for other series, and how copy without the /part takes only one parameter...
Giuseppe Chillemi 30-Sep-2009 8:53:45	Avoid making this module because it would maintain the old programming "context" in the mind of developers creating more and more confusion. It is true that people tend to maintain their own ideas but to learn REBOL you have to leard the basic concepts and how the compile acts. A simple table with comparison between functions in other languages and how in REBOL you get that working would be good. This table must be at the end of chapters which fully explain the inner working of the fuction exposed. Carl, I have written you privately: what old school developers are missing is a deep explanation of how and why REBOL works in its way. Take them by hand and show your way ! Giuseppe Chillemi
Hostile Fork 30-Sep-2009 12:05:23	Guiseppe- To wit: No one thinks you should live in Scranton... but if that's where you are, then Google has to put it on the map in order to plot your route to somewhere else. (The motivation to move comes naturally, because you live in Scranton.) :) So obviously, mechanical JavaScript conversions is a terrible introduction to Rebol. Yet once a programmer has committed to learning the language, then providing a map from these patterns keeps them from getting frustratingly stuck on things they are used to accomplishing simply. It's really just acknowledging the reality of shared reference points in programming, and leveraging that commonality. My suggestion of including further notes along with the simple answer would address your concern of whether it could educate further. In fact, it would be nice to have a StackOverflow-like solution. The most expedient and clear answer would bubble to the top via the ranking mechanism, and those interested in getting perspective beyond "just the answer" can keep reading.
Ratio 30-Sep-2009 18:21:47	Hi Carl, most important for newcomers is ONE, but exact and exhaustive official REBOL DOCU. Instead we find a lot of always unfinished work scattered around the world. That's the main problem all newcomers have with REBOL !! In the interest of all Rebolers: Please do more about ONE central documentation - not always starting new ones and always leaving them unfinished. Rebol 3 seems to be the same even on code level! Rebol 2 is very good and could be developed instead. ---------------- You know it yourself, Carl. Your example of a SUBSTR function via REBOL obviously cannot work. Start, End are not defined, the series to work upon is not even mentioned! THIS short generic function solves the problems we have with datatype CHAR! - and another not so important issue. ;==================================== SUBSTR: make function! [ {USAGE: substr "1234567890" 3 2 - Result "34" substr "1234567890" 8 20 (or -1) - Result "890" substr "1234567890" -1 -1 - Result "1234567890" substr "1234567890" 11 -1 - Result "" SUBSTR can be used on strings, blocks and chars. Used on blocks a block is returned; if count = 1 you get it's value at start position. Datatype char! is always returned as string! If out of bounds an empty string "" is always returned. } xSeries [series! char!] start [integer!] "If = 1: start from first" count [integer!] "If < 1: Rest" /local result ][ xSeries: c2s :xSeries ; c2s converts to string if char! separate function since often used if count < 1 [ count: length? xSeries] result: copy/part (skip xSeries start - 1) count if none? result: c2s block2val :result [result: ""] ; none happens if empty block [] or out of bounds result ] ;=================================== BLOCK2VAL: make function! [ "Returns if 1 block its value" result ] [ if all [block? result 2 > length? result ] [result: pick result 1] ; pick returns NONE if [] or out of bounds, FIRST ends with RT errors in these cases. result ] ================================ Carl, please remove this illogical and totally unuseable datatype CHAR! - producing a lot of RT errors - completely! Using it internally is ok. On user level it's a mess. Thank you, Ratio
Henrik 1-Oct-2009 2:00:07	Ratio, you are solving "problems" that don't exist, as I've explained earlier. What you call "short functions", I call, "a big mess that doesn't belong in a REBOL program". :-) Your BLOCK2VAL function introduces a nice problem of altering the output datatype of a function to one that is complex to test for, forcing following functions to deal with that. I also did similar things early on, but fortunately learned to stop designing functions in this way. Your functions need to learn to be polite and have simple, predictable outputs. Consider this: block2val [[]] Now, how do we test for this and how do we make sure there are no bugs? This is a classic way to complicate REBOL programs, and it's also the same problem you introduce yourself, as the issues you seem to have with char!, except char! is easier to deal with, because it's tied to string and you can FORM your way out of the problem with one word. I'm also glad that you left out the mystery C2S function, because now I'm wondering how it works in SUBSTR: xSeries [series! char!] vs. xSeries: c2s :xSeries vs. if none? result: c2s block2val :result [result: ""] Looks fun to debug for a 3rd party developer. And there's a great bug in the last line, regarding the use of strings and COPY. I'll leave it to you to find it yourself. I guess this is where the complexity of many modern programs come from: Because the programmers don't completely understand the underlying system or language they are dealing with, and so, create "solutions", that duplicate the original functionality while introducing new bugs. I know, because I fell into that trap myself long ago. I know with myself, over time, my REBOL programs become smaller and less complex, as I still learn new tricks and shortcuts, even after 8 years of use. It reveals the design decisions on a deeper level made by Carl, when he developed REBOL 2. Careful thought was put into REBOL 2, but even more thought is put into REBOL 3 thanks to ten years of REBOL 2 use by many experts, and I'm not even one of those. As such, your "problems" won't go away with REBOL 3. They will likely become "worse", thanks to new features, like the new generic /INTO refinement.
tomc 3-Oct-2009 0:31:50	there was once a small discussion on porting the "Perl Cookbook" code to rebol just as other languages have. from wikipedia --- The Perl Cookbook inspired the PLEAC (Programming Language Examples Alike Cookbook) website, which translated the code snippets in the Perl Cookbook into other languages: Python, Ruby, Guile, Tcl, Java, and beyond. O'Reilly went on to publish other Cookbooks inspired by the Perl Cookbook's format, including Java Cookbook, Python Cookbook, CSS Cookbook, and PHP Cookbook. --- Had the conversation not been as short as it was perhaps Rebol would already be on that list. I do not think you should be writing the examples but maybe vet them after the fact.
Nick 3-Oct-2009 1:04:50	Why not just provide more examples? In my experience, people learn best by doing. Here's a little starter list: http://musiclessonz.com/rebol.html#section-6.4.2
Ratio 3-Oct-2009 16:31:19	Henrik, Ratio, you are solving "problems" that don't exist, as I've explained earlier. Earlier you "explained" NOTHING, Henrik. I now ask you the other way round: Where is your SUBSTR functionality??? Just put it HERE !!!!! We nowhere and never saw your suggestion. - You don't have any idea, right? Please do not tell us again something like: SUBSTR is not needed. SUBSTR is one of the most important BASIC string and array functions at all. If you even cannot understand this FACT, I'm sorry for REBOL "experts" like you. Ratio
Ratio 3-Oct-2009 17:00:32	Henrik ... that you cannot understand simple function calls used in our SUBSTR to avoid the CHAR! problem to do what is expected, if just ONE block is extracted is no reason for you or your "3rd party developer" to joke about SUBSTR . Better you think about REBOL which makes these workarounds necessary. Ratio
Henrik 4-Oct-2009 2:35:30	Earlier you "explained" NOTHING, Henrik. I now ask you the other way round: Where is your SUBSTR functionality??? Referencing the comment I made on 22-Sep-2009 0:56:31 in blog post 427: I explained the possible lack of consistency with the *STR functions regarding COPY I listed all the series navigation functions. Referencing the comment I made on 25-Sep-2009 0:41:18 in the same thread, I explained quite clearly why SUBSTR is not needed and handicaps basic functionality for navigating and extracting parts of a series using REBOL series and indexes: I wrote five separate examples, all gradually more advanced substitutes for SUBSTR. A sixth example demonstrated an equivalent SUBSTR version, both requiring more code and is slower to execute. SUBSTR is one of the most important BASIC string and array functions at all. Yes, and it works fine in BASIC. Please keep it out of REBOL, thanks. REBOL is not BASIC, even if it can be with one line of code, but BASIC is most definitely not REBOL. Better you think about REBOL which makes these workarounds necessary. I looked for earlier references to SUBSTR and found some (can only post one active link per post, sorry): www.rebol.com/faq.html#040 - was written quite a few years ago, using the same suggestion as myself. www.rebol.org/ml-display-message.r?m=rmlMRSC - was written in 2006, using the same suggestion as myself. www.mail-archive.com/rebolist(at)rebol.net/msg03990.html - a useful example with demonstration code, using the same suggestion as myself. It can however be done using half the code without SUBSTR and half the numbers needed, because you don't really need to know both the start and end index. In REBOL 3, the whole thing can be done with one line of code using FORMAT, but let's not tell anyone, ok? :-) This blog post, where Carl also makes the same suggestion as myself. vpavlu.plain.at/REBOL/examples/color-code.r?substr.rebol - written in 2002, using a slightly different version. www.rebol.org/view-script.r?script=substr.r - written back in 2003, shows how not to write it. www.rebol.org/view-script.r?script=substring.r - written in 2004, a little better, but mainly because it always returns a string!. This developer understood that. It seems that the practical users of the function just wrote that one line of code without fuss and they tailor made it specifically to their needs. Where are the problems?
Henrik 4-Oct-2009 2:53:35	Paraphrased: Henrik ... that you cannot understand simple function calls used in our SUBSTR to avoid the CHAR! problem This post is dedicated to the side effects of your char! "problem", but there is a small comment at the bottom related to why I don't bump into it at all. We can dig into the problem itself later. and to do what is expected, if just ONE block is extracted is no reason for you or your "3rd party developer" to joke about SUBSTR. Alright, the joke was uncalled for, sorry. But, you really, really, really want to study and simplify the outputs of your functions. If you keep writing code that way, you will eventually end up in black box land, where you can't easily read your source code to figure out the behavior of a chain of functions and your code will be full of hidden bugs that might only be revealed the day you want to re-use it in a different context. You need to run it through a test suite or use PROBE for hours and hours. I know, because I've been there and it's a silly place to be, when the code could have been designed properly in the first place. Basically, "smart" functions are bad. They are avoided in the REBOL core and it's a good philosophy to avoid them in your programs too. Even one of the most complex functions in REBOL, PARSE, returns either TRUE or FALSE and nothing else. A typical way to do it properly, is allowing simple testing of input from another function to be either a value of one fixed datatype, a typeset, FALSE or NONE. You can do this throughout REBOL without specifically having to ask for NONE?. You've probably noticed this. get-program-version: func [data] [any [:data system/version]] print-item: func [item] [ print either :item [["Data is" mold :item]]["Data unavailable"] ] Chain the two: print-item get-program-version attempt [program-version] Now, if there is a problem, you can do this: print-item get-program-version probe attempt [program-version] Because the output of get-program-version is simple enough, you can grasp its output through the printed result. But we also now know that program-version wrapped in ATTEMPT, causes 4 outcomes: program-version might not exist. program-version might be none or false. program-version might be a function which requires an argument, thus the block will fail. program-version might contain a value that is useful for printing. If you are satisfied with these terms, then ATTEMPT is useful. If you want to satisfy term 3, change the ATTEMPT to this: attempt [:program-version] This quickly tells me that program-version will now be molded and printed, even if it's an any-function!. Now, consider this: We can quickly determine that FALSE equates NONE in this case. If the difference is important, the design must change. Notice, there are only a few specific paths through the function chain, not hundreds or thousands? Notice, that I never specifically ask for datatypes? Notice, how print-item is universally usable? It can even use both string! and char! without problems. Notice, the simple output of get-program-version? These are just one-liners and of course functions eventually get more complex than that, but their outputs should not become more complex. Now, we can easily restrict the input to none! or tuple!s, and otherwise throw an error. Fortunately, the design allows me to do it both at the earliest convenience and only in one place: get-program-version: func [data [none! tuple!]] [ any [:data system/version] ] Now we have a nice and tight set of chained functions with a few specific outcomes that are possible to keep in your head and easy to debug.
Anon 4-Oct-2009 15:34:53	Ratio, char! is a totally logical and sensible datatype. What I don't get is: if you so utterly dislike characters, why do you deal with them at all? In other words: why not simply write your code so that you never even have to take care of chars?
Ashley 4-Oct-2009 17:19:44	If these are real issues, please discuss them with the community on AltME ... otherwise please refrain from highjacking/derailing Carl's blogs with disingenuous comments.
Gerard Cote 5-Oct-2009 22:16:07	In the past I would have agreed that some form of translation table (for many common languages) would have been the best way to proceed. But with experience I admit that I would now prefer, as a beginner (or even as a programmer coming from any language) to get some clear intent of the goal to achieve (call it an operation if it is a simple task) coupled with a bit of the way of thinking involved by REBOL, like in the example Henrik developed above. Call this "learning by example" or a cookbook, it doesn't matter to me. What is of concern is that the list of operations (goals) must be graded carefully, and described in accordance with this level. For example: At the primitive level, we need some examples illustrating the way of thinking REBOL programmers have to follow if they want to get it right. Sometimes it must be supported by short explanations (or links to external resources for such ones) related to some concepts of of the kind Henrik did above for the proven design of compositing functions and testing them efficiently (in a process similar to the one Unix creators followed in the past for their processes or C creator used for function return values). Some similar work needs to be addressed for illustrating how REBOL takes care of old concepts every programmer has to know about and really understand to become fluent when programming. A simple example commonly referred in threads comes to my mind: why not clearly explain how REBOL manages his memory, using clear examples and even contour diagrams if this is needed, showing how he stores (in an abstract way) his data and how the traditional concept of call by value (as is done when COPY is used), vs call by ref (as used by default when words get their value - and not all of datatypes!are defined in this way) used for sharing data between functions) vs call by name (REBOL can do it using DATA as CODE with blocks if needed) instead of continually repeating this information for ppl that are simply looking for their lost landmarks - whatever the language they come from, be it BASIC, PASCAL, PHP, Javascript, name it. (I think that I can do it now and I soon will do and submit it for addition somewhere.) Just to illustrate this further - I learned a lot recently about the meaning of context-sensitive as used by REBOL when I got a look at this site : http://blog.revolucent.net/search/label/dsl . Hey! this is just another concept that deserves some special mention ! This puts in evidence how REBOL is in a class by itself, is it not ?
Gerard Cote 5-Oct-2009 22:45:53	Finally sometimes programmers need to have access to some "closed internal code - called native" for their own use, like the DO grammar rules to parse some of their own user-submitted code. For example I would have liked to create some animated REBOL execution script with breakpoints and word contents visualization capabilities - sort of visual interactive debugger. Don't know where to start with this one and recreating the DO parse rules seems an enormous task that should not be done again if some hook was offered to reuse the work Carl already did. May be it exists but no doc about it! Another project I had to stop was to add some functionality to the original R2 embedded EDITOR to get it reacting to some caret positioning (a bit like Shadwolf did with his Viva-Rebol IDE Project). In the same spirit I also would have liked to develop some semi-automatic GUI testing script-based engine but I can't access neither the Wait-list (events-list) because some insert operation is missing and I don't know how to get the internal format of each event generated by the event-port to simulate it. No indication about how to get a hook and I didn't get enough knowledge/information to go further with these projects - for now! In the same sense but at another level we also need more elaborate examples as mentioned by Nick above (Beginning at the bottom line with some kind of library for common implementation patterns for small day-to-day operations every programmer has to deliver - classified by domains of apps like Carl did with with his own Cookbook, or Nick with his own tutorials and Rebtut with its RebolTutorial.com site. We need some more elaborate well-designed scripts to show how are done both relatively simple and complex tasks involved in day-to-day operations a programmer has to cope with in so many domains (Nick and Rebtut already did a very good job with these: local and remote (ftp) files and directories maintenance, gaming, Images editing, graphics drawing and animation, sound and web creation, etc...), web apps API coupling. But that could be further enhanced/enriched by the addition of some implementation of algorithms that are based on advanced data structures when applied to small real projects (like some of them used by Nick and others that have been put into Rebsites, REBOL.ORG, REBOL Week and REBOL Forces.) There are full of them but not all of them have their design sufficiently well explained to be useful as is - at least for starters - but I no more think that all of those already done should be. If we want to progress, some initiative and study/work must be left... I plan to add some of my own in a short time when studying these algorithms and data structures for my own use. For sure all of this could become a course material for a CS/Programming curriculum but this not our role to get newcomers up there. Everyone has to leverage for himself after a good find-it-yourself help has been put into play. But if we all do a decent job of completing, organising and indexing what is already available, chances are to attract some really interested teachers to use REBOL as their tool for their students first language, and chances are that the wheel will then be started and more and more good programmers will try and keep REBOL for their current programming tasks and collaborate to the adoption of this great mind/tool-set. We are nearer the ultimate goal day after day. If I remember well a lot of effort was already put online for the above mentioned official REBOL websites (.com, .org, .net) plus external ones. Times has come to complete all of this, and put it online, as needed. Keep up the good work, community! I'm slowly joining. My learning curve was particularly steep and I'm far from being fluent with REBOL yet! Thanks to all of you who helped until now.
Maxim Olivier-Adlhoch 6-Oct-2009 20:36:36	My comment is on the very simple side of the universe. Get Nick Antonaccio to build all the official beginner + "attracting people to Rebol" documentation. He's been doing it for years, has the single most impressive REBOL documentation page on the net, including RT's own docs. I mean... one page of rebol code, 10 *usefull!* applications? He's the man!!!!
RobertS 7-Oct-2009 7:59:39	Given that old Rebol books will be available on Abebooks and such, I see a need for a table to correlate R2 to R3 for expressions in those books. This also counts for folks who did some R2 back when and have a script to move to R3. Example: system/options/cgi True, the value of system/options in r3-a87 has no such cgi value but a table which is linked a few times on the web will likely show up in a Google on system/options/cgi I volunteer to do this if Carl thinks it useful.
Steven White 8-Oct-2009 9:26:47	I'm with you on the concept. I have wanted to do a few things in REBOL, most recently getting at some substrings, and I have had to just sit and wonder, how in the world am I supposed to do this in REBOL. In other tools it is totally obvious (not necessarily easy, but obvious), but for some reason I just can't see how to do it in REBOL. It probably is just me. I come from a COBOL background, and Edsger Dijsktra said that the use of COBOL cripples the mind. But for some reason, I find REBOL extremely difficult to understand. When I finally do get a glimpse, I am amazed at how brilliant REBOL is, but those glimpses are hard to come by.
Henrik 9-Oct-2009 11:01:10	Steven, I've found that really learning REBOL should be done from the bottom up. Consider that REBOL is an extremely carefully designed language, which only really reveals itself, by thinking about its design rather than "how to do X". I think most languages are like this, but REBOL is especially hard on you, if you go about it as a traditional language, rather than thinking about the design. In the beginning I was mostly struggling with "how to do X", where I should have been worried more about the basic design of REBOL: Words, bindings, datatypes, contexts, loading, series and copying. From there, you can get to know the functions that are related to creating data and manipulating data. Then you can learn about the side-effects of the design, such as dialects. I don't disagree with the "how to do X" idea as shown above, because they can be quick fixes to get to know bits and scraps of REBOL, but they will never make you an expert.
Eugene Main 17-Dec-2018 5:24:01	I could read a great article today itself. This one is absolutely beautiful. I really love. The author could select an interesting topic to write and he could explain with cute sentences. I really glad to visit here and make a review. The topic is really useful for me. I hope this will be helpful for every reader who visits here. For more, you can visit https://buyessays.us/

Post a Comment:

You can post a comment here. Keep it on-topic.

Updated 1-Jun-2023   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code