A problem for "Web as distributed programming paradigm"

Jeff Bone jbone@jump.net
Fri, 24 Aug 2001 00:07:02 -0500

Russell Turpin wrote:

> In answer to the second question, and approach
> to the first, let me offer one criterion of a true
> distributed programming paradigm: the distribution
> is transparent to the programmer. Linda has
> this quality.

So debunking one small myth;  this transparency quality isn't even
true for Linda when used in the same context as the Web.  All Linda
systems do not automatically constitute a single, global tuplespace.
In Linda applications where multiple organizations must coordinate
activity between each other, the application itself must be
explicitly told which tuplespace to use / how to find and bind to
it.  This is equivalent to the Web's leveraged use of DNS, but even
less elegant;  it's a configuration / deployment consideration,
rather than a built-in and generic feature.  You don't get that sense
reading Linda papers and so forth, but that's because they're written
from the perspective of research systems or single-installation
systems.  And those operations are exposed to the programmer in ways
dependent on the particular Linda implementation and language binding
that's being used.

> So, to an extent, does DCOM.

Not at all;  it again uses network naming schemes (for tight
coupling) or name services (for loose coupling) in order to
accomplish binding.  Same thing with CORBA;  there's always the task
of finding and binding to the ORB in question, then using it to
bootstrap to any necessary higher-level name resolvers.

There are *no* truly transparent distributed programming mechanisms.
The best offer extremely high-level name services that understand
application-level objects and map them under the hood into
lower-level names / addresses.  Today's Web may a bit hinky inasmuch
as it exposes a lower-level abstraction in the http:// URI scheme,
but it's a far sight better (uh huh huh huh...  far site...  get it?)
than any of the alternatives --- *including* Linda --- for building
loosely-coupled and late-bound distributed systems that span
organizational boundaries.

> In
> both cases, you can use the formalism to write
> programs that are never intended to be distributed.
> And this works, not just as a novelty. I could use
> either to write -- say, a program for simulating
> the growth of anthills -- that runs just on my PC.

That's true.  And what's happening here is that you have a runtime
library that's mediating the access between your language
abstractions and the underlying IPC.  That's a good thing.

> Linda and COM both provide useful ways to
> think about how to structure a system into
> reusable components, even in a non-distributed
> environment.

Well, Linda provides this, absolutely.  It's a coordination language,
that's what it does --- in fact, it not only deals with problems of
abstraction and representation but also interaction.  COM doesn't
really do all that.  To the extent it helps with decomposition, it
does so by inheriting the notion of objects / components / etc. from
familiar programming models.  To the extent that it aids in
coordination, it do so by virtue of providing a single coordination
mechanism:  function / method invocation.

> But even if I ran a local webserver, and even
> if using it for program decomposition weren't
> dirt slow, I would be hard pressed to think
> *why* I might use HTTP to structure a program,
> except where distributed execution is irrelevant.

So here's the hypothesis:

  * The "resource model" is as expressive as generic object models
  * GET / PUT / POST provide a universal coordination language

It's true that we don't have the same general level of understanding
of how to use these tools to structure and build systems today as we
do, say, for OOP (COM) or generative communications (Linda.)  And
there's *definitely* an impedance mismatch between the design
perspectives, modeling techniques, and tools used for OOAD and REST.
(The same is true for OOAD and Linda.)  But that doesn't mean that
there aren't benefits there, any more than the lack of adoption for
Linda meant it was less powerful and useful than OOAD.

This is what I fear:  Linda was a wonderful way to think about
building distributed systems, but it seems like there were only a few
dozen of us on the planet that had even heard of Linda before
JavaSpaces hit the scene.  It basically died on the vine when the
commercial interests got behind another lower-level remote
programming model which mimicked the familiar local programming model
du jour, procedure calls.  And very few people even now really
understand it;  its incredible expressive power and utility is
obscured by its overwhelming simplicity.  ;-)

I think that the Web / HTTP / REST / whatever may be the same kind of
thing;  that's really what's lurking at the heart of my REST
gestalt.  Just *maybe* we're about to smother that simplicity by
heaping on a load of unnecessary complexity, for the sole reason that
all of us in the industry share an unfortunate tendency to maximize
complexity.  We don't "get" some of the fundamental stuff about the
Web, so we're going to pile on whatever it takes to remake it in our
own image, that image du jour being OOP.

And that would be unfortunate.  Tedious complexity is easy;
simplicity is *hard.*  It's been said that it takes a tough man to
make a tender chicken.  ;-)

> Yeah, when I have to do IPC, well .. it's the
> Web, so HTTP is always one of the top
> candidates. But I always and only use it where
> IPC might occur. I never view HTTP as a
> general way to structure software.

I hadn't really thought of it that way either until recently;  I just
viewed it as a great transport for doing RPCs over.  :-)

> And I've
> never seen it used that way. Why is that?

Sure you have, every time you see a banner ad.  (For instance.)

> It
> seems to me that that is key question, if one
> wants to view HTTP as a distributed
> programming paradigm.

So terminology aside, there *is* a massively distributed /
uncoordinated programming infrastructure out there:  the Web.
Understanding what it is that we've actually built and why it's been
so successful is a difficult and extremely important task.