[REBOL] where are all the components? Re:(7)
yes i did mention it to him, he even mentioned it in his daily writings at www.scripting.com his outliner XML idea is rather powerfull :-) although i have found it not easy (at first) to parse and manipulate it with rebol HJ
[REBOL] where are all the components? Re:(3)
i have an example of a rebol processing script at a temp server i use: http://131.211.29.218/cgi-bin/outlines.cgi That's pretty cool! Would it be possible for me to get a copy of your REBOL script? Curt
[REBOL] where are all the components? Re:(2)
I loved reading the two post from Jake and Garold. They express things I've been musing over for years. My own, coupla bits: With any description there is an irreducible amount of information that has to be encoded. Whether this has been done as an interface or as a monolithic program or system. The great thing that Rebol has done is to give the "Reboler" (programmer/user) power in expressing and interpreting this minimum of information. Maybe we call this stuff a dialect - a better language to communicate in. This then is how I understand RT description of Rebol being a messaging language - an' boy don' it do that well. So from this great ideas flow. One day I had an idea - may not be original but hey my brain produced it - one day I'll try it too. I thought well Rebol is so cool at languages I can buy me a voice interpreter and use it to chuck some dialectical words at Rebol and think of the possibilites. Now how does it work on Voyager? "Computer.." "Bip beep" Another. I've found that I'm wanting to write input-parsers for Rebol that take information out of existing format and place it in Rebol blocks where I suspect I'll be able describe all sort of wonderful transformations before forming into other formats again. One example. I got my tab-delimited-with-quoted-strings parser thingy happening. Now if get my Flash SWF input/output thingy happening I'll be able to combine the result and produce a Flash spreadsheet! Cool eh? Well, ok not cool. Probably dum. BUT I would have NEVER DREAMED of doing that before. Thats the point I think. Components. In my Rebolised mind now, a component is an interpreter with associated context. Thus, this component can be in my Rebol script, sitting in Java, sitting in Javascript in a browser, sitting on in another process on my machine, on another machine behind a port or maybe one day be part of a Rebol-OS accessible from the OS prompt. This isn't new this is what is today. Rebol has accepted it and provided another way to talk between them. I think components arrived when system theory game them birth - just maybe no-one celebrated at the time because they could'nt work out they were. They're here to stay because we have a wired and distributed world to talk to, but maybe not existing in the form the designers of COM and CORBA thought they might. End-of-trip. Boy that coffee was strong. Brett.
[REBOL] where are all the components? Re:(2)
"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." That hilarious! But mostly true! A name to my discontent, "distressing". I knew there was a reason I've been playing (=fun) with Rebol instead of working (=discipline) through Java for the last three months. Java is here to stay, it is a great 3GL+ (+ = objects). It is a pity it didn't come out a decade earlier - would've made my life easier. On second thought, probably not, nothin new under the sun Brett.
[REBOL] where are all the components? Re:(6)
this particular example is an implementation of dave winers outliners idea, Did you tell Dave about this thing? I'm sure he'd be really interested to see it :)
[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] where are all the components? Re:
had been developed from a perspective of language to start with, the job would be simpler. If the email protocol had been defined based on an internal object architecture then the protocol itself would consist of little more than appropriately marshalling and unmarshalling the object, which is the effect that the REBOL dialect (or Perl library, or Python library, or . . . ) has. FWIW, Garold (Gary) L. Johnson DYNAMIC Alternatives [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, July 17, 2000 1:52 PM To: [EMAIL PROTECTED] Subject: [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 TRIVI
