> Nathaniel Borenstein has argued for a procedural language (safe-tcl)
> because he's not quite sure what *exactly* he wants to do. (That is also
> why I'm experimenting with Python agents. ) However, it is just that open
> endedness and lack of standard higher-level functions that makes it
> not, in general, practically safe.
I think this is not quite an accurate representation of my position,
actually. I've argued for a procedural language (safe-tcl or something
better, if it comes along) because I want people to be able to do the
maximal possible number of things safely. It isn't that I'm not sure
what *I* want to do, it's that I am absolutely sure that nobody knows
what *everybody* will want to do. For that reason, my focus has been on
providing the maximum amount of expressive power that is compatible with
a safe language for untrusted scripts.
To make this crystal clear: For any KNOWN application, you can probably
define an appropriate data type to "do it right" without a safe
language. What a safe language provides you with is infrastructure for
future, UNKNOWN applications.
A good example of this would be event scheduling. If there were a
safe-tcl-like infrastructure widely available, you could use it to
experiment with the evolutionary development of a good distributed
system for scheduling meetings and the like. However, once you had
fully elaborated such a system, and understood exactly what your users
needed and wanted from it, you could design a new MIME type
(application/meeting-scheduler) that would probably permit a system that
was in many ways richer and safer than the one based on the safe
language. (This is analogous to the way SMTP and email evolved out of
FTP, actually. You can still do most email-like things by FTP, it just
isn't the best way.)
In short, a safe language infrastructure is primarily a tool for the
cutting edge, to streamline and speed up the refinement and development
of new services. I predict that many of the most successful
applications of such languages will lead directly to new data types that
permit the applications to be implemented WITHOUT the safe language,
because there's probably always going to be more expressive power
available that way. But the overhead of installing support for such
things in a zillion different systems is very high. A safe language
will permit a lot of services to be developed and played with in
*advance* of such domain-specific code installation.
Of course, you still need to get the safe language installed everywhere,
e.g. in all the web browsers. But once you do that, you can experiment
with advanced services much more easily, and thus start to convince
people about what advanced services are most important, and that's the
major point. -- Nathaniel