[REBOL] worse is better?
Here's a very intriguing article about programming languages called "Worse Is Better" that was originally published back in 1991 and compares the Lisp approach with the approach that brought us C and UNIX. Very interesting, IMHO, to see where REBOL might fit in to this theory. Any article that made such an accurate prediction of the future as this: "The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++." deserves to be (re-)read. :) Nearly 10 years later, how have we progressed.. or have we progressed? Enjoy! http://naggum.no/worse-is-better.html -Jake
[REBOL] no networking in experimental BeOS REBOL?
Hi, On my PC running BeOS 5.0.1 Pro Edition, I can't get any of REBOL's networking features to work, with either REBOL/core 2.4.24.5.2 or REBOL /view 0.10.18.5.2. For example: REBOL/View 0.10.18.5.2 28-Jul-2000 Copyright 2000 REBOL Technologies. All rights reserved. Type DEMO to run demo if it is disabled >> read http://anobject.com/ (30 second pause) ** Access Error: Cannot connect to anobject.com. ** Where: read http://anobject.com/ I have BONE Beta 4 installed, but I had the some problem before I installed BONE. Fortunately, the released REBOL/Core 2.3.0.5.2 works properly. Any idea when this will be fixed? Thanks.. -Jake
[REBOL] Cool gels. Great demo. Re:
> Had to take a quick break from the docs to regain sanity, so wrote this insanely fun demo script that I thought you might enjoy. Cool! (and very inspirational!) It's so easy for me to forget that so much cool stuff can be done with so little code when you have the right language and infrastructure behind you. I remember watching Benoit @ Be write some fun little demos in as little as 20 lines of C++ code for BeOS, and I thought that was amazing at the time, but in a coding shootout against Carl and REBOL, I know who I'd place my bets on! :-) No offense, Benoit, if you ever find this message in the list archive, you're still a coding god but C++ vs. REBOL I think would prove too big of a handicap for you! :-) Speaking of coding shootouts, you know why the ACM Collegiate Programming Contest (www.acm.org/contest) only allows C, C++, Pascal, and (in the finals only, due to Microsoft sponsorship) Visual Basic, and not languages like Perl? Because, it's common knowledge that in schoolwide competitions (often held by universities to choose the students to represent the school at the ACM competition), whenever the judges have allowed languages like Perl, the students who use it tend to win by huge margins (in other words have an "unfair advantage") over the students struggling with C/C++. When you're trying to solve six non-trival problems in five hours, struggling with printf() and strtok() (or iostreams) is *not* want you want to be doing! :) And REBOL should be even *better* at this than Perl, right? If only it had been around when I was in college.. because I never really liked Perl, ya know, and I was tired of always coming in second at the local contest to the resident Perl god.. ;) -Jake
[REBOL] Is é a valid char for use in urls? Re:(2)
[EMAIL PROTECTED] wrote: > An unescaped é is not valid in URLs, it should be encoded as %E9 > http://www.melbourne.net/antonr/résumé.html fails for me in IE5.5, but works > in NT4.7 > http://www.melbourne.net/antonr/r%E9sum%E9.html works in both. > > More details can be found in RFCs 1738 and 2396. > > In REBOL, (at least in REBOL/View 0.9.8.3.1) you must prevent the %E9 > encoding from being decoded too soon. A literal %E9 in a URL gets decoded > into é immediately; therefore in literal URLs you must escape the % by using > %25, or hide the url inside a string. > read http://www.melbourne.net/antonr/r%E9sum%E9.html doesn't work, but > read to-url "http://www.melbourne.net/antonr/r%E9sum%E9.html" does, and so > does > read http://www.melbourne.net/antonr/r%25E9sum%25E9.html. This looks pretty ugly to me. While it's nice to know that there's a workaround, IMHO REBOL should be taking care of this automatically when requesting URL's with special characters. Would someone like to file this as a bug report? -Jake
[REBOL] Rebol's argument handling is broken Re:(4)
[EMAIL PROTECTED] wrote: > Grep works similarly as REBOL currently does, considering > arguments preceded by - to be switches regardless of where > they are placed. For example: > > Before and after args: > > grep -A 3 foo * -vi > > In between and after args: > > grep foo -B 10 *.txt -A 20 Interesting.. But grep isn't a language interpreter, and that makes *all* the difference! :) -Jake
[REBOL] large-scale REBOL coding? Re:
[EMAIL PROTECTED] wrote: > Wow, that makes my REBOL program look puny. A mere 7242 lines (including > comments). And I was feeling so proud of it. Wh! You wrote a 7000 line REBOL program? That's pretty cool.. I'd love to take a look at that, is it publically available? What does your program do? Did you find any problems with using REBOL for a task like that? How did you split the source code up? Inquiring minds want to know. :) -Jake
[REBOL] Re: where are all the components?
Thanks to everyone who replied to my post on this topic, especially Gary and Brett! I hope to find time to think about this a little more and maybe type up a few more thoughts, but in the meantime, I got an interesting message from Marcel Weiher on the MacOS X mailing list today with some quotes from Alan Kay that I wanted to share (I didn't forward the whole message because I didn't get a chance to ask Marcel if he would mind.. I know the post was in a public forum but I don't want to be impolite). The comments on messaging being even more important than objects gives me hope that REBOL truly is exploring a better path! Original Message "Simula to OOP is moving to new things. Simula to ADT (Abstract Data Types: C++, Mesa, Ada) is moving on to better old things." "Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to hit computing since MS-DOS." "If you think programming is a small thing, that's why your programs are so large." "There is nothing more inefficient than 10 years development on an OS that never runs. (Reference to the Apple "Pink" OS project.)" All from Alan Kay's OOPSLA 97 talk. http://www.cc.gatech.edu/fac/mark.guzdial/squeak/oopsla.html Here is a longer message by Alan on the Squeak mailing list: Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word -- ma -- for "that which is in between" -- perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas. If you focus on just messaging -- and realize that a good metasystem can late bind the various 2nd level architectures used in objects -- then much of the language-, UI-, and OS based discussions on this thread are really quite moot. This was why I complained at the last OOPSLA that -- whereas at PARC we changed Smalltalk constantly, treating it always as a work in progress -- when ST hit the larger world, it was pretty much taken as "something just to be learned", as though it were Pascal or Algol. Smalltalk-80 never really was mutated into the next better versions of OOP. Given the current low state of programming in general, I think this is a real mistake. I think I recall also pointing out that it is vitally important not just to have a complete metasystem, but to have fences that help guard the crossing of metaboundaries. One of the simplest of these was one of the motivations for my original excursions in the late sixties: the realization that assignments are a metalevel change from functions, and therefore should not be dealt with at the same level -- this was one of the motivations to encapsulate these kinds of state changes, and not let them be done willy nilly. I would say that a system that allowed other metathings to be done in the ordinary course of programming (like changing what inheritance means, or what is an instance) is a bad design. (I believe that systems should allow these things, but the design should be such that there are clear fences that have to be crossed when serious extensions are made.)
[REBOL] where are all the components? Re:
Oops, my apologies for the awful line-wrapping on that last message. I originally wrote it in pine, which wrapped it to 78 columns, and when I resent it in Netscape, it chopped it down to 72 columns leaving all those trailing words... :-( -Jake
[REBOL] large-scale REBOL coding?
Hi all, Here's something I've been thinking about since talking to a friend about REBOL and its prospects. He said that just about any scripting language can handle scripts of a few hundred lines, but the real challenge for REBOL will be in whether or not it can handle large-scale programs as well as, for example, Python. Take Zope (www.zope.org), for instance, a Web application server written in Python (with a few native modules). I just downloaded the latest version and ran a quick line count on all the .py files: 83165 lines, plus another 10391 lines for the ZServer HTTP server! That includes comments, but still I'm very impressed that the language can scale up to handle a project of this size. One project I'd like to work on once I'm finished with my current programming contract job would be to look through the source code to Zope and figure out how feasible it would be to do something of that size with REBOL. Correct me if I'm wrong, but it seems that one big limitation of REBOL currently is the lack of solid module support. DO'ing subsidiary scripts doesn't seem like the right approach, especially compared to Python's powerful import facility. I know there are some third-party module managers available (which to be honest, I haven't had time to investigate), but this seems like the type of thing that needs to be built into the language. I would assume that RT is aware of this, and hopefully working on a solution, but are there any other areas where REBOL is currently lacking? I don't want REBOL to be only useful for quick hacks!! -Jake
[REBOL] where are all the components?
Hi all, Here's a longish rant I originally sent to some friends this weekend about where I see REBOL having a lot of promise in "the big picture." I'm sure I'm not saying anything that RT isn't already thinking of, but considering how long it's taken me to really GET what REBOL may mean for the industry, I hope this might be useful for some readers of this list who are still new to REBOL.. and of course, if I'm way off base in my logic, I'd like to hear about it. :-) I remember reading some very optimistic books by a team of authors (Orfali, Harkey, etc.) extolling the virtues of CORBA, The Distributed Objects Survival Guide being the most typical. In these books, they painted this very compelling image of a wonderful world in the near future where all software would be made out of a bunch of components, and companies and end-users would be free to either write their own or buy (or in the case of open source, download) ready-made and tested components that others had written. They saw CORBA as the horse most likely to win the race of being first to market with a workable component architecture that could bring about the "component revolution." So, where are all the components? Why is it that, outside of things like VBX controls and JavaBeans that have been very successful within very limited domains, we still haven't progressed beyond, essentially, shared libraries?! I take that back: MS has done a good job of implementing new Windows technologies in terms of COM components, but, even on Windows, it doesn't seem like ISV's are embracing COM within their own applications. And, on UNIX and Mac and BeOS, neither COM nor CORBA seems to have taken off, and even though GNOME apps are linking with an ORB now, I really don't see GNOME doing anything with CORBA that it couldn't just as easily have done without it. Long story short, I think one of the answers might just lie with a concept REBOL is pushing, dialects. Think about some of the most highly successful Internet protocols we use today: SMTP, HTTP, FTP, NNTP. While not an "Internet" protocol, let's add SQL to the list. What do they have in common? Instead of using CORBA or COM or some binary packet format, all client/server communication is in the form of domain-specific ASCII text commands! Why can't we take that architecture and apply it to creating components that communicate within a single machine? In some sense, we're already doing it in a very static and primitive way with things like /etc files and command-line arguments. Another piece of the puzzle is the notion of minimizing the number of incompatible namespaces on the system. Plan9 took this to an extreme: everything's a file in Plan9, even more so than UNIX, and so it's easy for shell scripts to do things like act as TCP/IP clients just by manipulating the right magic files. More on this below. So, why dialects? First, I think they're much easier to design and document than object interfaces. They've traditionally been much harder to IMPLEMENT, which is why people don't go that route unless they absolutely have to, but that's where REBOL comes in (as I'll expand on in a bit).. They're also MUCH easier to debug, as you can just open a port and start typing in commands and see what's going on! Think about how many mail problems have been diagnosed by sysadmins telnetting to port 25. Why shouldn't you be able to, say, telnet to a port and type a command to open a window, another one to draw a circle in it, etc., and see all the mouse, keyboard, and other events come back to you as text messages too? In fact, like any good RAD environment, I can picture a very clean design/implement/debug cycle where you add a new command, document it, and debug it, all with quick turn-around time compared to designing a class, implementing all the get/set accessor methods, realizing it still sucks, etc. Dialects are much easier to script, as any random scripting language that has the ability to open the port (which, in Plan9 was done in the same way as opening any other file) can spew stuff to it with print statements, and get responses back with read statements. Of course a language like REBOL makes these two tasks particularly easy, so it helps on both sides of the fence. Finally, dialects are TRIVIAL to extend: unlike binary protocols where it's easy to screw up and not leave yourself room to elegantly add new capabilities, with a dialect, you simply add a new command word! You don't even have to worry about proprietary extensions screwing up clients, because there's natural namespace protection built into a dialect, you simply do something like: X-MyCompany-WeirdCommand: foo and if the server doesn't understand, it gives you an error in a well-established (by the particular dialect) way. Efficiency seems to be the big reason more stuff hasn't gone this way, and to be fair, I'm certainly not proposing that we throw away shared libraries! Things like printf() will always
[REBOL] Rebol's argument handling is broken Re:(3)
[EMAIL PROTECTED] wrote:
> If you pass items beginning with a dash (-switch) as
> arguments to the script, how would you suggest REBOL find
> it's own command line switches?
To make this work as Sean expected, the answer is simple: REBOL should
find its own command line switches *before* the filename of the REBOL
script, and pass anything *after* the name of the REBOL script untouched
to the program. This is how the UNIX shell, and I believe Perl, Python,
TCL, and every other popular scripting language work. I'll walk you
through an example of how this works in practice.
Here's a simple shell script that echoes a list of its arguments:
#!/bin/sh
echo $*
I can run this script passing arguments that bash would normally pay
attention to, and they are happily passed to it, whether I do this:
$ sh test.sh --version
--version
or this:
$ chmod +x test.sh
$ ./test.sh --version
--version
So how do I pass arguments that I want bash to listen to? I would have
to either say:
$ sh --version test.sh
GNU bash, version 2.04.3(1)-release (i586-mandrake-linux-gnu)
Copyright 1999 Free Software Foundation, Inc.
or modify the script to something like:
#!/bin/sh --version
echo $*
$ ./test.sh
GNU bash, version 2.04.3(1)-release (i586-mandrake-linux-gnu)
Copyright 1999 Free Software Foundation, Inc.
BTW, when you use the "#!" trick on UNIX to automatically launch the
interpreter, what gets passed to the interpreter's argv array? Again,
an example makes this crystal clear. Here's a little C program that
prints its args:
#include
int main(int argc, char **argv) {
int i;
for(i=0; i
[REBOL] Rebol's argument handling is broken Re:(4)
[EMAIL PROTECTED] wrote: > DOing formed blocks is sort of inelegant. You're taking a > REBOL data structure, a block, and then turning it into a > string. By the DOing the string the interpreter actually > turns the string back into a block of REBOL data types > before evaluating it. It's not very optimal. Just DOing > the original string ends up being half as much work. Yes, but either way it doesn't seem like a whole lot of work, unless you're talking about a REALLY long command-line on a really slow machine. :-) > Another idea that was brought up was that you could have > more than one view of the command line args available, so > those that want the separation of args would have it in a > block somewhere, and those that want just a doable string > would have it somewhere else. Best of both methods > approach. > > Would that work for us disgruntled REBOL command liners? (-: Sounds great to me! -Jake
[REBOL] Rebol's argument handling is broken Re:(2)
Just noticed a minor goof in the message I just sent. In order for
REBOL to be able to produce the argument block:
> ["loop" "5" "[print" {"foo"]}]
the original input would have to be, not:
> $ myscript.r loop 5 [print "foo"]
but:
$ myscript.r loop 5 [print \"foo\"]
This doesn't invalidate my argument, of course... You'd have to escape
the quote marks in this example for the block to be doable, regardless
of how REBOL passes the arguments to the script, because otherwise the
shell will throw them away.
-Jake
[REBOL] Rebol's argument handling is broken Re:(2)
[EMAIL PROTECTED] wrote:
> The argument passing scheme for REBOL needs to address two
> things: 1) Providing args from command line, of course
> and 2) providing an immediately DOable REBOL expression.
1) How many people are going to *want* an immediately DOable REBOL
expression? I think a lot more people are going to want something
that's easy for them to parse. And a block is definitely easier to
parse, and less ambiguous, as Jussi said, than a string.
> With just a string for command line args, the second case
> is easy-- just do the system/options/args. In the first
> case there are situations where the distinction between
> args is unrecoverable, however you can force distinctions
> using escaped quotes, eg:
>
> \"first arg\" \"second arg\"
>
> or
>
> {first arg} {second arg}
2) If people are going to try to use REBOL to write command-line scripts
for others to use, they're going to want to make them behave like native
scripts, and that means escaping spaces in the same way that
command-line programs written in C or Perl or bash do.. Having to escape
quotes or use an alternate quote character is UGLY! Not allowing REBOL
scripters to get at information that would be available to them in ANY
other scripting language is also ugly.
> If you get a block of separate args in strings then the
> result is not easily DOable. The alternative is to have
> the args prescanned (essentially the LOAD of the command
> line args). The prescan creates a potential for
> syntax errors in the command line arguments preventing a
> script from running. That's not very advantageous.
Maybe I'm missing something, but what about FORM? For example, assume I
pass this to my script:
$ myscript.r loop 5 [print "foo"]
If split into a block, as Jussi suggests, this might look like:
["loop" "5" "[print" {"foo"]}]
Watch as REBOL works its magic and recovers the original string:
>> cmd: ["loop" "5" "[print" {"foo"]}]
== ["loop" "5" "[print" {"foo"]}]
>> form cmd
== {loop 5 [print "foo"]}
>> do form cmd
foo
foo
foo
foo
foo
Looks good to me! Is there a case where this wouldn't work?
> In the end, it was decided the best course of action was
> to leave it as it is because people COULD make delimiters
> using shell escaping measures and what not.
As I said, it seems like the wrong solution to me.
> So that's what the reasoning was. Make sense?
Not really. :-) I definitely agree with Jussi on this one.
-Jake
[REBOL] func[func] Re:(10)
[EMAIL PROTECTED] wrote: > BTW When I was first learning REBOL last fall I tried programming many of > the samples from the "Wizard Book" by Sussman et. al.. I found that it was > not really possible to write programs with the same behavior as the Scheme > examples, possibly because of the lack of dynamic binding in REBOL. > Presumably in REBOL 1.x this was possible. I was planning do to exactly the same thing when I get a chance! It looks like some of the messages that have been posted to this list over the past few weeks should be very helpful. I feel bad because, while I can realize that there is a lot of subtle stuff going on with issues like when variables are bound, I don't seem to have the intuitive grasp of how things work that other people on this list do.. or rather, I have to work a little bit harder to figure out what's going on.. and an exercise like porting the samples from the Wizard Book should bring things into a closer focus for me. -Jake
[REBOL] func[func] Re:(2)
[EMAIL PROTECTED] wrote: > I concur. > People *building* difficult stuff can't see the difficulty because they know the >stuff by name, having seen it grow from day one. As I may have said earlier, I can >feel the power of parse, I can almost grasp it, but there's something *just* out of >reach. This context thing I almost got... almost, but not quite... And other little >things here and there. > The meat RT is cooking is already good as it is, but it lacks ketchup. :-) For example, the message I just sent to the list a few hours ago because I couldn't figure out how to parse something that I probably would've been able to parse with no problem using lex and yacc, partly because there are so many more good examples out there for how to use lex and yacc to steal from.. :-) -Jake
[REBOL] need help with complicated parse
I need a little bit of help trying to parse something.. I've modified makespec.r to add a couple of new options to help me generate some HTML documentation for a project I'm working on. They're not very general purpose options, but I'm quite happy with how easy it was to get something quick-and-dirty going. If anyone's interested, I'd be happy to mail you my changes. For example, to generate a two-column table, with the first column in bold, I can use: #table #row "1st Column" "2nd Column" #row "row 2 col 1" "row 2 col 2" /table For this change, I modified makespec.r like this: parts: [newline | "===" section | "---" subsect | "#indent" (emit marg-in) | "/indent" (emit marg-out) | "#side" side | "/side" (emit []) | "#table" table | "/table" (emit []) | "#row" row | "###" to end (emit [marg-out "-End-"]) | example | paragraph] ... table: [(emit [ newline])] quoted: [some space "^"" copy text to "^"" "^""] row: [quoted (emit [text]) quoted (emit [text newline])] Here's the problem.. I'd like to be able to embed HTML tags inside a few of these tables, and some of those tags have embedded quotes, like so: #row "Protocols" "DB1 DB2" Had I thought this through, I could have changed my quote character to something else, but I'm sure REBOL will let me parse this if only I could figure out how. Basically, I'd like to modify the 'quoted' rule to ignore quotes inside of <> markers. How can I encode an algorithm like: quoted: [some space "^"" copy text to either "<" (in which case skip to ">" and keep going) or "^"" "^""] into valid REBOL code? I tried a few approaches but couldn't get anything to work. Another alternative would be for me to escape the embedded quote marks, but then I'd need to figure out how to transform them back for the final text block. Any help would be greatly appreciated. For extra credit, if someone can figure out a way to modify the row: rule to process an arbitrary number of columns (terminated by newline) instead of just two, that would make this new rule a lot more general purpose and probably useful to more people without modification. -Jake
[REBOL] a quine or two Re:(2)
> Isn't a quine supposed to be the minimal code needed to print out itself? It's good if it can be done in one line. In REBOL, wouldn't it be: > > do a: [print ["do a:" mold a]] You're right, of course. I should have spent a little more time and tried to optimize it down to one line myself, but instead, I wanted to see how short I could make it and still have some meat inside the REBOL block. I can see already that I could get rid of two lines by combining the do and the assignment, as in your example. > I'm not sure it has to be a program, does it? But, if so, no problem: > > REBOL [] do a: [print ["REBOL [] do a:" mold a]] > > Pretty short. Of course, I'd like to see other languages do a "superquine", which is to actually write out a file that when run will write out itself. > > REBOL [] do a: [write %quine.r reduce ["REBOL [] do a: " mold a]] Actually, this is not difficult to do in other scripting languages. I'm no Perl expert, but it was pretty trivial for me to turn this quine from the Perl section of the quine page: $_=q(print"\$_=q($_);eval;");eval; into this: $_=q(open(O, ">quine.pl");print O "\$_=q($_);eval;");eval; > And, regarding that sly newline tag. There is currently no way to access it. But there needs to be. Agreed. BTW, I submitted your three examples, naming you as the author, along with the shortened version of my second verbose example, to the quine page: http://www.nyx.net/~gthompso/quine.htm Maybe someone will stumble across the page and REBOL will get some free publicity. It can't hurt, anyway! -Jake
[REBOL] a quine or two
Just for fun: here's one of my first little exercises to get to know REBOL better: a "quine". This is a program which prints out its own source code when you run it. Here was my first attempt: REBOL [ Title: "A simple REBOL quine" Author: "Jake Hamby" Email: [EMAIL PROTECTED] Date: 23-Jun-2000 File: %quine.r ] header: [ Title: "A simple REBOL quine" Author: "Jake Hamby" Email: [EMAIL PROTECTED] Date: 23-Jun-2000 File: %quine.r ] code: [ print ["REBOL" mold header] print ["header:" mold header] print ["code:" mold code] print "do code" ] do code Note the duplication of the contents of the REBOL block. Of course the program would have been much shorter had I left the REBOL block empty, but I wanted to be kosher and do things the right way. Also, it piqued my curiosity about whether or not I could get at the contents of the REBOL block from within my script. I discovered how to do it, and here's my second successful quine: REBOL [ Title: "A simple REBOL quine" Date: 23-Jun-2000 File: %quine2.r Author: "Jake Hamby" Email: [EMAIL PROTECTED] ] print-obj: func [x][ foreach word next first x [ val: get in x word if val [print rejoin ["" word ": " mold val]] ] ] code: [ print "REBOL [" print-obj system/script/header print ["]^/print-obj:" mold :print-obj] print ["code:" mold code] print "do code" ] do code I'd like to submit these to the script library, as well as to this page (http://www.nyx.net/~gthompso/quine.htm), a repository of quines in many different languages, but I wanted to see if anyone could do better first. One curious "feature" of REBOL I discovered while fooling around was that blocks of code can contain embedded newlines and other whitespace, which display when you print the code block, but are invisible when you manipulate it like a list. In other words, this: block: [ a b c ] and this: block: [a b c] are equivalent in every way that I can see, *except* when you print them. Similarly, I was unable to programmatically construct a block with embedded newlines, which might have been helpful to me for this exercise, but print-obj turned out to be so short that I guess it doesn't matter. It is a weird feature, though: I think REBOL's doing the Right Thing for readability, but it's curious that I can't get at the internal structure where this is stored. -Jake
