LV wrote: Perhaps the community could contribute tips, references, etc. comparing and contrasting Python and Tcl to provide someone who programs in Python assistance in learning to read/write Tcl?
VK My vision of comparing is to start with a following road (feel free to change it and expand on each item in turn, shorten list or adding more items):
Python has all the Tcl data types, and has had the equivalent of dicts for some time. 'Everything is a hash table' is perhaps what you could say about how Python's object system works.
Python has OO, Tcl does not. This means that all Python extensions can utilize and build on one OO system rather than having to deal with the fractured landscape that Tcl has.
Python is used for all kinds of things - possibly a little bit less for quick scripts, as it's certainly slower to write some things in Python than Tcl. Tcl's socket abstraction is, IMO, the best in the business for example.
Aside from the very high quality ActiveState tools, I do not believe that any of the Tcl tools are maintained much. Python didn't have much until recently, but I believe there are a number of nascent systems that are fairly high quality.
Tcl's C API is more extensive, and IMO, nicer than Python's. It lets you access more of the underlying system.
Tcl's extremely flexible syntax lets you add new control structures. You can't do that in Python. Since Tcl is merely a series of function calls, one can use Tcl's proc to replace or extend functionality, or to add new functionality.
Probably about the same. Tcl runs on some things like Cisco, although it had to be heavily modified to do that. Python runs on some things like Nokia cell phones: [L1 ]
Tcl, when it gets things right (sockets, event loop, regexps), has a higher level API that really hits a sweet spot. Python has much more functionality available to it, is very popular and is growing in popularity. Tcl's implementation is nicer in some ways. Things like i18n and threads tend to be 'done right', and are less intrusive than in Python.
Sarnold I have tried writing a small tutorial, while reading the beginning of the Python tutorial. I have abandoned it, because it was not the subject of this page.
Sarnold All right. In my personal experience, I always used Python for small tasks, so I am not the person who would comment it for large tasks.
I just noted there was overall more than 300 modules in the standard distribution, part of them being platform-specific.
About OO : Python has by no mean the simplicity of snit, nor the mixins, filters of XOTcl. The multi-thread stuff seems not to be as well handled in Python than in Tcl.
On the other hand, Python users can create new types with UserDict, UserList and so on.
I made some quick'n'dirty perf comparisons between ActiveTcl8.5a3 and Python2.4.1. The results show that Tcl is not so slow. Setting a variable, looping or sorting a list is done in quite the same time.
LV Okay - compare what comes in Python with ActiveTcl - what important functionality is missing? What could/should be added to ActiveTcl to bring them nearer to the same level of out of the box functionality?
SS I don't think we should compare against ActiveTcl because Python is distributed with all this modules inside the .tar.gz file. So it's not the case of a batteries included distribution. All the libraries are *part* of Python.
LV I understand. For things to be added to Tcl, a TIP needs to be written, argued, approved, and implemented. On the other hand, to add something to ActiveTcl, one need only convince the maintainer of ActiveTcl and find an implementation that uses TEA.
So it seems to me that changes to ActiveTcl might be more likely to occur in the short term.
And it still seems fair to me to compare the two - because ActiveTcl is a single file release of Tcl, which includes the tcl interpreter and extensions. And what one downloads from python.org is a single file download of Python, which includes the Python interpreter, and, if the person building it so desires, a series of extensions. However, the Python can be built without extensions.
For that matter, if someone wants to, feel free to compare the functionality of Python, with no extras configured, with Tcl out of the box.
The issue I'm trying to address is this - if someone who has to write some app considers Tcl vs Python to determine a language, how are things going to compare? Most importantly to me, What functionality is missing in Tcl?
davidw ActiveTcl is great as far as it goes (I've been very grateful for it when forced to use Windows several times), however, the vast majority of Tcl installations out there are not ActiveTcl, and people do take that into account when creating packages on top of Tcl.
RHS It's fair to say "Well, the base Python dist comes with all these packages. You have to go get the batteries included dist of Tcl to get the same". However, it's also fair to say "Well, the core dist of Tcl is lightweight, and you can't get a lightweight dist of Python" (or, would that be you have to go get the lightweight dist of Python? I don't know the answer). The idea is that it's a design philosophy, and the two languages made different choices. Just because one person holds that one of the choices is better does not mean that someone else might not feel the other way.
davidw Seeing as how Python is being distributed for cell phones of all things, presumably where there is a desire to cut it down, it's possible. Meanwhile in the non cell phone market, most people seem pretty happy to have a very capable tool rather than having to fetch a bunch of separate packages. When the less knowledgeable go to compare Tcl and Python, they may very well be comparing what they find on their Linux box, which is a cut down tclsh with no OO vs Python and all its packages.
SS Also maybe it's worth to note that Python's distribution is organized in a way that extensions are stored into a separate directory, and they don't share code with the Python's language core. It's like to add a directory 'extensions' in the Tcl tar.gz with populare C extensions, and let the Makefile to compile-install even those extensions, and not just the core language. So this does not affect in any way the ability to get a little Tcl install. It's also possible to disable from configure the compilation of some extension if desidered.
Sarnold IMHO it is highly desirable that the Tcl core has a small memory footprint ; perhaps should we add mmap, atexit and some compression formats that Python has.
Kevin Walzer Having just released a Python application that makes use of Tkinter, after releasing three or four Tcl/Tk programs, I can say that Python is a heavier language: probably more robust out of the box because of its standard library, but also more complex to work with (threads are almost essential for GUI programming; fortunately Python handles threading gracefully), and more complex to deploy in terms of standalone applications. Python's deployment tools (py2app on the Mac, and presumably py2exe on Windows) produce much larger applications, in part because Python and Tcl/Tk have to be bundled (if you are developing a GUI using Tk). Starkits and starpacks are simpler and smaller. On the other hand, there are some things that simply can't be done in Tcl that Python could do with either its core language or extension: for instance, an SFTP client can be done in Python, but not Tcl. So it's a matter of the right tool for the job.
DKF: [L2 ] is interesting because it throws up a list of things that people feel are wrong with Python when they're not engaged in a pissing war with Tcl. :-) In particular, many of the things that they feel are problems (e.g. threads, extensibility within the language, extensibility from foreign code (C), redistributability) are Tcl strengths. Given all that, I'm not too worried about things... :-)
AMG, hoping he doesn't get too far off topic: Lately I've been busy extending a Python program I wrote to read in a "Tcl-formatted" data file and spit out predigested hunks of C, C++, FORTRAN, and myriad custom formats to be read by a variety of programs on a variety of operating systems. It performs extremely well, and I'm very happy with it... except for the Python bit.
I wrote the first version in Tcl, and it was short and simple but no less powerful, but I was forced to rewrite it because the Engineering Review Board categorically said no to Tcl. The reason the Python version is just as powerful and easy to extend is that the input data is "Tcl-formatted", meaning that its syntax is precisely described by the Endekalogue sans substitution. It's pretty cool to be able to say "see the man page Tcl(n) for syntax" rather than having to write it out myself. Leveraging an existing standard whose documentation is already installed on nearly every Unix machine? What a concept. But on the down side, I had to write my own Tcl scanner; at over one hundred lines, this is the largest part of the whole program. (I did it as a state machine that reads one character at a time and never looks backward or forward.)
Just as in Tcl, semantics can differ from application to application; I have a different "commands" for defining airfields and for defining visual models. Similar to slave interps, the commands differ from context to context, e.g. "state" only fits inside a "switch" block, and "switch" only works at toplevel or inside "model", but the toplevel "switch" contains a few extra commands. That set of commands is defined in the Python script by classes, but those classes are really just Tcl commands in disguise. Inheritance is very shallow and only used to borrow methods that aren't being reimplemented, and the only important methods are set() and get(). A couple functions are used to manufacture classes with special properties, for instance the ability to handle basic types like integers and reals, accept multiple "arguments", be "called" multiple times, or have a default value. I believe GPS wrote a Tcl object system that works in much the same way, where procs can be used to augment the properties of objects. [add reference here]
On the Tcl side of the translation, everything is a string. I don't need to go into how nice this is. But on the Python side, type conversions are manual. Therefore set() reads in lists of strings analogous to command arguments, and get() returns the same data in a format Python can actually use. (set() is like a Tcl command invocation, and get() is for Python to get the invocation's return value in the right Python type.) The Python script then collates the data into whatever output format was requested on the command line. Since the "compilation" was so easy to write, I have time to make the output formats nice, comments and all. For example, the C output is ready to be fed into doxygen.
I tell you this story because it has given me cause to compare the two languages and to figure out how to make them work together. True, the "Tcl" in this case isn't really Tcl because it completely lacks substitution, but it does come close enough for my purposes. It's amazing how Tcl remains useful even after removing items from the Endekalogue! Seriously, the amount of code I had to write to interface the two languages shows their differences.
Tcl is very dynamic because "everything is a string" offers limitless flexibility. This is the #1 thing I miss when using Python. Here's a telling example: If I want to look up a variable by name, I have to say locals()[an_expr_that_evals_to_the_name]. At least I can do it, unlike in C. But the syntax is clumsy. Because the syntax is clumsy, Python programmers don't often consider "metaprogramming" approaches; they won't even think to loop over a list of variable names or components of names. Writing expressions that evaluate to names, while possible, is harder than simply duplicating the code and manually substituting in the correct names. I know; I was there. Lack of automatic type conversions also is quite a headache to me; 5 + 5 == 10, yet "5" + "5" == "55". As a Tcl user you may look upon this with disgust, but those of a different faith may think it to be quite marvelous. More on this in the next paragraph:
If one assumes that inheritance-based object orientation, enforced types, enforced structure, (enforced indenting!), and a procedural approach are the only way to go, then Python is a great choice. Take away those assumptions, and Tcl becomes an option. Not only does it become an option, but also it becomes a superior option. Let me explain why. Someone who is able to eschew any of the concepts I listed is someone who is capable of appreciating Tcl's strengths.
And the last thing I sorely miss in Python is functional programming. Sure, Python pretends to have functional programming, and it's certainly possible to do functional in Python, but the in-place semantics of lists and dictionaries ruin the whole thing for me. list.sort() returns None and changes list as a side effect. I have to explicitly make a copy, an operation that takes multiple statements: new_list = old_list[:]; new_list.sort(). I can't do all that as part of a single expression without implementing my own sort function.
In that last paragraph I mention one thing about Python that I do envy: None. See null for my reasoning.
iu2 I agree with all that, and I think too tcl is much more flexible. However, there are some features that make Python realy fun to use. One of them is just the "Python pretends to have functional programming" thing. I've written a whole page about it - Commands pipe. List comprehensions are fun, so is Python's indentation (to my taste, many disagree) which elminiate the need to end blocks, and makes it feel like writing less. Many places mention Python's clean syntax. Python's syntax is not about cosmetics, but rather about psychologicaly - having a pleasant time coding. I also think that many coding patterns found in extensible languages like tcl have been imported to Python (up until version 2.5): Partial functions (tcl's commands prefix), with statement (like Common Lisp), list comprehensions (haskell), ternary operator, generators (provide a means of closure), lambdas. lanbdas! How many pages are there trying to import lambda into tcl? tcl got apply just recently.
I do prefer tcl over Python, though. I think syntax extension is a powerful thing, which puts behind other languages that don't have it.