Re: Looking for scripting suggestions

"George B. Smith" <gbs@k9haven.com> wrote:
> "Eric Tetz" <erictetz@yahoo.com> wrote:
> > TCL, besides being large and slow, also happens to be a pretty crappy
> > language IMHO. For details, including Richard Stallman's "Why you should
> > not use Tcl", see:
> >
> > http://www.people.virginia.edu/~sdm7g/LangCrit/Tcl/


> This is, IMO, a very cheap shot. The version of Tcl that RMS
> critqued bears little resemblence to a modern Tcl, ie 8.3.3.3 or
> 8.4a3, in terms of features and most especially performance. People
> who are still pointing out this very dated argument from RMS are
> doing a disservice to inquiring minds.


Hmmm... I didn't mean it as a cheap shot; I think the majority of that
article is quite relevant today. The fact that a bunch of new stuff
has been tacked on to TCL, and that more efficient implementations
exist, cannot cure fundamental flaws in the language. You don't make
an octopus by nailing extra legs onto a dog.


TCL's author readily admits the language is flawed, "Some of the
flaws, like the lack of a compiler and the lack of module support,
will get fixed over time. Others, like the substitution-oriented
parser, are inherent in the language. Is it possible to design a
language that keeps TCL's advantages, such as simplicity, easy glue,
and easy embedding, but eliminates some of its disadvantages?" The
answer to this last question is a resounding YES!! It has been done
many times over since Ousterhout wrote those words.


Without even getting into TCL's technical issues, lets look at the
flaming hoops TCL makes you jump through for even simple operations:


    proc fib {n} {
        if {$n < 2} {
            return 1
        }
        return [expr {[fib [expr {$n-2}]] + [fib [expr {$n-1}]]}]
    }


The expression in that second return statement is just absurd. And
this example is *trivial*. What happens when the task at hand becomes
more complicated? Obfuscated C doesn't look so bad anymore. And it
*does* get more complicated; one of Stallman's primary points is that
regardless of your intentions, the scripting language *will* be asked
to do more than you originally planned.


Here's Lua, Ruby and Python versions of the same code:


    function fib (n)
        if n < 2 then
            return 1
        end
        return fib(n-2) + fib(n-1)
    end


    def fib(n):
        if (n < 2):
            return(1)
        return( fib(n-2) + fib(n-1) )


    def fib(n)
        if n < 2 then
            1
        end
        fib(n-2) + fib(n-1)
    end




Neat, clean, and to the point. I recommended Lua because it happens to
have a small implementation and is fast.


Unfortunately for me, I'm stuck with TCL. I'm work on a network test
tool. The primary author chose TCL as the scripting language because
(a) other network test tools use it, so the testers were likely to
already know it, and (b) TCL was only to be used for configuration and
very light scripting, with all the heavy lifting done in C++. It
didn't work out that way. We now have a large parts of our regression
suite written in TCL. Some of it is horrendous (through no fault of
the testers). Stallman's words could not have been more true.


IMO, TCL is perpetuated by the momentum of its large user-base, and
not by the technical merits of the language. So why continue to foist
TCL on unsuspecting newcomers, especially when better alternatives
exists? It's a dirty trick, and people will only resent you for it
later. ;)


Cheers,
Eric

Return to the comp.compilers page.
Search the comp.compilers archives again.