Why not Tcl/Tk?

Cameron Laird claird at starbase.neosoft.com
Tue Mar 27 11:31:40 EST 2001


In article <8J2w6.3336$SB2.606281 at ruti.visi.com>,
Grant Edwards <grante at visi.com> wrote:
			.
			.
			.
>Tcl 
> Flaws:  
>     Only one data type: string
>     Incomprehensible quoting semantics
>     Roll-your-own control flow
>     No OO support
> Strengths:
>     Tk integration
>     Lots of code out there
>     Roll-your-own control flow
>     
>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 
>
>>-Why do you prefer the one you use over the other?
>
>I gave up on Tcl after one program and switch to Scheme.  Now I
>use Python a lot more than Scheme.
>
>[I don't know much about eithr on Win32, so I'll let others
>answer those questions.]
			.
			.
			.
Grant of course does fine on his own.  I think a few
footnotes are pertinent.

We mention in <URL: 
http://www.sunworld.com/unixinsideronline/swol-02-2001/swol-0202-regex.html >
that Grant's footnote alludes to the single most crucial
difference between Tcl and Python:  the latter's current
support of and integration with Win* is far superior.

Grant is absolutely right in repeating that, in case after
case, the same characteristic has both advantages and
disadvantages.  To further complexify his calculations,
I'll testify that many Tcl and Python application developers
aren't even aware of the control-flow philosophical
differences between the two languages.  Many programmers
spend their time with rather conventional procedural or
OO concerns, and are quite indifferent to metaprogramma-
bility or introspective capabilities.

I respect that Grant doesn't like Tcl quoting.  There
are, however, equally sane people who applaud it.  It
seems to be an ... ambiguous distinction.

Among the benefits Tcl has over Python that are easiest
to appreciate by the mass of application developers are
the former's [exec], [open], and [socket].  They allow
for succinct, portable interprocess communication that's
simply not as polished (at that level) in Python.
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html



More information about the Python-list mailing list