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

Reply via email to