From: J.M. Ivler
Subject: Re: what to use instead of TCL or PERL
Date:
Message-ID: <43fgn3$1g4@nntp.crl.com>
Harold Carr (····@fast.cs.utah.edu) wrote:
: What do programmers who implement and use real programming languages
: like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or PERL?
Harold, all languages are tools. Each has certain strenths and
weaknesses. C++ may be good for some applications, not so good for
others. The same can be said for all languages.
Consider the programmer as a carpenter. He has to sink a screw. Now he could
use a hammer to sink it, and it would work, but it would work much better
if he used a screwdriver. Additionally, the screw is a philips head. Now
he could use a flathead screwdriver, but wouldn't the better tool be a
philipshead screwdriver? Now, if he had only one screw to sink, he might
use a hand screwdriver, but he has 1000, so might it not be wise to
attach a philipshead screwdriver to a powertool to help?
At each point in the design of a project the developer looks at the tools
in the supply cabinet. He may have to consider porting issues, or issues
of GUI interfaces. No matter what the concern, there are always factors
that go into determining the "right tool for the job". and that includes
the language that the solution should be coded in.
I note that you are posting from a .cs.[place].edu I suggest that you may
want to look into seeing if they have a class in Intro to Computers that
you could take, as the above comes from my notes when I used to teach it.
jmi
·····@crl.com
set Tcl {a toolbuilders friend}
From: John Chambers
Subject: Re: what to use instead of TCL or PERL
Date:
Message-ID: <43pn5p$e83@ceylon.gte.com>
In article <··········@hplb.hpl.hp.com> ···@hplb.hpl.hp.com () writes:
>J.M. Ivler (·····@crl.com) wrote:
>
>|Consider the programmer as a carpenter. He has to sink a screw. Now he could
>|use a hammer to sink it, and it would work, but it would work much better
>|if he used a screwdriver. Additionally, the screw is a philips head. Now
>|he could use a flathead screwdriver, but wouldn't the better tool be a
>|philipshead screwdriver? Now, if he had only one screw to sink, he might
>|use a hand screwdriver, but he has 1000, so might it not be wise to
>|attach a philipshead screwdriver to a powertool to help?
>
>Carpenters often _do_ use hammers to insert screws; they hit them in for most
>of the distance and then screw them in for only the last 1cm or so. Much
>faster, and it works!
>
>Know your tools, and use the appropriate _mix_ of tools!
As an example of yet another logical fallacy in the presuppositions
implied above: Carpenters who have square-drive bits very often use
them to drive (mostly remove ;-) Phillips screws. The smaller square
bits fit quite well into a Phillips screw's slots, and unlike the
Phillips bits, they don't tend to pop out so easily. If you are
trying to remove a stuck or damaged screw, the square bit will usually
work better than the Phillips bit.
This is an example of the fallacy in the "obvious" advice to use the
appropriate tool for the job. Few people would consider mixing bits
like this to be "appropriate" (in the usual sense of the term). But
this is an example where the "wrong" tool actually does a better job
than the "right" tool.
To be more accurate, this is a case in which tool X does tool Y's job
better than tool Y does, despite the fact that X wasn't designed to do
Y's job. Similar examples abound in the computing world. Thus, csh
was designed as a C-like scripting language; it was supposed to be
better for writing scripts than sh. There have been a lot of summaries
posted explaining why 1) (k)sh is a better scripting tool than csh, and
2) csh is a better interactive shell than (k)sh. This is exactly the
opposite to what you'd expect from their design goals.
Another curious example I ran across a few years back: I did a speed
test comparing various file-transfer packages across various networks.
One of the results was that, when uucp worked across tcp, it beat out
ftp by a *factor* of 3 to 4. Now, uucp was designed to work across
poor-quality links like modems and phone lines; the tcp driver was a
late add-on. On the other hand, ftp was designed to run on tcp. So
how does uucp beat ftp so badly on ftp's "home court"? A 10% difference
wouldn't be worth noticing, but how did ftp's authors blow the job
so badly as to lose by more than a factor of 2? (Not only that,
but you don't have to hold uucp's hand like you do with ftp; it keeps
trying until it succeeds, and optionally tells you when it's done. So
despite the fact that it's not interactive, it's much more user-friendly
than the interactive ftp. Of course, ftp's problems won't be fixed, due
to the unwillingness of the Internet crowd to learn anything from things
like uucp. ;-)
The computer industry is full of examples of tools that do their job
poorly, while a tool not designed for the job does it better.
--
if (HEART(getenv("USER"),'C')) printf("Honk!\n");
print "Honk!\n" if &HEART($ENV{'USER'},'perl');
if {[HEART $env(USER)] == {tcl}} {button .h -text honk ; pack .h}
YOU 4TH HEART IF HONK THEN