On one hand, there are fundamental differences in approach of
different languages, that lend fundamental advantages and
disadvantages for different tasks. So no one language is ever going
to be best for everything.
On the other hand, by no means all of the disadvantages of a language
for a particular task are inherent in the fundamental approach of the
language, and many can be corrected with good design. And making a
language capable for many different tasks better enables consolidating
and interconnecting different task handlers within a single framework,
which can be a *great* boon to the systems programmer and user!
> > Can it be made safe ? ... sure , I don't see why not.
>
> I do. It wasnt designed to be safe from the start. From my own past
> experience with Python internals, I simply have no faith that
> reasonable security could be achieved w/o a 80% rewrite.
I have to confess that i do not really know, even in the abstract,
what is entailed in making a language safe, or even exactly what the
safety enables. My impression is that the current impetus for this
sort of thing is so the language can be used as a substrate for
passing procedural objects across client/server connections, when the
client doesn't necessarily trust the server. Eg, particularly, a web
client dealing with an arbitrary, not particularly familiar server,
out there in the ether. This seems like a useful goal, and something
for which python would be well suited, modulo this safety thing.
Perhaps it would be important to better focus our designs by
determining a specific problem domain, like the above procedural
objects for web client/server relations, and possibly help to keep the
impact on the language proportional to the purpose? ?
Ken
ken.manheimer@nist.gov, 301 975-3539