Re: Why Tcl is a Bad Thing

Peter da Silva (peter@nmti.com)
Wed, 12 Oct 1994 19:07:51 GMT

Personally I wouldn't consider using a conventional algorithmic language for
an extension language if any list or string oriented language, however poor,
is available. I do not understand why people insist on taking complex languages
that are hard to generate code for algorithmically and putting them in an
environment where they will inevitably used to parse algorithmically
generated configuration files.

I can take a Tcl config file and *parse* it with a fairly simple routine into
Tcl atoms, modify it, and write it back out... without worrying about having
some user put something complex into the file that can't be parsed. The same
is true for reasonably pure lisp (though things like macros make it harder).
For something like Python, though, it's a mess. You pretty much have to have
a complete codewalker to do the trick. The same is true of just about any other
algorithmic language I know.

The "code is data" model is a *very* powerful one. Don't try and force
something on me that forces me to violate it. Fine me a better compromise
than Tcl... I don't think you can: Tcl is such a very nice balance between
the ideal I would prefer (lisp or scheme) and the ideal that just about
every end user prefers (basic).

Using two languages for this would simply make for the worst of both worlds:
forcing end users to parse lisp, in config files, and forcing all the chaos
and complexity of algol-style languages on the implementor (and again I say
unto you, for something like this where you have lots of programs digging
into config files parsing the code gets reinvented again and again).

-- 
Peter da Silva                                            `-_-'
Network Management Technology Incorporated                 'U`
1601 Industrial Blvd.     Sugar Land, TX  77478  USA
+1 713 274 5180                       "Hast Du heute schon Deinen Wolf umarmt?"