Is Computer Science really a must to understand deeper use of Rebol?
I am refering to piece of code from 'Rebol a Programmer's Guide:
exec-cmd: func [
cmd [ block! ] 'Rebol Instructions'
/local err
] [ if error? err: try [ do cmd ] [ print mold disarm err ] ]
Explanation in book:
This function takes a block containing Rebol code as its parameter and defines a local variable called err. This is used to gather error objects intercepted by the try word. The Rebol instructions are executed by using do which evaluates a block of code.
I follow the explanation, but I get the feeling that it will take many years to assemble code like this.
I need to know what background experience one needs to increase my level of knowledge/ expertise; don't want to battle endlessly. Please note, I am motivated, but I need some guidance. How long did it take you to get to a comfortable level (use), and briefly explain the difficulties you encountered along the road?
By the way, I briefly glanced at Rebol back in 1999. I remember my thought pattern: 'It can't be that easy to code a GUI? etc. This is a toy. Wished I put in some serious time. Thanks for all the response.
posted by: Danie 8-Dec-2015/12:55:44-8:00
I never took Computer Science classes of any kind, so I'm a dilettante. I discovered REBOL around 1997, during its earliest releases. I was (and remain) terrible at understanding the inner-workings of REBOL, to my disappointment because at the time I hoped to write better user docs for the language. I kept using rebol because it's flat-out easier to learn and use than other languages I've encountered.
Over the last 15+ years, I've been a (non-IT) web commerce manager. This means I'm in charge of managing web sites and their design, including content strategy and web publishing operations for large corporations.
In my "non-technical" area, our global teams need to be able to manage, manipulate and generate reports for tens of thousands of web pages, XML content records, search engine data logs, generate metadata/sitemap.xml's and to test web-services/SOA for hundreds of web and mobile sites.
I personally do lots of tasks that IT developers in large, bureaucratic companies can't do or won't do, because they live-and breathe J2EE but struggle to do quick-and-dirty scripts. Note that these devs are trained, professional-level career "computer science" programmers, and I'm a neophyte. I'm only able to do what I do because of rebol. (And if I had to write middle-ware code in Java, of course they'd run circles around me.)
Using rebol, I've rolled out tools/utilities (.exe's) which load scripts from our internal library (sitting on an internal webserver). This lets our content managers around the globe have the ability to generate reports, validate assets and link/code references, and to manipulate site personalization rules for their audiences & locales.
So I use rebol as a practical choice-- because the productivity gains and immediacy far outweigh the alternatives. I can usually get something accomplished in rebol in less time than it would take me to describe a request to IT or a vendor.
Back to your question. I think a lot of what I wrote above maybe sounds fancy, but my scripts still seem very novice-level when I compare them to the more elegant code I read from the masters in the rebol community. However I don't let it bother me-- my scripts function well for my needs. The key was that I stuck with rebol, improved my ability to script and found a niche that allows me to make a difference in my career.
I mentioned earlier that I suck at understanding rebol. In terms of "deep understanding" I still suck at it. Despite this I am satisfied with what I've been able to accomplish with rebol, and I feel that it has become indespensible to my work. If I had been in a different career or niche, I doubt I'd have any use for rebol other than for toying around.
I have provided some light training to most of the people on my team, and the more tech-savvy ones have taken to rebol slowly over the course of a year. I think that there's a virtuous cycle to scripting where you learn how to do a few simple things, which allows you to improve the range and versatility of what you can achieve, which in turn allows you to extend/deepen your expertise. In my case, I had known the basics for years, but once I grokked how to easily scan & filter folders and directories (see: http://www.rebol.com/docs/quick-start5.html), it opened up a world of things that I could apply immediately in my career. From there, I worked at learning parse, and that became the next key step (Bo shared a tutorial in this forum. I have trouble recommending any single piece of documentation which is essential.). Lastly, building a halfway-decent GUI became a way to tie everything together so I could allow other members of my team to use and extend the scripts I've written. Maybe the next level will be to write an android app using rebol, we'll see.
If you goal is to use rebol for scripting, I recommend looking for tasks in your work/life which are tedious or highly repetitive and see if you can use rebol to automate some or all of it. I think it all comes down to whether or not rebol is the right fit for your specific needs and your work environment. Good luck!
posted by: Edoc 8-Dec-2015/18:50:19-8:00
I don't think Rebol is any more difficult to learn than any other language. It does have a fair degree of consistency, I think once you grasp why certain things work the way they do, then it becomes rather easier to master.
I'd certainly recommend looking at series functions first--there you get an idea not only of how to manipulate blocks and strings, but also how most Rebol functions have useful return values: INSERT, CHANGE, BACK, NEXT, SKIP, HEAD, TAIL, INDEX?, HEAD?, TAIL?, etc. Certainly learning this went a long way for me in figuring Rebol out:
https://medium.com/@rgchris/understanding-rebol-series-d5d6f597a239
Also worth a wee read:
http://blog.hostilefork.com/why-rebol-red-parse-cool/
With regard to your example, there are a few areas to watch for.
- Errors are just another value in Rebol, albeit ones that when evaluated halt the evaluator (this behaviour is slightly different in Rebol 3). You can however 'catch' them by using a function that takes them as an argument, such as ERROR? (or any type checking function).
- Not sure why the author went with TRY [DO CMD] instead of simply TRY CMD
- DISARM turns an error into an object. This is useful if you want to evaluate an error instead of having it bomb.
- PRINT returns an unset value. unsets are tricky to handle--you can't simply set a word to an unset: FOO: () thus I'd be careful with that EXEC-CMD function that it might not be friendly.
posted by: Chris 8-Dec-2015/19:08:35-8:00
You don't need any formal background in computer science to use Rebol well. The example you presented, as with almost any other Rebol example you'll find, just requires more of an understanding of Rebol's ways of doing things (as opposed to other prior experience). Most of the basic thought patterns which are used in other software development tools are all used in Rebol. You'll need to learn to represent and manipulate data using variables, loop through lists of values and perform actions based on conditional evaluations, optimize code to run efficiently, etc. Those things don't require any prior training - just some clear explanation and lots of repetitive exposure to the same sorts of code patterns.
One of the great things about Rebol is that you can perform all sorts of useful tasks really easily, and with short bits of code. The text at http://re-bol.com/rebol_quick_start.html covers everything you need to know to build 20+ example apps, in about 55 pages. You don't need any former experience with Rebol, or with any other language, or with any other computer science topics. That text covers all the basics of Rebol, and then goes though each of the many examples in line-by-line (sometimes character-by-character) detail.
When you're done with that text, take at look at http://re-bol.com/short_rebol_examples.r and the video which displays most of those examples at https://youtu.be/lR5Fzv6DP0I . Just run each example and read through the code. There are more than 70 example apps at that link, and many of them are only 5-10 lines long. Also take a look at http://re-bol.com/examples.txt - there are many duplicate examples there, but plenty more to just read through. Read each line of as many of those examples as possible, and see which bits of code and logic make intuitive sense. If you start with the quick start text first, much of what you'll see in those examples should be perfectly understandable.
After that, when you've got some understanding of, and familiarity with, the most basic code patterns used in Rebol, read http://business-programming.com . That will take you through all of the basics again, but in much greater detail, and with far deeper explanations, and it will continue on through just about every useful topic and technique which is common in Rebol. There are more than 100 complete apps in that text - many longer ones - all with detailed explanations, and much more than just basic concepts demonstrated in practical use. If you read through all of that code, the detailed explanations, and the code comments, you should come away with a *very strong understanding of how to accomplish a huge variety of goals in Rebol. The first part of that text covers all the various capabilities of the Rebol language, as well as how they are combined to create a wide variety of example apps. The second part is about learning how to think about assembling those capabilities - learning to think about organizing the structure of applications from scratch, and how to "think in code", using all the tools and ideas learned in the first part. And in each section of that text, there are hundreds of links to other supporting documentation and third party examples. If you read all those pieces too, you should be able to thoroughly master everything you could possibly need to know about Rebol.
That should take you through everything in a nice progressive way, and all in about 1000 pages, with a clear path to other supporting docs where desired. You'd likely need to read 10s of thousands of pages to get that far using just about any other development tool.
posted by: Nick 8-Dec-2015/21:45:58-8:00
The code you ask about is, in developer terms, not that computer-sciencey.
I have done similar things in assembler -- ie pass the "safe execute" subroutine the address of target subroutine and the address list of the args.
"Safe execute" then runs the targt subroutine, but first wraps it in a STXIT macro (I'm an old mainframe dinosaur -- Windows and Linux will have something similar. If the subroutine fails, the STXIT gets control and can pass the failure information back to the caller.
That's all the Rebol example is doing. It is something I do in most of my Rebol apps -- that was, we don't drop to a Rebol console if something fails; we show the user a nice apologetic message, dump a load of stuff to a log file for later analysis, and perhaps send me an email so I know my code is buggy.
So not computer science so much as good development practice. Not something you need to do in a personal app, but useful for anything that gets deployed more widely.
posted by: Sunanda 9-Dec-2015/3:25:05-8:00
I might be in a position to offer some comments. If I were writing a resume, I would say I am a professional programmer/analyst with 42 years of experience. But really, I am professional only in that I get paid, and my experience could be called one year of experience repeated 42 times. So I know how to analyze my way through a problem and write a program, but I don’t have a lot of experience outside a narrow area.
I think that if you have the ability to analyze your way through a problem and describe logically a solution, you have what it takes. After that you have to figure out how to work with the available tools to make the solution. There might be a lot of computer science genius behind REBOL, considering who wrote it, but you don’t have to know that to use it. In fact, Carl himself might say the same thing since he wrote a blog post (which I can’t find) about simplicity being “clean abstraction and clear expression” (or something like that). If you can “black-box” out any thoughts about what goes on behind the scenes and just use what REBOL offers, you can make it work.
When I first saw REBOL I had a terrible time understanding it. I now have some ideas why. In other languages there are declarations, keywords, and so on, and often they are computer-ese words like “data” and “file.” Also there is punctuation which can provide clues about what is going on, like what is a function (things in parentheses), what code statements go together (the curly braces for example), where a statement ends (a period or semicolon). In the REBOL samples, all you have is a blast of lower-case words with no punctuation and lots of words that sound like meaningful language keywords (like “data” and “file”). Also confusing was the concept of a function “returning” something when that something could be a complex thing, like an object or an error or a block. I thought of a function returning something simple, like a number. If you can avoid looking for similarities with other languages and just accept what REBOL offers, which is punctuation-less function calls evaluated in left-to-right order, that can help. What I do as a visual aid is code all the words, that I create, in upper case, and often make them multi-part words with hyphens (like INPUT-FILE), and then leave all the REBOL function words in lower case. Real REBOL programmers might vomit, but it helps me a lot and has become second nature.
In unix, as I understand it, they have this idea that everything is treated like a stream of characters. Files, console input/output, all streams of bytes. With that model, you can use all sorts of text tools to pipe stuff around and work on it. Many data processing applications involve “one thing after another,” like strings of characters, files of records. The REBOL model for “one thing after another” is the series. I think (but don’t know) that Carl tried to apply the series model to all instances of “one thing after another” so that one set of functions (all the series-related functions) could work with all cases of “one thing after another.” So, as mentioned above, absorb all the series functions.
I started to try to use REBOL at its very beginning, and I hate to say that it took YEARS to become comfortable using it. But I think that part of the problem was that one can be hindered by what one does not know (by way of background) and what one does know (by way of expectations of how things should work). Remember also that a goal of REBOL was to make simple things easy and complicated things possible. That doesn’t mean that complicated things are easy. If you want to do something and can’t figure out how to make REBOL do it, maybe that’s because it can’t be done. Don’t expect to be able to do something and then think you are incompetent if you can’t figure out how. If you happen to know the COBOL language, you might find some guidance at a web site called www.cobolrebol.com. If you don’t know COBOL, most of what is there will be meaningless, like an English speaker trying to learn Latin from a Latin-to-Italian dictionary.
When I look at scripts by Carl, which ought to be “the REBOL as she should be written,” I find them hard to follow. Carl “complained” once (in a blog post) about people using REBOL like other languages. I personally don’t think it a bad thing to take a plodding approach to writing REBOL code. If you can write code that is NOT as terse as a master’s, that is NOT as compact, that does NOT take advantage of some of the clever features, but that you CAN understand and that works, that is not a bad thing. Plod along, document any programs you write, save and organize everything you write for future modification and re-use.
I tried to write down some of the big things that held me back from learning REBOL, and I am happy to say that after many years I am starting to forget them.
posted by: Steven White 11-Dec-2015/12:45:59-8:00
Steven: is this the article?
http://www.rebol.com/article/0509.html
posted by: Chris 13-Dec-2015/10:47:15-8:00
Yes, thank you, the very one. I had the "clean" and "clear" reversed, although "clean" abstraction makes more sense to me personally, as does "clear" expression.
And another thought, in this article: http://www.cobolrebol.com/pages/miscellaneous/back.to.prsnl.cmptng.html
Carl laments the state of software complexity (even in the last century) and makes the comment that in the "good old days" if one had a computer problem one might be able to fix it oneself. That implies to me that he would not expect a person to need a computer science degree to use a computer, and that he would not create a language requiring that either. I think his goal was to hide the complexity under a clean, or clear, layer of abstraction so that we could his language with clear, or clean, expressions.
Not to make this sound like a "cult of Carl."
posted by: Steven White 13-Dec-2015/13:00:03-8:00
Thanks to all those that responded to the question as I feel the same way. I do understand some of it but some of the more terse programs befuddle me. Not to kiss up too much but I like the way Nick explains things. He seems to build up so that it becomes less like the old cartoon of the physics teacher who has a board full of equations that in the middle says,"here a miracle occurs".
posted by: Sam 16-Dec-2015/1:53:04-8:00
No, you just start by describing the problem you want to solve and you end up with some code. On the way you will learn.
Even today someone posted a link to an old blog post by Carl https://people.apache.org/~jim/NewArchitect/webtech/1999/09/junk/ that showed me some things I perhaps already knew but reminded me of other ways to do things using Rebol.
Best advice is 'just do it' and good luck.
posted by: iArnold 26-Dec-2015/16:38:54-8:00
I was going through some old article clippings I'd collected about rebol and found that one and decided to post to the sub-Reddit for rebol. https://www.reddit.com/r/rebol/
What struck me about that particular article is that Carl's approach to some common parses-- the kind I do all the time-- was slightly different than the way I implement them. The article also lightly covers dialects.
In my opinion, apart from all of the great & convenient stuff that rebol provides as a basic scripting language, parse & dialects are two vital topics which are woefully under-documented.
FYI, Oliver Auverlot's Rebol ("Programmers Guide") book touches on dialects briefly as well and is worth a read. You can find a free English translation with a simple Google search.
posted by: Edoc 28-Dec-2015/12:19:44-8:00
|