Re: Looking for scripting suggestions

"Eric Tetz" <erictetz@yahoo.com>

3 Sep 2001 22:56:02 -0400

From: "Eric Tetz" <erictetz@yahoo.com> Newsgroups: comp.compilers Date: 3 Sep 2001 22:56:02 -0400 Organization: Posted via Supernews, http://www.supernews.com References: 01-07-166 01-08-009 01-08-140 Keywords: interpreter, design Posted-Date: 03 Sep 2001 22:56:02 EDT

"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.