[ Re: procedural .vs. non-procedural ]
> Well, I really have to disagree with this one point. The whole point of
> extension languages, to my mind, is dealing with the unanticipated.
I guess my worry comes down to: can you ever really make the unanticipated
safe ? ( I've tried to choose my words carefully when I said I was
"unconvinced" by the paper: I just may not understand the model sufficiently
- I'm the sort that usually needs some hands-on experience before what I have
read falls into place, so maybe after I've actually tried to write a
safe-tcl script or two, I'll acquire more confidence in it. )
> I would *love* to hear, however, about anything you want/need to do in
> collaborative computing that can't be made to work well in Safe-Tcl.
Well - the main point was that I wanted to add safe features to Python
to aid *Python* programming.
Not to get into language wars, but one of the things I have found
about Python is that it's module and O-O class system ( and overloading
of builtin operators ) makes code reuse and collaborative work easy and
practical. I find my code-reuse in other languages tends to be done
mostly in the editor: cut and paste and modify pieces of code. In Python,
I find myself using other peoples modules and classes without having to
poke around in the code. What we've been lacking though, is someone with
the time to organize and document all of the posted and contributed code
into one package. So I'm looking for a way to _distribute_ the work:
The plan is to embed Python <CODE> in HTML documents, to get a sort of
hypertext-literate-programming-class-browser-and-documentation-viewer
and to add a remote "import" to the language. However, the "safe" features
required for this are pretty much the same sort of things required for
enabled-mail and other agent-ware. This did not start out in competition
with safe-tcl (although it was partially inspired by it), but, inevitably,
any alternative *is* competition.
> > I understand his desire
> > that for it to be an effective standard, defacto or otherwise,
> > he would rather see people adopt his scheme that putting energy
> > into a "competing" product.
>
> I think you've captured my argument pretty well here. I wouldn't dream
> of objecting to people building new languages for good reasons; my
> biggest concern is to try to reduce the amount of *frivolous*
> reinvention-of-the-wheel, because ultimately I think that such work will
> have a negative impact on progress towards better global infrastructure.
I agree. In fact, I had some initial hesitation to push forward on this
project - I didn't want to be a "spoiler" - so the fact that I am launched
on it anyway - I'm *not* in the "anything but tcl" camp - is one of the
things that makes me sceptical about the success of a procedural language
based standard of this sort. ( I should add: sceptical, but also hopeful
that I'm wrong! )
The other things has been touched on in the gnu.misc.discuss et.al
language wars:
I also evaluated tcl and several other languages before I settled on Python
for several projects. Tcl would have actually been a better fit for one or
two of them, but I didn't want to have to support both of them, and Python
looked like a better all around choice - it wasn't as minimal a language as
tcl. TO some extent, that desire seems to be futile: I *will* have to support
Python, Perl, Tcl, Xlisp-Stat, as well as C, Fortran and a couple of others.
:-(
However - how many languages do I need to use in one program ?
If I need to write in C and Python and Tcl and XXX, the complexity
of the interfaces between them all starts to become a bigger factor
than the effort saved by "using the RIGHT language for the job".
Maybe ILU - Inter Language Unification, from Xerox is
the solution to the problem of proliferating interfaces.
Or maybe writing one language in another - after reading
the TC tcl compiler paper, I considered trying to write
a TCL compiler in Python, that would compile into Python's
byte-code. It didn't look that hard, but it was suggested
to me that that didn't get me too far, as without Tk and
other support modules, it wouldn't bee very useful. However,
now that someone has ported Tk to Python, I may reconsider:
it would yield a faster tcl. The only problem is those
*damn* interfaces ... All the Tcl code would run unchanged,
but I'ld have to modify any other C-coded support modules
to fit into both Python and Tcl.
( I saw the references to Rush yesterday, and I'm going to
read them at lunch. )
-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --
[ "Cheese is more macho?" ]