[Tutor] Python and Tcl/Tk

[Magnus Lycka]

At 16:00 2003-01-28 +0000, alan.gauld@bt.com wrote:
>Oooh, I have to jump to Tcl's defence here :-)

Good! I rarely meet Tclers these days.

> > Tcl is only intended for small tasks and to glue larger
> > programs (written in C or whatever) together.
>
>Not entirely true, the latest versions of Tcl can scale to
>quite large projects now it has OO and module support.
>But I do still favour Python for that role.

If you say so... but it was John Osterhout who wrote that:

"I think that Stallman's objections to Tcl may stem largely
from one aspect of Tcl's design that he either doesn't
understand or doesn't agree with. This is the proposition
that you should use *two* languages for a large software
system: one, such as C or C++, for manipulating the complex
internal data structures where performance is key, and another,
such as Tcl, for writing small-ish scripts that tie together
the C pieces and are used for extensions."

He wrote that in 1994 though. Maybe he changed his mind
later? Or was his statement then just his feeble defence
for Tcl shortcomings until he had repaired them?

A brief review of Tcl scalabilty and related problems would
be interesting.

> > It needs to live in symbiosis with another language, where
> > the "real" programs are written.
>
>Not at all true. there are many standalone Tcl scripts
>around, most famously expect.

I'd say that expect is a perfect example of what I meant.
Expect is used to provide access to other programs. It's
as glue as it gets! Sorry if I was unclear.

> > You can do everything Tcl can in Python
>
>This isn't true. In Tcl irts easy to redefine the bahaviour
>of the language at a level Python can't approach - redefine
>how the if statement works, or a while loop etc. Whether
>doing such things is wise is another matter entirely!
>
>Self modifying code is also easier to write in TCL - and
>the same caveat applies!

I was unclear again. Sorry. What I meant to say was that if
there is a problem where tcl can provide a solution, python
can be used to provide a solution as well. I didn't mean that
you would do it in an equally weird way. ;)

I'll make a reservation for embedded use where space is
an important factor. Python might be too big for some
applications.

This ability to redefine the way the language works is a
mixed blessing to put it mildly.

> > really tried, but it seems to me that using Tcl to interface
> > to  programs where you need to access and communicate with
> > complex data structures would be a little like trying to build
> > model airplanes with thick wool mittens...
>
>Not sure why you think that. Tcl can handle complex structures
>pretty well. Certainly C unions and structs are handled OK.
>And classes map to Tcl classes.

It seems Tcl has evolved a bit since I last looked at it. I
thought OO features like classes only existed in extensions
like [incr Tcl]. As far as I understand these extensions might
cause compatibility problems with other Tcl/Tk libraries since
they change the language, introducing scopes. I have this vague
memory of horror stories from people who tried to use [incr Tk]
widgets in applications that previously were "classic" Tcl/Tk
apps.

But I guess it's difficult to make *any* firm statement about
features in a language where you can change how the basic
building blocks behave in runtime.

> > On the other hand, I think Tcl is smaller, which might be
> > a good thing on a palmtop or in an embedded appliance etc.
>
>Much smaller.

The ActiveTcl package at ActiveState isn't so terribly small
though. But I assume that includes a lot that you can strip out.
Although that is true about Python as well.

So, how small does it get? Can it run in a PDA? With classes
and stuff? Or are we back to stripped and/or old versions?

>Too true, finding good Tcl books is not hard but there are few
>of them and the language is tending to outpace the authors.
>(But the same is true of Python book currency)

You don't need to develop the language a lot to outpace the
book authors if the newest books are four years old. Roughly
30 books about Python have been published after 1999. Regarding
Python, version 2.3 doesn't change as much as the previous
releases did, so it might be time for the authors to catch up
now...

But there ARE Python books that are fairly current, covering
version 2.2. The 3rd edition of the Welch book covers 8.2
though... Not too bad I guess, but if you don't want t brick,
and look for O'Reilly book for instance, I think you get
something like 8.0 which as fairly dated.

> > A fading star?
>
>A niche player...

So how do you judge the vitality of the Tcl community today?
Compared to Python? I seems python's growth is beginning to
flatten out. But I think there is a chance that it will make
another surge.

For Tcl it seems to be downhill to me, like Delphi and soon
Visual Basic. Not quite like Fortran, COBOL and good old ADA,
but it'll come...

In the middle of the 90's Tcl/Tk got a lot of attention--it
was a cool way to build Unix GUIs, and  Sun obviously showed
a lot of interest. Now, I don't hear a lot about it. I just
notice that it's alive from the fact that new Python versions
use newer Tcl versions for Tkinter.

Today, the mainstream is all involved in Java, C++ and C#.
The volume in free development tools is in Perl and PHP, with
Python and Ruby as the slightly cooler and smarter options,
and the little Lisp community is just like the good old HP
calculator freaks in school. They will never die...

>Tcl does have native compilation (and
>Java byte code support) in its favour too (as does Python
>via Jython and py2exe etc).

Is this real native compilation to machine code, or is it
py2exe style cheating?

>Which is the Tcl idiom. In that regard its a bit like Lisp
>which also encourages a fine grained functional approach.

Do you think this is good?

>In its niche (an embedded extensible macro language) it is
>still the best tool around IMHO.

Right, this is actually another niche than the glue and
Tk GUIs I mentioned.

Assuming we are in a normal computer, with a resonable amount
of money, what is the main advantage with Tcl compared to
Python? Python swims in this water too, you know... ;)

There is a list of top ten reasons to use Tcl at
http://www.tcl.tk/advocacy/top10.html

It has headlines as listed below. It's curious that Python and
Tcl seem so similar when you look at those headlines, and are
still very different languages, with a big difference in scope
in my opinion.

1. Rapid development

All they say here could as well have been said about Python. See 
http://www.ipd.uka.de/~prechelt/Biblio/jccpprt_computer2000.pdf
for an objective comparision. In that study, Python and Tcl
programs were more or less equally fast to develop, with just
a slight advantage for Python, but the Tcl programs used much
more memory and ran slower.

2. Graphical user interfaces

With Tcl, you only have Tk and it's extensions. It seems Tix
might be getting somewhere, but it still seems to me that
wxPython has much more features than Tk + Tix and others.

3. Cross-platform applications

I think there is a draw here.

4. Extensible applications

This is what Alan mentions above. Python can obviously do
this as well. I can't judge the respective merits of either
approach. In all honesty I never even did this with Python.

5. Flexible integration

Python works as glue, just as Tcl does. There are even Python
programs that work more or less like expect. I don't think
they work under Windows though, but does expect?

6. Ready for the enterprise

Here they claim that Tcl is the only scripting language with
"all the facilities needed for enterprise applications, which
include internationalization, thread safety, cross-platform
portability, great GUI capabilities, embeddability, Internet
support, and database access." Funny...

What is it that python doesn't have here?

Python is no speed daemon, but Tcl is worse. Does Tcl have
application development frameworks like Zope or Twisted?

Are there business libraries/toolkits etc like 4Suite,
ReportLab etc in Tcl/Tk?

7. Testing

I've certainly used Python a lot for this. It works very
well here in my opinion.

8. Easy to learn

Hm... I've heard that about Python.

9. Network-aware applications

"No platform has easier to use networking facilities than
Tcl." So, why are Zope and Twisted written in Python?
Where are the big Tcl network killer applications hiding?

10. The Tcl community

I can't compare the helpfulness or professionalism of
these two communities, but I know about the Python one...

If we look at the free software community, Freshmeat
lists almost 900 Python projects and a little over 300
Tcl projects. At sourceforge there are 600 Tcl projects
and 2100 Python projects. So, despite an longer time,
a period of fame in big business and a much earlier
inroad into the business world, it seems Python is much
bigger today.

11 BONUS: It's free!

Very unique! ;)


-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se