[Tutor] Python and Tcl/Tk

[alan.gauld@bt.com]

> If you say so... but it was John Osterhout who wrote that:
> 
> that you should use *two* languages for a large software

I think that is still Ousterhouts view but there are plenty 
of Tcl'ers who are going the dedicated Tcl route.

> later? Or was his statement then just his feeble defence
> for Tcl shortcomings until he had repaired them?

Ousterhout is not the sole owner of Tcl to the extent that 
Guido is for Python. He owns the core language but because 
that can be changed in Tcl its easy for add on facilities to 
be crafted in by "entyhusiastic amateurs"... BLT would be 
a good example.

> 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.

OK, but expect is a tool for robotically driving other programs 
not interacting at the code level which is what I thought you 
meant. Sun also have a bnch of networking/server admin tools 
written in pure Tcl, but many of them drive other tools under 
the hood so in the real worlds I might concede this one :-)

> > > You can do everything Tcl can in Python
> 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. 

In the sense that any Turing complete language can do so, yes. 
In that respect anything that Python can do can be done in 
vim macro language too - and I don't mean with Python built 
in as the macro language (have we ever mentioned that feature 
of vim before?)

> >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. 

In the last 3 or 4 years Tcl has leapt forward. I think it 
was the move to 8.x which was even more radical than Pythons 
jump to 2.x.

> thought OO features like classes only existed in extensions
> like [incr Tcl]. 

There are two main Tcl OOP extensions, and yes that is how 
they are implemented. The code looks very much like a C++ 
class definition but is, of course, just a single line of Tcl...

> cause compatibility problems with other Tcl/Tk libraries since
> they change the language, introducing scopes. 

I didn't say there were no issues! Just that the mechanisms 
are there and lots of experience to help use them.

> memory of horror stories from people who tried to use [incr Tk]
> widgets in applications that previously were "classic" Tcl/Tk
> apps.

I wouldn't use [incr Tk] personally, Tk already is in what Ousterhout 
calls an OO style and trying to wrap one OO paradigm inside another, 
different one, spounds like a really bad idea to me. But [incr Tcl] 
(which, for non Tcl'ers, is a Tcl joke on C++ since it means the 
same syntactically) I've used [incr Tcl] without problems.

> >Much smaller.
> 
> The ActiveTcl package at ActiveState isn't so terribly small

Yeah but has oodles of tools/extensions. Raw Tcl is only a 
few hundred kilobytes if all you want to do is embed it 
- see the tcl80.dll file that ships with python.

> Although that is true about Python as well.

Yes but its still bigger at the minimal level.

> So, how small does it get? Can it run in a PDA? 

Easily, but then so can Python, see the Palm version...

> Or are we back to stripped and/or old versions?

Not old versions but obviously the more extensions 
you add the bigger it gets.

> So how do you judge the vitality of the Tcl community today?
> Compared to Python? 

Like I say its a niche. Those who have settled for Tcl are 
actively using and developing it. Take a look at the traffic 
on c.l.tcl But I suspect Python is more active and probably 
has more users nowadays.

> For Tcl it seems to be downhill to me, like Delphi and soon
> Visual Basic. 

Delphi is actually growing again due to Kylix. But that will 
be short term I fear. VB, I suspect, is here for the long 
haul - unless Bill G leaves Microsoft!

> a lot of interest. Now, I don't hear a lot about it. 

Yes, it has settled into its niche. It has about 4 years 
advantage over Python so maybe in 4 years time Python 
will stabilize in a similar fashion. It also was radical 
in its day as being the first language designed fron the 
ground up to be embedded as glue inside another language 
application. I suspect the history books will recognise Tcl 
mainly for its innovation factor than for any long term 
staying power.

> Today, the mainstream is all involved in Java, C++ and C#.

And COBOL - still more programmers using COBOL than any 
other language...


> Python and Ruby as the slightly cooler and smarter options,

There are certainly far more active Tcl'ers than active 
Rubyists.

> and the little Lisp community is just like the good old HP
> calculator freaks in school. They will never die...

Indeed, and Smalltalk, and aybe someday Tcl...

> >Tcl does have native compilation (and
> Is this real native compilation to machine code, or is it
> py2exe style cheating?

I don't know, I suspect the latter. I don't see how you could
genuinly compile Tcl to machine code without an amazingly 
intelligent optimiser. But the key thing it does is convert 
types from strings etc and does seem to give much more of a speed 
up than py2exe achieves. I think its a combination of Pythons 
bytecode compiler and py2exe - but thats guesswork based on 
observed results not any inside knowlredge.

> >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?

I don't think its bad, its just another way of working. 
Forth did exactly the same. In fact, thinking about it, I'd 
say Tcl is like a modern version of Forth. Probably the 
best description I can come up with.

> <talking of embedding macxro languages>
> of money, what is the main advantage with Tcl compared to
> Python? Python swims in this water too, you know... ;)

Tcl is, in my experience, easier than Python to embed.
But not that much easier. Its comparative and subjective.
If you have already done it with Python and not woith Tcl 
then you might get the opposite result!

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

Yes, an old list and hardly objective :-)
The Ruby gang have a similar list on their web site...

> programs that work more or less like expect. I don't think
> they work under Windows though, but does expect?

expect does work in Win32 yes.

> Python is no speed daemon, but Tcl is worse. 

This is true, Tcl is slow.

> Does Tcl have application development frameworks like Zope or Twisted?

I wouldn't be surprised but thats not how I use Tcl 
so I haven't looked.

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

There are certainly numerical processing libraries 
like PyNum etc. Dunno about the others mentioned.

> 8. Easy to learn
> 
> Hm... I've heard that about Python.

Python is *much* easier to learn than Tcl.
Tcl has some really obscure rules about what gets executed when.
Thesecare necessary because of its single line/command philosophy 
but it forces beginners(and experts!) to think like the interpreter. 
This is not a good learning environment - unless you are 
learning about language interpreters!

In summary, Tcl is good for a small set of problems. For an 
even smaller subset it may even be better than Python. But I 
see no compelling reason for anyone to learn Tcl other than 
that it offers an interesting alternative style of programming. 
The same is true of Lisp or Smalltalk.

Alan g.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld/