[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): * What are the basic data types? (hash/array/list/strings) Is everything an object? a string? 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. * How is OO different between the two languages? [Python] has one true OO and is heavily based on it; [Tcl] does not ship with an OO system, but it has many different types of OO as external libraries. What does this bring to language? advantages? disadvantages? (wiki has many about this; link to page would be good) Multiple inheritance? 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. * What is the typical usage of [Tcl]? of [Python]? of their combination? Is it Web, GUI, financial, physic computation? what? 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. * IDE: Several GUI WYSIWYG have been written in Tcl ([Visual Tcl], ...) 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. * IDE2: what debugger and ease of use tools are available? * What does it usually take to extend the functionality of an application? (as opposed to commonly used (mis?)conception that [Perl] programs are write-only) Tcl's C API is more extensive, and IMO, nicer than Python's. It lets you access more of the underlying system. * What does it take to extend the language itself? Is it possible? on the tcl/python level? C level? 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. * OS coverage. Both support many platforms. Which coverage is wider? 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: [http://forum.nokia.com/main/1,6566,1_49,00.html] * ''to be continued'' 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. ---- [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. [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 into a spearated dir 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. ---- [Category Language]