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
