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

[REBOL] Re: Newbie Q: Cropping text

From: joel:neely:fedex at: 8-Jul-2002 9:01

Hi, Charles, You've already gotten specific answers from other folks (INDEX?, AT, HEAD, etc...) so please allow me to wax philosophical for a moment or two. Charles wrote:
> For instance, in C, I would have something like int idx; wherein > I could use array[idx]; and move around by increasing and > decreasing the index marker. How can I optically see where 'next > will put me without evaluating it? How can I find out where > REBOL believes itself to be in a series! ? Does REBOL think > it's at the first value, the second, the third, etc? How can I > find out? >
First, a couple of background ideas: - I used to tell my students that (aside from the practical value of getting paid ;-) there is no point in learning another programming language unless it somehow changes the way you think. - My dad, a retired aero-space engineer, was known for asking a question that I've found extremely useful in software design: In order to what? Low-level languages, such as c, lead us to conceptualize what we're doing in terms of the mechanics of doing it. Higher-level languages, such as REBOL, LISP, SQL, ... tend to focus our attention on *what* we're doing, rather than the mechanics of a specific approach. In my own development as a programmer, I found it very liberating -- but initially uncomfortable -- to "let go" of the familiar details and focus on purposes & goals rather than details & mechanisms. Despite over thirty years in programming (during much of which time I've known this principle) I still catch myself from time to time giving too much attention to the mechanics. The application of all that metaphysical musing is this: REBOL gives me several different ways to navigate through the structures that my programs have built up. Choosing which one to use is (for me, at least) usually a matter of thinking about my purposes, and deliberately ignoring everything else. If you'll pardon the simple analogy: - Suppose I'm working in a grocery store, and my manager hands me a box of soup cans with the instruction to put them on a display shelf, I can do that without knowing how many cans there are in the box. I just take the cans, one at a time, and place each can in the "next" available space. - If his instructions were instead to refill the shelf with as many cans as would fit, and then tell him how many cans were required, I can simply add one to a count (starting with zero before the first can) as I place each one, then report the final value of the count. It doesn't matter which end of the box (or the shelf) I start from, nor whether the box had already been opened and partially used. I could go on with more hypotheticals, but my point is that there are many situations where the units (cans) are interchangeable in some sense, so I simply don't need to keep up with any notion of position. total: count: zero foreach item someblock [ if number? item [ total: total + item count: count + 1 ] ] either zero? count [ print "No numbers found" ][ print ["Average of numbers is" total / count ] If the above is evaluated, then the numbers in the remaining portion of SOMEBLOCK will be averaged. "Remaining portion" may be the whole block, or it may be what's left after some other operation. (The box had already been opened and partially used for some other purpose, or -- to switch metaphors -- a search may have been made for the section of the block meeting some criterion.) The point is that unless the concept of position is critical to my current purpose, my thinking will likely benefit from doing away with that concept on my "palatte" of ideas for painting my picture of what I'm doing. To a certain extent I think of this as like writing a sonnet or composing a minimalist typographical design: the elegance seems often to arise from a deliberate choice to work within specific self-imposed constraints.
> Still, I like to know where REBOL is, or thinks it is. >
This one has already been addressed by others, but let me add an extra bit of philosophy: Sometimes (in low-level langugages) we need to keep up with our position in an array because we need to process an element in a context that includes its neighboring values. For example, a simple smoothing algorithm might calculate the average of each value with its immediate neighbors, giving us something like for (i = 1; i < N - 1; ++i) { b[i] = (a[i-1] + a[i] + a[i+1]) / 3.0; } However, if I think about the above bit of code in The Language That Must Not Be Named, I realize that I'm just using the index expressions i-1 i i+1 to encode the idea of neighboring elements. I can do the same thing in REBOL without reference to absolute position, but to relative position just as well, in a variety of ways: b: make block! NN: (length? a) - 2 c: a loop NN [append b (first c) + (second c) + (third c) / 3.0] as one example.
> I like to be able to have some sort of index instantly available > to me like that. >
If that's what you want, it's certainly OK (and already answered by others on the list), but I'd suggest taking some time to think through some common tasks you perform and consdider *whether* and *why* you really *need* some of the ideas you're used to using. I get great fun from discovering ways to do without something that I thought I had to have!
> I'm still going to have to work on this more. I can see very > often where REBOL is easier, particularly for new coders to learn. > But it strikes me that people who've been coding for a while in > languages like C run up against brick walls. ;) >
Learning to think differently takes work and time, but the rewards are definitely there (speaking from personal experience)! -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]