I do believe that both Perl/Tk and Python/Tkinter still use a Tcl interpreter to drive the Tk GUI. The Perl or Python interp is interfaced to the Tcl Interp. This is why these approaches are no more responsive (even slower?) from a UI standpoint, even though Perl and Python are generally faster languages than Tcl.
I believe that someone was working on a Tcl-less version of Tk, but that's not the one that everyone uses.
...for OO, GUI and Client/Server stuff in Tcl/Tk. If you need to do any of the previous, then read his stuff!
He created the [Incr Tcl] and derivative extensions. And in addition to the above book, he contributed a couple of good chapters to O'Reilly's excellent "Tcl/Tk Tools" - a compendium of Tcl/Tk extensions - which Harrison edited.
Python/Tk (called Tkinter) makes for a nice combination. You get Tk with the benefit of an OO language with real dynamic typing. Unfortunately it's no faster than Tcl/Tk. Here's a nice intro. [pythonware.com]
If your UI does not need to be crossplatform, pygtk [daa.com.au] may be a an even better choice. It has more widgets, is fast, and you can also write GNOME apps with the companion pygnome modules. (The pygnome package includes pygtk.)
I was involved in a commercial project that used Tcl. The experience says: use perl. You will regret using Tcl. You will hate it. You will fail deadlines over and over again. The system will be sluggish, and you can't do a thing about it, because it's Tcl's fault.
I mean, what do you expect from a language designer who distinguishes between untyped and statically typed languages? And either has never heard of dynamic typing or chooses to ignore it? Who thinks that "all the world is a string"?
Do yourself, your employer, and your customers a favor, and stay away from Tcl.
If you're interested in a language as fast as C++, but as nice as Python or perl, check out Dylan. A Gtk+ wrapper is under development. Gwydion Dylan [gwydiondylan.org] is even written in itself, you can't say this about Tcl, perl or Python.
Actually a lot of people like Tk and don't like Tcl, and that's why you can do neat things like using Perl/Tk instead of Tcl/Tk. Check out the O'Reilly books for more info, ie "Advanced Perl Programming"
I'm not an expert in how these languages are implemented, so I could be wrong, but anyway, here is a quote from the O'Reilly Book "Advanced Perl Programming" chapter 14 "User Interfaces with Tk", "Nick Ing-Simmons tried a more ambitious approach: he purged Tk of all embedded Tcl code and gave it a generic porting layer to make it easy to add other scripting languages; this effort is called pTk (portable Tk). To this, he added a Perl5 wrapper (with the intention of adding other language wrappers in the future)."
How does the book compare with the standard Tcl/Tk book, Practical Programming in Tcl/Tk
(2nd edition)?
I own both books. I find the Welch book to be a very good primer on using the language. McClennan/Harrison is a good book once you are up to speed on the basics. It covers a set of best practices from some guys who have written a lot of tcl code and in the process developed a set of useful techniques for Tcl programmers.
I took a tutorial from McClennan at last years Tcl/Tk conference that covered client/server apps in Tcl. It was the single most useful aspect of that whole conference. The tutorial was designed around the client/server chapter of the book and I bought the book as a result. The best Tcl/Tk book I've seen.
McClennan (author of [incr Tcl], founder of Tcl Consortium) was one of the most highly motivated and driven people I met at the conference. He ran more tutorials (one for each session) than anyone else there, ran the "Game Show" (including writing the software for it), and was also a conference co-chair.
He nows his stuff and, just as important, he know how to explain it.
First, it sounds like you were still using Tcl 7, not Tcl 8 (which no longer thinks the whole world is a string).
Second, there seems to be a great deal of evidence that Tcl/Tk can handle its own in the real world. Scriptics ( www.scriptics.com [scriptics.com]) maintains a collection of success stories.
Tcl's main advantage is the ability to prototype extremely quickly. It was originally designed as a "glue" language, but has been far more useful than just that. If you find some aspect that is too slow, you can recode that module into C or C++ (or even java for cross-platform purposes) and link it in.
Tcl is also widely used in QA test automation. Many web sites use it as a back end. NBC presented a paper at the Tcl/Tk conference detailing how they use Tcl/Tk to deliver satellite feeds to affiliates (they originally planned to just do the prototype in Tcl and recode later, but found that they only had to replace a small number of modules).
There are at least two debuggers for Tcl. One is from Don Libes, and comes as part of his Expect extension (although usable separately). See the Expect home page [nist.gov] for more info.
The other is the commercial offering from Scriptics [scriptics.com], John Ousterhout's company.
I'm sure if you check the Tcl FAQ you can find more. Check comp.lang.tcl.announce for the weekly summary postings, it will contain a link to the FAQ.
I believe Scriptics is coming out with a Debugger.. The alpha version is even out for free trial (last I checked). Check out Scriptics [scriptics.com]. (btw - Scriptics is the company Ousterhout founded to further his Tcl work.
The review is alright, but it doesn't really tell my how the book stacks up to the other Tcl/Tk offerings out there.
Also - Tcl is not Tk's "brother" or whatever it was the reviewer put. Tcl is a scripting language and Tk was an extension made to that for GUI pruposes. Tcl is the important piece and without it, Tk doesn't exist. I think the reviewer needs some more Tcl experience before he can give an informed opinion on what was important and what wasn't. Generally, most people are fairly ignorant about the power of Tcl, though..
Gosh, how about that FUD there? The last project I worked on, I used ISO C to collect data, perl for preliminary postprocessing, and Tcl/Tk for interactive final processing and display.
Would I want to use ISO C to do heavy string handling?
Would I want to use Tcl for batch-mode report summarizing?
Would I want to use perl for an interactive data viewer. (nb: perl/Tk is a bit hard to get installed on various random systems. The syntax is also not to my taste.
The chief point in all that appears above isn't that the answer is uniformly no; it is that the answer is a personal preference. What I'm most productive with is a function of my skill set and tastes. There isn't any data in what I'm replying to, just a lot of dire warnings. Bigotry over technology never got anyone anywhere.
Tcl might not have worked for this guy in this project. He hasn't given any real reasons why, though. Knowing how and why Tcl didn't work out might be interesting and useful.
Doesn't include any information on how to debug the lanuage perchance. I have spent long pleasure filled hours resorting to the good ole reliable puts (printf for those of the C clan)to debug it.
I would sell my soul and carpent lint for a decent debugger. Still though not as bad as the days when I was writting speech systems in TCL. Had to spent several weeks in a padded romm after that
What is algebra, exactly? Is it one of those three-cornered things?
-- J.M. Barrie
I don't think Tk exists without Tcl... (Score:1)
I believe that someone was working on a Tcl-less version of Tk, but that's not the one that everyone uses.
Someone correct me if I'm wrong...
Comparison with Welch's book? (Score:1)
They're both good books. Welch's is the expansive, complete reference.
Harrison/McLennan is more like the hot-insider-tips kind of book. It points out a lot of cool, but inobvious, things.
McLennan's *The Man*... (Score:1)
He created the [Incr Tcl] and derivative extensions. And in addition to the above book, he contributed a couple of good chapters to O'Reilly's excellent "Tcl/Tk Tools" - a compendium of Tcl/Tk extensions - which Harrison edited.
Beware of Tcl! Use Python instead. (Score:1)
If your UI does not need to be crossplatform, pygtk [daa.com.au] may be a an even better choice. It has more widgets, is fast, and you can also write GNOME apps with the companion pygnome modules. (The pygnome package includes pygtk.)
Beware of Tcl! (Score:1)
I mean, what do you expect from a language designer who distinguishes between untyped and statically typed languages? And either has never heard of dynamic typing or chooses to ignore it? Who thinks that "all the world is a string"?
Do yourself, your employer, and your customers a favor, and stay away from Tcl.
Beware of Tcl! Use Python instead. (Score:1)
Sure TK exists without TCL (Score:1)
quote from O'Reilly book (Score:1)
Comparison with Welch's book? (Score:1)
Comparison with Welch's book? (Score:1)
I own both books. I find the Welch book to be a very good primer on using the language. McClennan/Harrison is a good book once you are up to speed on the basics. It covers a set of best practices from some guys who have written a lot of tcl code and in the process developed a set of useful techniques for Tcl programmers.
TCl and Debugging (Score:1)
Must have book (Score:2)
McClennan (author of [incr Tcl], founder of Tcl Consortium) was one of the most highly motivated and driven people I met at the conference. He ran more tutorials (one for each session) than anyone else there, ran the "Game Show" (including writing the software for it), and was also a conference co-chair.
He nows his stuff and, just as important, he know how to explain it.
Beware of Tcl! (Score:2)
Second, there seems to be a great deal of evidence that Tcl/Tk can handle its own in the real world. Scriptics ( www.scriptics.com [scriptics.com]) maintains a collection of success stories.
Tcl's main advantage is the ability to prototype extremely quickly. It was originally designed as a "glue" language, but has been far more useful than just that. If you find some aspect that is too slow, you can recode that module into C or C++ (or even java for cross-platform purposes) and link it in.
Tcl is also widely used in QA test automation. Many web sites use it as a back end. NBC presented a paper at the Tcl/Tk conference detailing how they use Tcl/Tk to deliver satellite feeds to affiliates (they originally planned to just do the prototype in Tcl and recode later, but found that they only had to replace a small number of modules).
TCl and Debugging (Score:1)
There are at least two debuggers for Tcl. One is from Don Libes, and comes as part of his Expect extension (although usable separately). See the Expect home page [nist.gov] for more info.
The other is the commercial offering from Scriptics [scriptics.com], John Ousterhout's company.
I'm sure if you check the Tcl FAQ you can find more. Check comp.lang.tcl.announce for the weekly summary postings, it will contain a link to the FAQ.
TCl and Debugging (Score:1)
where's the comparison? (Score:1)
Also - Tcl is not Tk's "brother" or whatever it was the reviewer put. Tcl is a scripting language and Tk was an extension made to that for GUI pruposes. Tcl is the important piece and without it, Tk doesn't exist. I think the reviewer needs some more Tcl experience before he can give an informed opinion on what was important and what wasn't. Generally, most people are fairly ignorant about the power of Tcl, though..
Beware of Tcl! (foo) (Score:1)
- Would I want to use ISO C to do heavy string handling?
- Would I want to use Tcl for batch-mode report summarizing?
- Would I want to use perl for an interactive data viewer. (nb: perl/Tk is a bit hard to get installed on various random systems. The syntax is also not to my taste.
The chief point in all that appears above isn't that the answer is uniformly no; it is that the answer is a personal preference. What I'm most productive with is a function of my skill set and tastes. There isn't any data in what I'm replying to, just a lot of dire warnings. Bigotry over technology never got anyone anywhere.Tcl might not have worked for this guy in this project. He hasn't given any real reasons why, though. Knowing how and why Tcl didn't work out might be interesting and useful.
-BJK
TCl and Debugging (Score:1)
Doesn't include any information on how to debug the lanuage perchance. I have spent long pleasure filled hours resorting to the good ole reliable puts (printf for those of the C clan)to debug it.
I would sell my soul and carpent lint for a decent debugger. Still though not as bad as the days when I was writting speech systems in TCL. Had to spent several weeks in a padded romm after that