C
Chris Angelico
Let the flame war begin!
I'll try to avoid flamage
First off, gitk is a huge unstructured mess. You are not obliged to write
programs like this in Tcl, at least not today. All these global statements
give already a hint, that this is a procedural thing. Think of Python, where
classes are stripped. Tcl has object oriented frameworks for years. If you
use Snit, e.g., all those globals are not needed because they are really
instance variables.
Ah, okay. Don't take gitk as representative. Got it. Unfortunately
there are quite a few languages that I've experienced from, really,
only one program that I've tried to modify (Scheme almost falls in
that category too - all I've ever used it for is LilyPond scripting,
and not much of that), and I'm aware that's not really a fair look at
the language.
This is just syntax and purely a matter of taste.
Yeah. Like I said,
.. But my rule of thumb with bash scripts is: If it exceeds a page or
two in length, it's probably time it got rewritten in an application
language. When a program is the size of gitk (>10KLOC), the benefits
relating to interactive use (as you mention below) become less
significant, and benefits relating to discoverability of the more
obscure features become more significant.
It does command substitution (indeed the brackets [] do) and is one of the
key concepts of Tcl. mc is probably the command from msgcat which translates
i18n strings. Complaining about these basic things is like complaining about
indentation in Python.
Okay. Now, how am I to figure out where this command comes from? It's
not a host command (typing "mc" at the bash prompt comes up failure),
and it's not defined in the script itself (at least, I can't find
"proc mc" anywhere); is it a Tcl built-in? Where do I start looking?
(Yes, I'm aware this is a problem in any language. I'm not now raising
a point in the Python vs Tcl debate, I'm just asking out of
curiosity.)
Tcl also has some strengths.
First off, the syntax is quite flexible, and so things like list
comprehensions[1] or classes[2] can be implemented in Tcl itself. Second,
it's great at interactive use because at a command prompt, you don't want to
type all those () call operators, "quotes" and obey indentation just to get
a simple loop running. Third, its implementation features a few unique
things:
Yeah, that's nice for the interactive interpreter... but I already
have bash for that, and Python's not far off. I've used interactive
Pike and REXX interpreters, which are both more demanding than Python
(in terms of syntax requirements and such), so I'm perfectly happy
with Python; but if you're used to something even lighter, then sure,
use something that lets you type almost nothing. No problem. I just
think that - as mentioned above - a ten thousand line program should
be aiming more at maintainability than ease of manual typing.
* Safe interpreters. Sometimes requested here for Python, you can create a
slave interpreter in Tcl that is restricted and cannot do disk I/O, has
limited execution time etc. You can precisely control which commands are
passed on to the slave.
Cool. Not enough for me to choose the language unless I really REALLY
needed that feature, but there was one time in my programming career
when that was true, so we'll count that a win.
* Interpreters in threads. There is no GIL, Tcl interpreters are thread safe
and more than one can coexist in a process and run concurrently. This is
accessible from script level through the Threads package.
Nice, though Python's threading and/or multiprocessing can do 90% of
what people want. Side point: What about Tk? Can you (a) run separate
GUI threads for separate windows? (b) manipulate widgets created by
another thread?
* Very easy deployment: Starkits/Tclkits bundle an interpreter within a
single executable. Similar to what pyinstaller does. But in my experience,
it's much easier to pack all dependencies into a starkit than it is with
pyinstaller. You can get a rather full-fledged interpreter with GUI support
into a few megabytes, and I've never seen it fail.
Never really needed this, but for the people who do, I'm sure that's a
fairly big deal.
So there definitely are some advantages that Tcl has over Python. Put
against them is a superior object model, a large corpus of first-class
object types (dict, set, list, etc[1]), and a syntax that more clearly
differentiates names and strings without making variable references
look like a lot more than they are.
Huge room in the world for both languages to exist and thrive.
ChrisA
[1] What is an etc() in Python?