Re: Why you should not use Tcl

Robert DeLine (rdeline+@CS.CMU.EDU)
26 Sep 1994 20:59:16 GMT

Thanks, John, for not fanning the flames and for encouraging technical
discussion. In that spirit, I would like to take issue with one of your
comments:

John Ousterhout writes:
|> Ultimately all language issues get settled when users vote
|> with their feet. If Tcl makes people more productive then they will use
|> it; when some other language comes along that is better (or if it is
|> here already), then people will switch to that language. This is The
|> Law, and it is good. The Law says to me that Scheme (or any other Lisp
|> dialect) is probably not the "right" language: too many people have
|> voted with their feet over the last 30 years.

This notion of "voting with your feet" as a way of judging the quality
("right"-ness) of a programming language only works when the choice of
programming language is based on technical merit. I'd like to claim that
there are many reasons why a given programming language is chosen for a
given project and that these reasons seldom deal with the technical merits
of the language. People choose a programming language for a project
because:

* they already have experience in that language;
* there are tools available for that language in their target environment;
* they must interface with existing software, which implies that language;
* the language is popular, so obtaining training and tools is easier;
* there are nifty tools/libraries available if they use that language;
* there is corporate/university infrustructure that demands that language;
* and so on.

I've worked on and started many software projects, but not once have I
gotten to use "my favorite programming language" -- there were always
external containts that dictacted the language to use. Hence people don't
always switch to "better" languages when they come along, and a language's
lack of popularity doesn't necessarily damn it as a bad langauge.

In short, using a programming language's popularity as a quality metric is
dubious.

Rob DeLine