Slashdot Mirror
Effective Tcl/Tk Programming
Greetings, all, I'm back once again. After my travels into the world of Tk a few weeks ago, I've branched out to include its sibling, Tcl, in all its glory. Tcl, I have to say, reminds me a lot of Lisp, at least in its typelessness and fondness for lists. I do miss all the (()), though :-).
What's the book about?Generally speaking, it is designed as a sequel to any and all introductory Tcl books with a view toward more advanced and narrow concepts. The authors go through various parts of Tcl that the novice programmer might not use frequently, but the advanced programmer will find quite useful. The geometry managers are all covered in detail, so the advanced programmer can select the best one. The canvas widget, that all-purpose blank slate, is given quite a bit of room. The book even covers communicating with other programs on the same machine and through sockets. Most all aspects of Tcl and Tk are addressed to some extent, leaving few stones unturned. Of course, programmers on different levels and with different experiences will find different nuggets in here. Personally, I was well acquainted with the text widget, making chapter five somehwat redundant, but needed some help with communicating with other processes. YMMV. Generally, the book is composed of several large examples, with new features added in each chapter. There certainly is a great deal of code, relative to the amount of explanation, so a good grasp of Tcl is required. In addition, the final chapters deal with delivering a complete, cross-platform Tcl application to the marketplace, in terms of packaging and cross-platform compatability. There's a nice install program example, and plenty of cross-platform minefields mentioned.
What's Good?This book is excellent for any Tcl programmer who's looking to add one of the skills covered in this book to his bag o'tricks. If you want to know more about text widgets, or using Tcl as a front-end to other programs, there's plenty of explanation and example to glean from this book. If you want to know more about general Tcl concepts like the event loop or the geometry manager, there's still more for you. There are also plenty of concepts addressed that could be applied to other GUI efforts outside of pure Tcl/Tk. I wouldn't necessarily read the book just for those, but they are a welcome addition. The examples in particular are quite thorough, with extra code available that is not printed in the book. There's even an entire calander manager written that's quite full-featured. Any topic covered comes with not only text but plenty of code. Commercial Tcl developers will especially appreciate the emphasis on professional Tcl libraries and delivery. If you do Tcl for a living, you'll appreciate this book.
What's Bad?If you don't want to delve deep into Tcl, don't bother with this book. You'll end up having to deal with areas of the language you never wanted to know, and you'll end up frustrated. Similarly, I wouldn't recommend reading this from beginning to end unless you love Tcl. There are plenty of parts where the flow is bogged down by the endless obscure code, and if you aren't interested, you'll end up skipping it anyways. Skim the parts that you don't need now, and come back to them.
What's In It For Us?Since I know there are plenty of Tcl fans out there, I'm sure there will be plenty of interest in this book. As I said, if you're just starting with Tcl, hold off on this one. If, however, you've honed your Tcl skills, but need some extra help in some areas, this book is for you. Whether you're into sockets with Tcl or just want to use that text widget more effectively, you will find this book useful. I'm sure it will be coming off the shelf for reference much in the future.
To purchase this book, head over to FatBrain.com, and pick it up.
I know there is a Tcl debugger out there, Brent Welch talks about it in his "Practicle Programming in Tcl and Tk" -- that's the book I go by for my Tcl/Tk bible.
If you do decide to get that book, make sure you get at least the second edition (there may be a third by now, I don't know). My frist edition got a lot of love, and now it's loaned to my suitemate, but it's slowly dieing (pages falling out) from so much hard use.
Funny, all those AOLserver-based web sites (like the 18,000 hits/second that AOL serves) are using Tcl...
For example, take every version of Tcl and try sorting a list of three-digit extensions numerically. Be sure to include 008, 009, and 010. Explain the differences. Blah. That's not even an API problem.
Perl has its share of mistakes like that, but its share is maybe a tenth of Tcl's share, and Perl's problems are mostly in esoteric areas.
Jason, ejr@cs.berkeley.edu
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 is even written in itself, you can't say this about Tcl, perl or Python.
As a language, Dylan kicks amazing amounts of booty. It is as clear and readable as any language I have ever seen -- including Scheme and Python -- and it boasts an object system almost as powerful as CLOS. If you are interested in language hacking, Dylan is a *great* choice to contribute to, as you will be doing the free software community a tremendous service by helping this project.
But Gwydion Dylan it isn't quite ready as a choice for doing real development in yet. For example, it doesn't yet support dynamically linked libraries. I'm sure those features will come in time, but right now Gwydion is more of a demo to drool over than a real choice for development.
But Gwydion Dylan it isn't quite ready as a choice for doing real
development in yet. For example, it doesn't yet support dynamically
linked libraries. I'm sure those features will come in time, but right
now Gwydion is more of a demo to drool over than a real choice for
development.
It is certainly more than a demo. I'm doing real development in Gwydion Dylan on Linux. You have to be a little adventuresome and it does have some limitations, but it a great tool for doing a lot of stuff. The C foreign function interface is good, and getting better rapidly. Gwydion Dylan is certainly capable of writing applications like web servers.
Harlequin's commercial Dylan implementation for Windows, Harlequin Dylan, is definitely ready for prime time.
Peter
That is a bunch of B.S. Have you ever heard of the
90-10 rule. Tcl is fast enough for 90 percent of your code. If you try to write an MPEG decoder
in Tcl you are an idiot.
Yeah that gameshow was a blast. I hope the next
conference will include such funny stuff.
Plenty of commercial projects successfully use Tcl. Synopsys is moving all of their EDA tools over to Tcl. Avanti uses it as well and our internal CAD system is written in Tcl. All of them work quite well.
The best strategy is not to program in tcl/Tk
at all.
Gee. It's so effective you don't even have to buy or read this book..
Here is the correction:
Perl/Tk has no Tcl interpreter. Python does.
I am uncertain about some of the other bindings
such as Ada, Scheme, etc.
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.
Someone correct me if I'm wrong...
-- Mike Greaves
I have both but only use each for reference - i.e haven't read them cover to cover.
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.
-- Mike Greaves
...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.
-- Mike Greaves
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.
If your UI does not need to be crossplatform, pygtk 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 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.
Alpha??? It's in production, v.1.2 already.
-- Don't Tase me, bro!
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.
-- Don't Tase me, bro!
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) 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).
-- Don't Tase me, bro!
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 for more info.
The other is the commercial offering from Scriptics, 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. (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..
- 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
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
Regards Redemption