Let the flame war begin!
Am 16.12.13 17:10, schrieb Chris Angelico:
Here's the Tcl procedure that I tweaked. This is from gitk; I find the
word diff not all that useful, but a character diff at times is very
useful. I haven't found a way to configure the word diff regex through
gitk's options, so I tweaked it in the source code.
proc getblobdiffs {ids} {
global blobdifffd diffids env
global diffinhdr treediffs
global diffcontext
global ignorespace
global worddiff
global limitdiffs vfilelimit curview
global diffencoding targetline diffnparents
global git_version currdiffsubmod
.....
> }
I'm a long time Tcl developer who has just picked up Python recently; so
my view is tinted from the other side.
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.
First off, everything's done with commands, rather than assignment
("set diffinhdr 0"), which is very shell-style and not very
programming-style.
This is just syntax and purely a matter of taste.
Can live with that, though even shells can use
equals signs for simplicity. Similarly, the shell style of adorning
variable usage feels messy. There are string literals, some of which
contain interpolated variables; there are dollar-sign adorned
variables; and then there are other words. What are the other words?
Are they implicit strings (as they would be in, say, bash)?
Yes, they are, and it doesn't feel strange if you are used to it. Tcl's
syntax rules are very compact. Tclers see this as an advantage.
Secondly, what does this do?
if {$worddiff ne [mc "Line diff"]}
I *think* it means 'if $worddiff is not equal to "Line diff" (this
code is executed for the options "Markup words" and "Color words", but
what's the mc do?
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.
This is where, IMO, Python tends to be a lot clearer. It's easy to see
what's an object and what's a method on it, and every bare word is
either a local name or a standard built-in name. I'm sure Tcl's a
great language, but I'd rather not have to drop out of Python into it
if I can help it. :)
Python has some advantages over Tcl. To name a few, references, list
comprehensions, real classes, clean module support, extensive extensions
such as matplotlib/scipy. But 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:
* Stubs. Compile a C extension against 8.1 and load it into 8.6. This
actually works. 8.1 was nearly 15 years ago!
* 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.
* 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.
* 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.
Happy flaming,
Christian
[1] http://wiki.tcl.tk/12574
[2] http://wiki.tcl.tk/3963
--
https://mail.python.org/mailman/listinfo/python-list
