Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: [RSL/UHURU discussion]

From: joel:neely:fedex at: 25-May-2001 19:46

Hi, again, Volker, Thanks for your interesting and stimulating remarks! I'll try not to be overly verbose... I think that one theme that keeps emerging is the differing needs/purposes that different people may have. The student of REBOL needs material to play with, and needs to try things as part of understanding what's going on. The exploratory programmer who is experimenting with new ideas *definitely* needs that try-out and play-around time. But the typical working stiff (production programmer who needs a quick data conversion/reformatting script, webmaster who needs a new CGI or form-data-handling script, researcher who just needs to slurp up some data and crank out a summary report and some statistics, etc...) can benefit *greatly* from a large collection of off-the-shelf doorknobs, curtain rods, and picture hangers. Since I spend some amount of time in each of these three modes of operation, I'm looking for solutions that allow me to do the right thing in each circumstance. Given the choice of snapping together some standard components, customizing some available code samples, or building a hand- crafted, optimized solution from scratch, I'm often looking at something like this: Option Build time Run time Total time ---------- ---------- -------- ---------- Standard 5 mins. 5 mins. 10 mins. Customized 15 mins. 1 min. 16 mins. Optimized 45 mins. 15 secs. 45.25 mins. (Obviously these are only examples.) It's very often the case that the first option is the win. In fact, a good overall strategy is to assume that EVERY task can be handled that way, then proceed to customize or optimize only when the program is run so often that the tradeoff flips. Enough soliloquy from me! Responses to your comments are below. -jn- Volker Nitsch wrote:
> ... IIRC carl said something > before going productive in smalltalk one has to learn all > the collections and how they work together. > This compared to similar powerful series. >
My (limited) experience with Smalltalk is consistent with my more extensive experience with other languages (including REBOL). It's possible to start getting real results fairly quickly, but true mastery and making best use of all the capabilities/libraries/classes comes over time. To use your example of the REBOL series, there are often subtleties or efficiencies that remain to surprise even an experienced programmer.
> > FWIW, I see REBOL as lying closer to the "sparse" end of > > that spectrum than the "rich" end. > > hm. >
In case I wasn't clear (the "hm" made me wonder), the rules of REBOL syntax are smaller than any language I can think of except for LISP and FORTH. In fact, all there is to REBOL syntax is the rules for writing literal values (strings of both flavors, numbers of various types, URLs, etc... words, and blocks). All the rest of learning REBOL is about the behavior of the predefined words that are there once the interpreter has started. (However, some of those are VERY subtle...)
> > In *ANY CASE* one may need to learn something. > > parse string [thru »this« copy gimme to »that«] > is usefull. »How are the dotsused in RE? Ups.« >
Your example of PARSE in REBOL can be written in Perl as ($gimme) = ($string =~ /this(.*)that/); To provide a complete working example in each language: 8<------------------------------------------------------------ #!/usr/local/bin/rebol REBOL [] string: "I think that this precedes that in this string." parse string [thru "this" copy gimme to "that"] print gimme 8<------------------------------------------------------------ #!/usr/bin/perl -w $string = "I think that this precedes that in this string."; ($gimme) = ($string =~ /this(.*)that/); print $gimme, "\n"; 8<------------------------------------------------------------ In the second Perl line, the =~ tries to match the variable to its left against the regular expression to the right (which is delimited with slashes). Inside the regular expression: - the literal words are just what they seem; - the dot matches any single character; - the star says "any number of times", and ; - the parentheses mean "remember what matched here". A successful match on the right side stores the result in the variable ($gimme) on the left side. So, from the command line, we can run them both to get $ ./ precedes $ ./testp.r precedes (except that REBOL/View blanked the screen before providing its output).
> »perl? Arg? No, never understand! - rebol? Ups, i write a > script i use?!« >
Perl is certainly as unorthodox a language as REBOL (but each in its own unique way). My first significant Perl script was an interactive tool to help me port the content of a large directory structure from one Unix box to another, reorganizing and pruning as I went. My first significant REBOL script was a web-server stress tester that simulated a browser and kept response-time statistics for page requests. In both cases, I had little advance warning, and chose to risk jumping into an unfamiliar language because it appeared to have the right features for the task at hand. In both cases, I suceeded "well enough" to get the job done and to decide to keep using the language. In both cases, I have continued to learn more about the language, its style and usage, and its strengths and weaknesses. IMHO, both are good tools, but not necessarily for the same reasons or for the same tasks. I think this post is long enough, so I'll address some more of your comments in a separate note. -jn-