[RSL/UHURU discussion]

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.

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...)

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 $ ./test.pl precedes $ ./testp.r precedes (except that REBOL/View blanked the screen before providing its output).

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-

Am 26.05.01, 01:46:51, schrieb Joel Neely <[joel--neely--fedex--com]> zum Thema [REBOL] Re: [RSL/UHURU discussion]:

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..

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.)

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«?.. ;-)

yes. hm. Are the brackets around $gimme necessary? *brooding* ;-)

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 ;-)

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 :)

Scrolling allready :)

-Volker (who can't snip somehow)

If I understand you correctly, you are opposed to libraries as they dumb down users who could potentially be learning to be better programmers by examining scripts and building from examples rather than using a black box. If so, then that view is shared by some eminent programmers including Charles Moore, the inventor of Forth. This is taken from his annual fireside chat: http://www.ultratechnology.com/fsc2000.htm Now, I would like to address why this is, if this is, and particularly what we can do about it. There was a movie on one of the channels last night, It Conquered the World. (1956) This creature had flying bats that went out and bit people on the back of the neck, this is a very dangerous place the back of the neck, and turned them into slaves. I think it actually bit six people and that's what it means, conquered the world." But nobody realized what was going on with this kind of threat, its insidious. You don't realize that it is a serious "conquer the world" threat. Well it occurred to me that we are subject to that kind of attack. That somehow someone slipped into the software industry and has been taking over the world. And everybody has been going along with it accepting that this is the way things are in software and that forty mega lines of code is needed to do anything interesting." ... One of the things that happened, I guess twenty years ago, was that we had the concept of automatic code generation otherwise known as a compiler. And this did not let anyone write code that could have been written before but it did let less skilled people write code than what people were used to. So we introduced into the profession a very very large number of very very unskilled coders. You hardly can call them programmers. Now this may just not have hurt a little bit it may have destroyed our civilization. The same thing is happening in VLSI design. The silicon compilers are attempting to do the same thing. Let lesser skilled people do what a small pool of experienced expensive people used to do. It isn't cheaper. It isn't better. It's just different. This is what the bureacrats, the executives want. They want industrial scale workforces. Ten times as many people earning one tenth as much. The only justification is redundancy It is certainly easier to manage a large group of dumb people than a small group of smart people. You can't replace the smart people, but you can replace the dumb people. What our culture is doing is trying to do is build a reliable system from a large number of unreliable parts. And to do that you need a large number of unreliable parts. Of course, such opinions haven't help popularize Forth! -- Graham Chiu

Aside from the most interesting things about the transcript, the second most interesting thing was demonstrated by: === Audience: What about Cisco? Their stuff has to be pretty reliable. Moore: I don't know what Cisco does. Audience: They make a lot of routers which basically support the Internet infrastructure. So nobody sees their software Moore: Is it complicated? Audience: I am sure it is. == Wow! No offense meant to Moore (I should be so lucky to have a quarter ("forth";) of his intellect), but this situation reminds me of Dante's Inferno, where the scientists need to have "flappers" continuously flapping them so that they remember to not constantly look up to the skys. The discussion does make some excellent points about learning programming, (re)using code, and about libraries. It also makes some interesting observations that run parallel to the discussions of late. I think my brain is starting to hurt from thinking too much. Think I'll do some painting (rooms, not pictures), mow the lawn, and maybe start hacking webserv or rebserver later today to manage longer posts. Sorry to hear about "the spill"; sounds like an awful mess. --Scott Jones

[quotation snipped]

(Parenthetically, I'll say that the above interpretation is not exactly what I got from Chuck's speech, but that's beside the point here.) The main point I want to hit can be illustrated from another exchange during the fireside chat: Probably the people who care most about the quality of code is ironically Microsoft. They seem to make a corporate effort to write good code. And they fail... Microsoft is judged by the reliability of its operating systems. (What about Cisco? Their stuff has to be pretty reliable.) I don't know what Cisco does. (They make a lot of routers which basically support the Internet infrastructure. So nobody sees their software.) Is it complicated? (I am sure it is.) I think of a router as a very simple thing that takes data in and sends it out. Perhaps it more complicated than that. Now I don't want to sound judgemental here, but one of the things that struck me about the FORTH community from early in my involvement with FORTH (dabbling in late 70's, heavy usage in early 80's) is their insularity. There was an attitude of, "If it's not FORTH, it's crap!" that extended to *everything* including operating systems, utilities, editors, etc. This was often perceived in the non-FORTH world as a very elitist attitude: We have a superior language that lets us be more productive with less resources than you. You're welcome to join us, but you'll have to throw away or rewrite all of your existing code and tools, because we won't interoperate with that junk. Two specific examples: 1) There was a real debate over whether to have support for floating-point numbers in FORTH. Chuck had decided that for most computations one could use integers, and just scale the results up or down. 2) There was bitter debate over whether to allow people to use other text editors and operating system files for FORTH source code, or whether to stay with the requirement of FORTH-managed disk space (in 1k "blocks") and a FORTH-only 1k-at-a-time block editor as the only way to write code. The REBOL language certainly doesn't have some of the myopic constraints of the FORTH language, and RT is certainly reaching out to the larger world with the ability of REBOL/Command to interact with other software. So it's up to us as the REBOL community to be flexible and open to ideas from other folks, even if they're not "pure REBOL". Bottom line: regardless of what I think of either FORTH or Perl as a programming notation, I much prefer the Perl community attitude of "Everybody's welcome; there's more than one way to do it." I'd rather REBOL have the acceptance and respect of Perl than to eke out a marginal existence in the "splendid isolation" of FORTH. -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

Am 26.05.01, 08:15:42, schrieb "Graham Chiu" <[gchiu--compkarori--co--nz]> zum Thema [REBOL] Re: [RSL/UHURU discussion]:

No, wrong. I like libraries. But: Blackbox-libraries have some disadvantages about whitebox-libraries. One is, i have to press my wishes through the api. This is a good way if i have to deal with tons of code. But the smaller the code, the more easy it is to change the code compared to pressing through api. And rebol-code is very small.. So customisation compares well to parametrisation. Maybe, let us compare unix-find with rebol. (except rebol can't detect file-links afaik) Unix-find is very strong. But it is not stronger for me than rebol if i have the basics of a subdir-walker. I would have patched it faster for my patterns than finding again these specialities in the man-page. Easy done with going to the part where a new file is handled and inserting some ifs and [x < size? F] and [parse read file[thru »hello« to »world«]] if i had a blackbox instead, i would need a lot of options which would make usage very similar to unix-find: read the manual, learn the options, and - well, why? The blackbox would consist of 20% subdir-walker and 80% [if option]'s. The whitebox could be 5 times smaller. Wasn't there a rule complexity grows »some bad factor« with the size? So i want to have flexible changeable scripts as a base. Contrary The standard library discussion here focuses a lot on definitive places, versioning, fixed apis, magic updates and so on. That will break my patched scripts of course. So i have to decide to go through api for the library (with 80% option-handling) or to change prototype-scripts of 1/5 the size. exxagerating? [help find] (native) shows me 10 options because i can't simply put my check at the right place. And thats only a little find, think what would be needed for a real find/deep .. then look at some 3-liner loops shown the last time for finding stuff in sub-blocks.. 3 lines to 3 + 1/option = 13 .. ok, i choosed an example which favors my point.. ;-) Additionally updates give compatibility problems which aren't really solved AFAIK. Staying backward-compatible is a nice art with a lot effort and self-restriction IMHO simple copying current script will work as good as this frees the developers do what they want for real improvements and give users more flexibility/customisation. As long as scripts are short, many stuff is short living (scripts after all) and there are good instruments to compare new versions to the original and patched versions for scripts that live long enough to incorporate librarie-updates. That means, we need a good diff and a smart searcher and »cross-referencer« in rebol to track changes, instead of smart dependency-tracking around the world. And a good library of course. But off customize-friendly prototypes. Like the old rebol.org - style. With a bit more support for the very small snippets somehow. Not of clever organised »everywhere exactly the same automatic« blackboxes. Except of the carefully designed rebol-exe of course. one update-target to track, and it changes seldom, after lots of discussions. Gives the freedom to mutate on top of that wildly :)

<snipped Charles a bit(sorry, Chuck :)>

You are citing really chuck here, yes? Sounds like LDC and Carl talking how short and flexible rebol (again) makes code ;-) (well, i snipped chucks rambling:)

Chuck must be joking here? He wrote lots of compilers. and i heard he can fly with his vlsi-cad through the chip in realtime 3D, dropping transitors on the way? :) *brooding*

-Volker

I don't think of this as being an elist attitude that was causing this debate. The underlying debate to the above was not whether files were better/worse then blocks, but by using files, one would lose the discipline involved in writing small "words".

Again, I don't see this as a language constraint, but one of a programming philosophy.

And my take is that you can write Rebol as Forth if you so chose to, where Forth is not the language but the philosophy. -- Graham Chiu