Movatterモバイル変換
[0]ホーム
Why not Tcl/Tk?
Tom Poindextertpoindex 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 programin those languages on occasion.>>Tcl>> Flaws:>> Only one data type: stringActually, many folks see this as a benefit. I think of Tcl's data storageas '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 tointeger and stays that way until you need it as a string again.>> Incomprehensible quoting semanticsThe 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 supportNo 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 whichadds current state of the art features like per-object mixins, filters.I still lament that fact the Incr Tcl was never adopted as a coretechnology :(>> can be SlowAgain, not since Tcl 8.0, which has on on-the-fly compiler and byte codeinterpreter. Sure, there are benchmarks that favor Tcl, Perl, Python, etc.In some benchmarks I ran many months ago (Brian Kernighan's benchmarks ofscripting languages *), Tcl places anywhere from last to first. A lot has todo with understanding the which operations are costly, and which can beeasily optimized.> not so good debuggingI'd have to disagree strongly here. First, since Tcl is so flexible, it'srelatively easy to rewrite Tcl core commands to instrument debugging. E.g.,you can easily include code that re-implements the 'proc' command to printdebugging 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 platformcode and network programming a breeze.Friendly newsgroup (Python has this too)Easy to integrate with existing C code, either natively orwith 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 modulesYep, 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 (Whynot 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 intoa proc, and edited for common coding techniques appropriate for Tcl 8.x.Seehttp://www.mini.net/cgi-bin/wikit/348.html-- Tom Poindextertpoindex at nyx.nethttp://www.nyx.net/~tpoindex/
More information about the Python-listmailing list
[8]ページ先頭