Jake, you got it. You said it. Here's the way I summarize it: It all comes down to communications. The object-oriented approaches (CORBA, etc.) are trying to do it with their arms tied behind their backs. Good communications requires language, not just static language, but living, mutating language. Language = expression = function = action. Now, how do we get others to understand that? The concept of language is so fundamental to humans. It's not obvious because it is so obvious. -Carl REBOL's Dad At 7/17/00 01:52 PM -0700, you wrote: >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 be best handled through >that sort of mechanism. However, what exactly would be the impact if >the >computer industry were to embrace dialects and take them to their >logical >conclusion? What if, sitting at your PC, you could connect to any of >100 >different ports, each one of which would supply you (as well as the >applications which depend on it) with a set of well-defined services >available through a simple, domain-specific language? > >I can think of a few obvious implications. First, security! While it's >useful to think in terms of "telnetting to a port", it's clear that, if >this is the primary way to add functionality to a system that was >previously available through shared libraries, the DEFAULT security >should >be localhost-only, with some secure way of establishing the identity of >the user. Something like UNIX domain sockets would make sense, at least >on UNIX (in fact, 4.4BSD has a rather nice feature in that one app can >send unforgeable credentials to another over a UNIX domain socket). >Clearly it would be trivial to write a telnet-style debugger tool to >connect and log in to one of these sockets, and the fact that they sit >in >the filesystem namespace means that they'd be much easier to find and >avoid collisions than a numeric TCP port. The other nice thing is that >the needed infrastructure is already in the UNIX kernel and is >well-tested, efficient, and reliable. > >Of course UNIX domain sockets eliminates the possibility of remote >access >when you do desire that sort of thing, so it'd be nice if this solution >supported TCP as well. The funny thing is that, by communicating in >terms >of ASCII commands, there's no need for anything like IIOP, and it's >probably just as efficient, if not potentially even better! > >You might argue that this will create a "Tower of Babel" with each >language being completely different from all the others, but I think >that, >by planning for the future and creating a sensible set of "Language >Design >Guidelines" (much like the famous Mac UI Guidelines), you can eliminate >99% of this. Ideally, each language would service no more than 10-20 >commands, and all the boilerplate stuff (like returning error codes for >commands not recognized, etc.) would be handled in an identical way for >all of them. > >The real issue that's kept this from happening so far, and this is where >I >think REBOL can come in, is in the difficulty (up until now) of writing >reliable parsers for these domain-specific languages. What if we assume >a >single multithreaded REBOL server to wait on all of these UNIX domain >sockets and TCP ports, parse each of the hundreds of domain specific >languages, and then call down to a mixture of native and REBOL code to >implement the functionality? This presumes a lot of REBOL, and clearly >current versions of REBOL are probably not up to the task, but I think >future versions could easily be, and I'm pretty sure the clever people >at >REBOL are already looking forward to such a day. It's just that you >have >to read between the lines and really THINK about the nature of software >"components" to make the connection that maybe REBOL has a real >alternative worth pursuing, because clearly CORBA has had its chance, >and >so far has not ushered us into "component heaven", so what do we have to >lose? > >-Jake >
