Why not Tcl/Tk?

Tom Poindexter tpoindex at nyx10.nyx.net
Tue Apr 3 23:21:43 EDT 2001


In article <9ad6r1$nt0$1 at saltmine.radix.net>,
Cary O'Brien <cobrien at Radix.Net> wrote:
>In article <8J2w6.3336$SB2.606281 at ruti.visi.com>,
>Grant Edwards <grante at visi.com> wrote:
>>In article <4211ctgvusgcma0c6ok1cpmjou98lv9714 at 4ax.com>, Alexander Kluge wrote:
>>>-How would you describe the major strengths and flaws of Tcl vs. Python?

Ok, I'm an admitted Tcl fan, but still follow Python, Perl, and even program
in those languages on occasion.

>>Tcl 
>> Flaws:  
>>     Only one data type: string

Actually, many folks see this as a benefit.  I think of Tcl's data storage
as 'late binding' - it's up to each command to interpret the data as needed.
Of course, since Tcl 8.0 stores data as string, integer, double, list, et.al.
internally.  So if you use a variable as a integer, it gets converted to
integer and stays that way until you need it as a string again.

>>     Incomprehensible quoting semantics

The rules are very simple, but sometimes not very obvious, especially in the 
case of callback of raw code.


>>     Roll-your-own control flow
>>     No OO support

No OO support in the core, but I heard the argument before that Tcl is the
*most* object oriented of all languages, since it has so many ways to do it! :)
Incr Tcl, Otcl, Object Tcl, Java-like, Smalltalk-like, and lately, XOtcl which
adds current state of the art features like per-object mixins, filters.
I still lament that fact the Incr Tcl was never adopted as a core
technology :(

>
>      can be Slow

Again, not since Tcl 8.0, which has on on-the-fly compiler and byte code
interpreter.  Sure, there are benchmarks that favor Tcl, Perl, Python, etc.
In some benchmarks I ran many months ago (Brian Kernighan's benchmarks of
scripting languages *), Tcl places anywhere from last to first.  A lot has to
do with understanding the which operations are costly, and which can be
easily optimized.


>      not so good debugging

I'd have to disagree strongly here.  First, since Tcl is so flexible, it's
relatively easy to rewrite Tcl core commands to instrument debugging.  E.g.,
you can easily include code that re-implements the 'proc' command to print
debugging information on entry, exit, etc.  GUI based debuggers like Tuba,
TkInspect have been available for years.  And most recently, the TclPro 
tools (debugger, etc.) that Scriptics used to sell are now open sourced.
If you're not using TclPro debugger for your code, download it now.


>> Strengths:
>>     Tk integration
>>     Lots of code out there
>>     Roll-your-own control flow
>
>      Event driven programming model.  Makes some 
>      network programming much easier.

Network *and* GUI programming easier.

>
>      Some libraries higher level (i.e. scotty/tnm) and sometimes
>      more portable between platforms.

A few other points that I would add are:
	The Tcl channel system (does not use stdio) makes cross platform
	code and network programming a breeze.

	Friendly newsgroup (Python has this too)

	Easy to integrate with existing C code, either natively or
	with SWIG  (again, a Python feature too.)

	Seamless Unicode support.

>
>>     
>>Python:
>> Flaws:
>>     No roll-your-own control flow
>>     Lots of GUI options
>> Strengths:
>>     No roll-your-own control flow
>>     Good OO support
>>     Lots of GUI options
>>     Simple syntax and semantics
>>     Library modules 

Yep, another nice Python feature is the 'batteries included' distribution.
Some Tcl folks are working on this, and it needs to be expanded, IMHO.

>>
>>>-Why do you prefer the one you use over the other?
>>
>
>I still use Tcl if I am in a hurry to get something working,
>but that is changing.

The original poster also posed the opposite question in comp.lang.tcl (Why
not Python?), so check out that thread too.


(*) Brian Kernighan's benchmarks are available from his home page at:
  http://cm.bell-labs.com/cm/cs/who/bwk/

Kernighan's Tcl code was written for Tcl 7.6, and runs fairly slowly 
even under 8.3.  To make a fair benchmark, the Tcl code should be put into
a proc, and edited for common coding techniques appropriate for Tcl 8.x.
See http://www.mini.net/cgi-bin/wikit/348.html





-- 
Tom Poindexter
tpoindex at nyx.net
http://www.nyx.net/~tpoindex/



More information about the Python-list mailing list