Perl vs TCL (was: Execution speed of Perl?) 
Author Message
 Perl vs TCL (was: Execution speed of Perl?)

   Like most shells, tcl is strictly a string-substitution language, which
   has a number of serious side effects.

Been there, done that -- see
<ftp://oak.oakland.edu/SimTel/msdos/freemacs/emacs16d.zip>.  Tom is
right, string-substitution loses for large programs.

   If you read the older writings of John Ousterhout on tcl and contrast with
   the newer ones -- or just listen to some of his talks -- you'll see that
   he's changed his tune a bit about what tcl's legitimate and reasonable
   problem domain is.

I have read the early stuff on tcl -- it's designed to be an embedded
language.  It's a way to paste together new primitives.  Writing new
primitives in tcl, while emotionally and technically rewarding, is a
performance lose.

Basically, if you *don't* add new primitives to tcl, AND you find
yourself writing more than a thousand lines of code, you're losing.
Rewrite the subroutines in C.

   I suspect than in a few years, perl may well be better known as a
   CGI language than it is as a sysadmin language.

:)  You mean it isn't already?

--

Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | The enemy of BOTH socialism and capitalism is mercantilism



Thu, 02 Oct 1997 03:00:00 GMT  
 Perl vs TCL (was: Execution speed of Perl?)

Quote:

> Basically, if you *don't* add new primitives to tcl, AND you find
> yourself writing more than a thousand lines of code, you're losing.
> Rewrite the subroutines in C.

That's really too simple a way of putting it.  You could easily design
a system with enough forms and other GUI components to require >10K
lines of Tcl.  This isn't qualitatively different from a system with 1K
lines -- if you picture your program as some sort of tree, making one
level much broader without increasing the depth shouldn't be a real
problem, either conceptually or (for Tcl especially) performance-wise.
I don't think any arguments about the number of lines of Tcl I have
would convince me to rewrite GUI code in C.

I would suggest the following way to tell if you are writing too much
Tcl code, for interactive applications at least.  Try and count up the
number of proc calls and lines of code that are executed for each user
action (keypress, button press, etc).  If you are calling more than 10
procs or executing more than 1000 lines of code, there is something
wrong with your design.  (For precise values of 10 and 1000 yet to be
determined.)

There are actually two problems with a system with too much Tcl code --
organizational problems and execution speed.  The organization will in
most cases benefit from extensions like [incr Tcl] and namespaces.
For execution speed, you might want to look at the ICEM CFD Tcl Compiler
(ftp:ftp.netcom.com//pub/ic/icemcfd/tclc) or other systems that will
increase performance in a relatively painless way.

Wayne Christopher ----------------------------

2600 Etna St, Suite 1       (510) 549-1890
Berkeley, CA 94704          (510) 841-8523 FAX



Sat, 04 Oct 1997 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Perl speed vs. Python speed

2. TCL Speed vs PERL

3. Speed of Python vs. Perl

4. Speed problems with Python vs. Perl

5. Yet another Python vs. Perl speed issue/question

6. Speed of Python vs. Perl

7. python vs. perl speed comparisons

8. Python vs Perl: benchmarking for speed?

9. PYTHON VS. PERL VS. TCL

10. Python Binding [Was: Re: PYTHON VS. PERL VS. TCL ]

11. jredford's flames and criticism (was: PYTHON VS. PERL VS. TCL )

12. THANKS: RE: PYTHON VS PERL VS TCL

 

 
Powered by phpBB® Forum Software