The implementation is quite elegant and efficient. I don't see any good
way of compiling it, altho I have heard of papers discussing it.
It isn't bad once you get used to it, which takes far less time than (say)
getting used to C. However, elegance has never been a driving
force in acceptance of software, as far as I can tell.
It is (or will soon be) ported to any number of platforms.
It can be made arbitrarily efficient by replacing larger and larger
subroutines with C code (or whatever code).
> Whatever, the language, the important issues are a secure/safe
> abstract machine in which it is to execute.
Which is already defined for Tcl. It's called Safe-Tcl.
It's standard, its free, its (pretty) portable, and it works today.
Those are pretty powerful advantages compared to "elegance".
> If we talk about execution on the servers or in caches, then I think
> we need to be concerned about efficiency.
Have you ever actually used Tcl and measured its efficiency? One of the
really stifling trends I see nowadays is people who insist on using cruft
like C on the grounds of "efficiency" before ever actually trying it to
see if such low-level solutions are necessary.
We should be concerned about it, but the solution is not to chose an ugly
language that can be made efficient with sufficient care, but to chose a
good interface (e.g., CGI vs C++). With that in place, efficiency can be
improved where and as needed, rather than requiring everyone to go thru
contortions trying to make code running as Root in C++ secure just
because a few dozen server sites are overloaded.
> The larger issue when one starts talking about pushing executable
> candy-grams around the network is controlling those that have more
> than an extremely short life span.
Yes. This is still an open question in SafeTcl, since it was primarily
designed for email applications. I would be interested in hearing what
ideas you might have on this front. -- Darren