Agreed. And even further, given its text oriented approach and
"exec" primtive, it makes excellent use of the existing unix toolset.
Something that lisp and scheme variants tend not to do so well.[1]
In this regard, I view the "extra" types (such as structures, lists,
even numbers) as a barrier to this smooth integration with
separate-process subtools.
So, while the traditional "worse is better" because "better is the enemy
of done" holds, I think it is also true that the performance and
abstraction deficits that come with the text orientation lead to
sometimes-annoying notational difficulties. By which I mean something
more than the trivial "abstraction is the enemy of convenience". It is
more that notational abstraction at one level can lead to an inhibition
of innovative notational abstraction on others[2].
Anyway, the bottom line is, I think that expressing things primitively
in text leads to simpler and more fluent notational innovation than does
expressing things in s-expressions. You take a performance hit for it,
but you end up with a much glue-ier glue.
: Substitution syntax seems a weird base for serious programs, fraught
: with potentital side effects and parameter passing weirdness, a
: semantic mess as big as pass by name. On the other hand, essentially
: every Unix shell works this way, and a shell, like Tcl, is used to
: glue together foreign pieces of code, quite successfully.
True. But I think tcl's expr parser could benefit from not depending on
text substitution rules for all variable usage. This would have the
twin benefits of allowing awk/perl-like converstions-on-demand between
arithmetic and string types (for some performance benefit), easier
encacheability of expression trees for evaulation (for a bit more
performance benefit), and a much less cluttered algebraic notation (for
significantly improved readability). It is in arithmetic expressions
that the string-oriented substitutions are perhaps least useful,
and most confusing.
: p.s. I don't quite agree with either pole. I don't live in academia, I
: need tools that work now, but I cringe when I see lessons from
: previous systems ignored.
Agreed, and there are (I think) *some* lessons in tcl's design that would
be sad to have ignored by any successor scripting languages.
--
[1] Mind you, it's clear that scheme and lisp variant approaches *can*
integrate well with string-bashing unixy approaches. It's just not nearly
so easy to do, and is certainly not feasible without considerable
additions to the available string operations.
[2] Specifically, using a text-based primitive representation means
that it is much easier to use multi-language solutions to problems,
because any single language's internal representation peculiarities
are filtered out early. I find it very nice to fluently combine
awk, sed, sql, perl, and many more subnotations into tcl scripts.
Again, *possible* to do in s-expression notations, but usually
requiring more little bits of distracting notational glue.
--
Wayne Throop throopw%sheol.uucp@dg-rtp.dg.com
throop@aur.alcatel.com