IMO there are a variety of issues involved in the "component revolution"
that are related to the entire issue of "code reuse" as promised by all of
the "object oriented" technologies.
Component interfaces and communication:
The various component communication mechanisms are in competition - CORBA,
DCOM, XML-RPC, etc. They are not as yet standard. When the components reside
on the same system the efficiency hit is substantial. For a single processor
we have such things as DLLs which are mostly packaging, and OLE which allows
an application to export most of its object model and interface.
Using the interfaces:
No matter what mechanism is used to interface to a component, there is still
an interface to be learned. It may be termed an API, a COM interface, an
object model, or whatever. The fact remains that every component provides
some object structure and some ability to operate on that structure, all of
which requires understanding the nature of the component. This is true
whether the interface is a language (or dialect) of some sort, a programming
language or set of function calls, or an object model exported by
OLE/COM/DCOM/CORBA.
XML-RPC attempts to help by providing a DTD that defines the grammar of the
interface language and a definition of any particular interface. This is
another part of the approach of allowing one component to ask another for
its interface. It is really analogous to asking for and receiving a grammar
for the interface language and a dictionary for it.
Even given this, the programmer still has to understand the interface of the
component being used, at least in broad terms. This is independent of any
interface communication standards and, to my mind, inescapable. What grammar
definitions do help with is changing interface definitions and such things
as parameter type validation for remote invocations.
If we realized interfaces with dialects, we still need to know what the
dialect offers and how it is used. Rebol/View offers several internal
dialects, but programming in any of them will always require a knowledge of
the dialect.
The concept of "little languages" has been used with great success in parts
of the Unix communities for years. When these languages are implemented as
true grammars, they can be very useful and very powerful, since they allow
the programmer to address a problem domain in a language that is suited to
the domain. Languages such as REBOL and FORTH make heavy use of this idea -
the general concept of a dialect.
Indexing reusable components:
Another overwhelming problem is indexing and retrieval of components once
created. Give a universe of accessible components that you could potentially
use, how do you locate those that might be appropriate and how do you find
out what they can really do? If you think that a new component it needed,
how can you find out whether much (or perhaps all or even better) has
already been implemented and is available to build upon?
The best current answer that we have is that components of various sorts are
advertised or promoted in various ways, discussed in email lists and
newsgroups, featured on web sites, and found by accident or by design with a
web search engine.
Learning the interface is done as it has always been done - the bright ones
read the manual and then try things and then ask for help when what the
manual seems to say conflicts with their understanding and the behavior that
they observe. If the component is one that must be purchased prior to use,
the decision it spend the money has to come from the various discussions of
benefits and pitfalls of using the tools.
Notice that this problem doesn't change whether we are talking about
stand-alone applications, programming languages, development tools, or
components in any of their various forms.
While we as an industry have made some progress on the technical side of
reusable and even distributed components, we have hardly the glimmering of
an approach to this problem of indexing. We haven't solved it with regard to
books and other natural language communications, and we haven't solved it
for components.
What now?:
Having said all that, it is clear that components have a real place in the
scheme of things.
Being able to describe the structure and format of the actual interface with
a grammar as is done with XML-RPC is a good step in generality.
The ability to create dialects within a language that allow the use of
component / interface features easily is harder but still useful.
Whether these "little languages" are small enough to be realized by
something like dialects in REBOL or are more appropriately constructed using
parser generators so as to produce true compilers or interpreters for the
languages would seem to depend on the nature of the component interfaces
involved. That REBOL has succeeded with so many of the internet protocols is
an indication of the value of the approach. If these protocols had been
developed from a perspective of language
