| I think that Stallman's objections to Tcl may stem largely from one
| aspect of Tcl's design that he either doesn't understand or doesn't
| agree with. This is the proposition that you should use *two* languages
| for a large software system: one, such as C or C++, for manipulating the
| complex internal data structures where performance is key, and another,
| such as Tcl, for writing small-ish scripts that tie together the C pieces
| and are used for extensions. For the Tcl scripts, ease of learning,
| ease of programming and ease of glue-ing are more important than
| performance or facilities for complex data structures and algorithms.
| I think these two programming environments are so different that it
| will be hard for a single language to work well in both. For example,
| you don't see many people using C (or even Lisp) as a command language,
| even though both of these languages work well for lower-level programming.
The GNU emacs experience, is that this clean separation just does not
happen. Systems evolve by writing large portions of the code in the
extension language. Over time features migrate up and down from the
C/elisp boundary, as functionality, extensibility and performance
requirements are understood better.
Notice that, as you point out later in your message, the TCL
experience is the same: the extension language is used for large
portions of the system.
| Thus I designed Tcl to make it really easy to drop down into C or C++
| when you come across tasks that make more sense in a lower-level
| language. This way Tcl doesn't have to solve all of the world's
| problems. Stallman appears to prefer an approach where a single
| language is used for everything, but I don't know of a successful
| instance of this approach. Even Emacs uses substantial amounts of
| C internally, no?
The emacs approach is NOT to use elisp for everything. But, why
use C when elisp can do? Ditto for TCL.
| I didn't design Tcl for building huge programs with 10's or 100's of
| thousands of lines of Tcl, and I've been pretty surprised that people
| have used it for huge programs. What's even more surprising to me is
| that in some cases the resulting applications appear to be manageable.
| This certainly isn't what I intended the language for, but the
| results haven't been as bad as I would have guessed.
BTW, I think that TCL is not far off from being a pretty reasonable
extension language. From what I've seen several small modifications
would make it adequate. Hopefully it will keep evolving and improving.
>From reading RUSH, it seemed a good direction. I haven't looked
at [incr tcl] yet.
- eduardo