Re: TCL with Perl or Python?

Now that you mentioned web guis, tcl is far behind on this :-(

I want to add a small web gui to an existing app, and still I haven't found a solution...

George

O/H schlenk έγραψε:
I've also heard or seen a lot about how great Python is but what I
would like to know is just what are the advantages of using Python
over Perl when working with a gui created with TclTk (I use Vtcl to
initially create the gui).

When working with a Tcl/Tk created GUI there is no real benefit in
using Python or Perl.

There are some benefits to both Perl and Python, mostly if you have a
lot of people knowing Perl or Python already or if you need to use
some module only available for those languages. But otherwise they are
pretty similar.

Python has some nice spots, some language constructs are pretty nice,
but a lot of warts too. If you need x-platform stuff like Windows +
Unix you will find a lot of tiny warts on Python, things that just
work in Tcl and have you add if sys.platform = 'win32' all over your
code in Python. Perl is similar, they work on a lower level of
abstraction usually (but offer more control about those lower levels
as a benefit).

When using Perl or Python you basically loose the x-platform
convenience that are Starkits/Starpacks, so no single file deployments
for you anymore. Python has various similar solutions but none is
really cross platform or as convenient.

When you have a Tk GUI you also loose some ease of use, as the Python
and Perl Tk bindings (tkinter,Tcl::Tk) are not as nice for working
with Tk as the native Tcl bindings. If your not locked into Tk you can
explore some other GUI toolkits with those other languages, which
might be an interesting option if you target Apple systems and want
native Cocoa GUIs but forget X-Platform in that case.

I have to work with Python in my day job since two years, and have
done a lot of Tcl before and must say, Python feels like programming
with one hand bound on your back. Its more of a bondage and discipline
language than Tcl, there is a specific way to do things and you should
do it that way, or your code gets horrible complex, brittle and ugly.

One thing i think Tcl lacks is a modern, portable web framework (yes,
there is OpenACS, but thats not really portable as it is bound to
AOLserver), all the current options don't really play in the same
league as Ruby on Rails, Pythons Django and similar offerings. But if
you don't do web UIs, you couldn't care less.

A similar issue comes up with ORM layers, Python has various, e.g. the
nice SQLAlchemy system, but one reason Tcl might lack widespread
adoption of an ORM is that Tcl simply is not a pervasive OO language
like Python, so people are pretty okay with writing procedural code
sometimes. Tcl 8.6. with the new TDBC and the OO system might change
that in the near future though.

Where both Python and Perl suck is multi-process control or network
servers. Python without extra libs offers barely more than what the
BSD socket API in C would give you, which is pretty low level and hard
to work with. Even C++ with Boost libs is far better than that.
Because of that all the standard protocols in Python either use
Threads or are blocking by default and you need a huge beast like
Twisted or coroutine libs like eventlets to get a decent network
server built in Python. Don't let yourself distract by the toy
examples you see for Python usually, ask for the non blocking version
to see the uglyness.

Encodings are a mess too, at least in Python 2.x, Python 3.x basically
adopted the Tcl model (which Tcl copied from Java) where all strings
are Unicode and you convert on I/O. One plus for Python 3.x is that it
supports more than the Basic Multilingual Plane of Unicode, a thing
Tcl still lacks due to manpower implementing it.

If you work with time and date you will hate Python compared to Tcl
8.5 and newer. Tcl's clock command beats Pythons offerings hands down
in everything but speed. You don't have any reasonable timezone or
locale support for datetime in Python, your basically working with a
thin, non portable wrapper around C standard strftime() and
gettimeofday().

Threading is another issue with Python. It has a simple Threading API
in its stdlib, but for anything but I/O bound programs its totally
worthless due to a global lock around all data structures (in CPython
at least, the .NET and Java implementations don't have this issue),
Tcls message passing based threading is vastly better if you don't
have huge shared datastructures (that would be better in a database in
many cases anyway). In recent Version Python added the multiprocessing
module which offers some options to use processes instead of threads,
but its not really superior to e.g. Tcl with fileevent/open and
something like tequila or tcllib comm to communicate.

XML processing. Python offers xml in its stdlib via elementtree, but
if you know tdom for Tcl you will hate it. Its crap, does not even do
basic syntax checking (you can build cycles of nodes ;-)) and is a
memory hog. No xslt or xpath support either. There are external
modules that are better though.

Hashlib/Crytpo. The stdlib of Python does offer less options than
Tcllib, no crypto at all (okay, ssl for sockets/streams, but thats
it). But there are good extensions that add all you need.

File system utitilies. The Python stdlib offers quite some, but those
are so-so in usability. Newer versions are pretty okay, older ones are
near to totally worthless on Windows. Tcllibs fileutil, multiop and
related modules are pretty much nicer. No VFS support for python
either so no option for cute tricks there. They hacked something like
starkits with Python eggs (zip files), but those are not much more
than loading code and stuff from a zip file.

Security/Multiple Interpreters. Python offers a similar solution to
Safe Interpreters, its just deprecated and know to not work. Basically
if you try to embed Python in any app you have one interpreter and
just one interpreter. No way out. No chance to do one interpreter per
user models without big surgery.

The module system. Python offers modules, quite similar to Tcl
modules. They don't have stubs so you need to recompile all your C
extensions if you upgrade your Python core. Python couples namespaces
to modules, so if you have a module you have a namespace too, unlike
Tcl where those are distinct dimensions of splitting your code. Python
modules by default have no versioning, so you have a hard time to have
two versions of a Python module around unless you add that info to the
filename (like Tcl modules, unlike tcl packages).

So whats left over? Some low level stuff like mmap and ctypes (which
are pretty nice to have), decimal (for fixed precision math), a built
in debugger (pdb), a little more execution speed in benchmarks.

Value semantics. Python has both mutable and unmutable values by
default, very often using mutable values/references, with all the
gotchas that brings. One favorite gotcha are mutable default
parameters to functions. Makes it easier to build complex data
structures in Python, but makes it harder to debug sometimes.

Traces. Python does not offer functions like Tcls trace, but it allows
one to overwrite accessors for objects to achieve similar effects with
more code.

Documentation. Pythons docs look nicer and are a bit better organized.
Content varies a bit, some stuff simply lacks or is hard to find
(object model, super() and similar topics).

The main reason to use Python would be to use some lib not available
for Tcl directly like NumPy or similar things.

Michael
.

Relevant Pages