Am 16.12.13 23:40, schrieb Chris Angelico:
On Tue, Dec 17, 2013 at 9:06 AM, Christian Gollwitzer <aurio...@gmx.de> wrote:
Let the flame war begin!
I'll try to avoid flamage :)
:) So let's vigorously discuss about facts;)
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.
I do not know, whether bash has means to structure large programs, I
suppose not. Tcl has (see below), and concerning discoverability, see
also below.
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?
Usually, I run the program in tkcon, an excellent interactive shell for
Tcl. There you type "edit mc", and it shows you the definition, plus you
can change it, send it back to the program and see how the modified
program behaves now (without restarting it!) Under the hood, it executes
commands like "info commands", "info args", "info body", which do the
work. If it tells you that there is no such thing as "mc", it came from
a compiled extension (a C procedure). Indeed, in this case you are out
of luck, to my knowledge there is no info which extension loads that
thing. But you could observe it before startup by putting up a command
trace (some sort of callback) on "mc".
In the gitk case, mc comes from these lines:
package require msgcat
namespace import ::msgcat::mc
Now, be prepared: These lines do almost the same as
import msgcat
from msgcat import mc
would do in Python.
*What is this? I heard Tcl has no modules?* Don't listen to these
people, today (well, namespaces exist since 8.0, 1997, packages date
back further) you can use namespaces and packages to structure your
programs and separate data. And because Tcl is highly introspective, you
can ask about almost everything:
(src) 61 % namespace import
mc
(src) 62 % namespace origin mc
::msgcat::mc
(src) 63 %
(there is only one imported command in gitk, namespace import returns a
list)
About globals: Yes "global" gives you a true global, but namespaces have
namespace variables, which you should use instead. The awkward thing is
that you need to import these (as the globals) into every proc which
uses them, but by using an OO framework such as Snit, this burden is
taken away from the programmer.
Still Python *has* advantages here. If there is a docstring, you can get
help() about the unknown thing, it has a type() and in Tcl, the package
author is responsible for wrapping the package content into a namespace.
Something like "import Tkinter as Tk" is not possible in Tcl (well, you
could rename the namespace, but if not carefully written, it may break
the package).
* 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?
You can't run Tk more than once, that applies to almost every toolkit I
know. But you can pass a message to the main thread to do it for you.
This is quite easy; it looks like
thread::send -async $main [list doit $somedata]
You pass an arbitrary Tcl command which executes in the main thread as
soon as it is idle. In fact, because of the embedded event loop in Tcl
(not bound to Tk), you rarely need threads at all. Asynchronous I/O is
very easy in Tcl (fileevent command).
That one question here with replicating nc to control a device would be
a textbook example of fileevent usage in Tcl.
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.
Lists and dicts exist in Tcl as first class objects. You just can't tell
them apart from strings. Sets are in tcllib. Python is more strongly
typed than Tcl in that respect, which can be an advantage. Specifically
doing math is easier in an evaluation based syntax than in a command
based syntax, this sometimes sucks in Tcl.
Huge room in the world for both languages to exist and thrive.
Yes, you name it. I wish people who criticize Tcl would not use their
knowledge from 15 years ago; that beast has evolved. I'm not complaining
about Python 1.0 either. And I wish Tcl would be used more often for
large-scale programs, such that the idioms really develop.
Christian
[1] What is an etc() in Python?
Is this a quizzy question? I have no idea.
--
https://mail.python.org/mailman/listinfo/python-list
