Sun, 26 Aug 2001 12:22:52 -0500
Dave Winer wrote:
The thing that's tickling my lobes these days is the suspicion that there's a
qualitative difference --- and perhaps a quantitative one --- between a couple
of different kinds of programming. One kind involves wiring up components. The
other one involves modeling. Any reasonable programming language probably has
facilities for both; but most languages optimize for one or the other.
This whole train of thought is actually inspired by something that you said,
Dave; you challenged the REST crowd to come up with a scripting language that
allows people to easily build RESTful systems. This is a pretty deep
challenge; it points out that there is a mismatch between what most existing
scripting languages are good for --- expressing procedural endpoints of
arbitrary arity or object interfaces of arbitrary complexity --- and the more
generic interfaces advocated by REST. It's neither conceptually nor
notationally as convenient as it could be to wire up sets of REST resources.
What would a language or toolkit specifically for REST look like?
Now, I have no intention of actually taking your challenge up and building
another scripting language; I'll leave those to you. :-) I might build some
Python glue. However, right now I'm sort of groping around in the dark to
capture and describe the differences between the kinds of programming listed
earlier. I don't really believe this is a "been there, done that" kind of
thing; I think *perhaps* we've all collectively had an opportunity to learn a
particular lesson before about software reusability --- me included --- maybe
repeatedly --- and *failed to do so.* Or, maybe not. But that's what I'm
trying to figure out; what are the lessons lurking in the parsimony and power
of Plan 9, the constraints of REST, the elegance of Linda, the simplicity of
shell programming, etc.? Similarly, what are the lessons of RPCs, CORBA and
DCOM that might be applicable to the HTTP-RPC Web Services view?
As I've said before, I don't think this is an either / or kind of thing.
However, I do think there might be qualitative and quantitative things about the
economics, scalability, and so on of various approaches that might be useful in
selecting the right thing for the job. So burning a few extra brain cycles on
it seems reasonable.