[REBOL] Re: [RSL/UHURU discussion]
From: agem:crosswinds at: 26-May-2001 6:46
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 26.05.01, 01:46:51, schrieb Joel Neely <[joel--neely--fedex--com]> zum
Thema [REBOL] Re: [RSL/UHURU discussion]:
> Hi, again, Volker,
> Thanks for your interesting and stimulating remarks! I'll
> try not to be overly verbose...
> 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.
Yes. But - iam looking at my upload-script here - oops, really
to dirty to show..
Somewhere in it are - ? - oh, here -
are 30 lines (½ empty/log)which copy the files to the server.
There is a dir where i put the uploaded files and a dir
where the uploaded files are copied, and before upload
files are checked by content, uploaded only when changed.
Well, this part needed development-time comperable to explaining it
here.
The rest - um.
There is a large part which collect files and copies it into the
upload-dir, in varous ways, including running make-spec over them,
replacing directory-names, and so on.
Also, of couse, there are my pathes.
All hardwired into one script, together with copying some
helper-scripts.
Well, its hard to think how to keep the collection-part
shorter than using native rebol.
Or how later added features are of great benefit.
(write/binary join %upload/ file read/binary file).
And its hard to see why a [do-uhuru %uploader-0815.r] for the 30
lines.
is favorable about looking in an example and copy the source.
So if i ever polish it, i would write
files: copy[]
;---please fill in what you would need,
;---for example (write/binary join %upload/ file read/binary file)
ftp-dir: ftp://a-good-url-demo
..
[30 lines for the upload lib]
and the user would customize it, add some debug-statement
to check dirs maybe, run it 3 times and after that forget about it,
except of having an icon on desktop and knowing how to edit
for new files.
hm. automatic index-creation would be nice. Thats -
ah yes, %make-index.r, the tools folder.
i have to throw out the file-requester-stuff.
And maybe i should mark the file-list with some
[%script.r index %xyp.html ..] and
[either word? File[append-index file/-1][copy-to-upload-dir file]]
in the upload-code? Ah!
And that would be hard to insert with »standard«-apis IMHO.
And i have more flexibility for the file-selection,
as flexible as programming can be.
hm. the script is larger. Now i split it in a lib part
and my file-collector with a do %upload-stuff.r before.
But - how to place that in the public library?
Naming-conventions, %upload-stuff-994a-modified-by-volker.r?
Or kill pathwords, cean a bit, zip it and push it to »the library«,
where others may find it by a fulltext-search for upload,
among a lot other scripts?
Making a special dir, unzipping, gallop through script, edit and use?
30-50 lines..
> Enough soliloquy from me! Responses to your comments are
> below.
> -jn-
<snip>
> >
> > > 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...)
yes. I meant this subtle. Stuff often works similar, but not
exactly equal in much cases.
This makes scripting quicker because if you want [first block]
without empty-error you can choose [pick block 1] and so on,
and some functions try to be clever with certain types,
like executing them. other functions with others.
Personally i like (and use) it.
Its so good choosen, i have often the impression rebol
can read mind, but if an average designer like me
includes similar exceptions.. it goes pretty confusing :)
it is complex semantic.
(ok, the first time i touch these exeptions,
i sometimes report bugs, but then ;-)
(rebol has the advantage everything new gets quick some samples
hacked into the console, so the exceptions occur mostly early.)
> >
> > > 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/);
Aarg! Don't mention that. After some time i really liked
what i can do with this
(prettyprinting java with one line/type of statement :)
but i had often to look into the camel-book for the chars
(it learned quick to open on that pages ;-)
And this »=~« symbol, i even today have to translate it to
»apply the pattern to the string and return the match«
i can absorb »thru«-parse much better. (well, hm, »absorb«?.. ;-)
> 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";
yes. hm. Are the brackets around $gimme necessary? *brooding* ;-)
> 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.
Well, yes, this newbies have time-tables similar to you,
except they have:
Option learn time use time Total time
---------- ---------- -------- ----------
Mouse 5 mins. 10 * 0.5 mins. 10 mins.
Programming .......................
;-)
parse string [thru "this" copy gimme to "that"]
means »take the 'string, run thru the first »this«,
start copying into 'gimme, run copying to the first »that« (from
there),
stop copying, done.
Perls actions i would explain similar to you.
And loosing the one or other newbie thinking programming is
complicated.
while the rebols stay because they expect the rest is that easy too
;-)
> So, from the command line, we can run them both to get
> $ ./test.pl
> 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.
Yups. With my english - well i do not mean this ironic.
I think you are well skilled, specially with digging into,
finding the right points and experimenting.
But i think rebol has to fight the mouse offering more power
for frequently tasks and being interesting as »hobby«.
So it has to keep »simple things simple« for mousers
with limited time/interest.
If it succeeds, these people will prefer to look at scripts
instead of black boxes, because this boxes are highly
abstract things which can't be touched, only documented.
They need high levels of dicipline for both developers
and users.
But if users expect this %webserv.r has somewhere a part
where it decides
how to handle which extensions, and yes, there is a block
with stuff like
%.html »mime/html« ..
they are smart enough to extend the script IMHO.
If they have to lookup the right config-file for apache
and understand it in all that every possibility configure - stuff,
they may get lost.
And even %script-config.r - loading can be the largest part
of a usefull script sometimes..
Rebol can embed configuration very easy inside the script
- if you copy the script.
Hm, again, what do i try to tell? And am i right? And..?
but fun writing :)
> I think this post is long enough, so I'll address some more of
> your comments in a separate note.
Scrolling allready :)
> -jn-
-Volker
(who can't snip somehow)
