Anyway...
> > Please not TCL. It is intrinsicly inefficient and, to my eyes, quite
> > inelegant.
>
> 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.
An elegant implementation of an interpreter is a long way from saying
the same thing about the language itself.
Please don't take me as an anti-TCL bigot. Rather, I'm concerned that
as we load servers with more and more interpretable blocks of code
that what are tolerable levels of overhead will be vastly multiplied.
(The standard warning in http daemon configuration documents that
running the daemon from inetd might not be desirable is a similar
forewarning.)
> 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".
The concern I have about "safe" environments is that they often do not
consider the interactions which can occur between machines, i.e. as
things travel across "safe" boundaries. We find this kind of problem
all the time in network security where people hook up machines running
secure operating systems over an encrypted network. Because the
secure environments aren't coordinated, it is possible to introduce
information which has different meaning in the various security
contexts and hence cause a secrutity violation. This often happens if
the different machines have different privileges attached to the same
user ids or user names, for example.
> > 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.
Yes, I've seen many Sparcstation 10s sinking under the load.
I did an interesting comparision, a TCL/TK program that did some bit
map drawing and the ELK Scheme toolkit (that also has X operations
built-in). The Scheme (Lisp) based approach ran circles (drew
circles?) around the TCL/TK engine.
I quite agree with your point about finding the slow spots and then
optimizing. If I didn't believe that I would still be using assembly
language.
However, as someone else mentioned, the value of TCL is that it gives
a means to express the sequence of execution, which just about all
languages can do. And hence the value of TCL/TK is in TK, not TCL.
And I don't think that we are talking about documents that have
built-in X11 display operations?
But we are getting in a language war here, which is not what this list
is all about.
> 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.
I haven't seen anyone advocating C or anything like it. I'm surprised
I haven't seen anyone mention (I hope I'm not hit by lightning for
this) Microsoft's Visual Basic.
One interesting side point about languages like Scheme is that they
are so small that it may be possible to build tools that can validate
that the program itself is safe rather than wrapping it in run-time
checks. But this is starting into proof-of-correctness territory, a
black art I haven't practiced in some years.
> > 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
Ah, finally what I do want to talk about. But first, I think we
really need to understand how smart documents will interact with one
another or spawn one another, if they do so at all, or how cgi-scripts
interact with other cgi-scripts, if they do so at all.
The stuff I've been working on allows the creator of a
script-in-execution to have enough control over that script to kill it
or replace it. I don't know that this is a relevant concern to this
group except insofar as these kinds of things make really nice web
search engines. (I'm working with controlled worm programs -- it's
time to dust off the old copy of Shockwave Rider.)
--karl--