This is a page for me to outline a 45 minute talk I am giving this summer on Tcl/Tk


  • What is Tcl/Tk
  • A sample "Hello World" program
  • Tcl provides rapid and easy development
  • Perfect for hacking, democracticization, prototype
  • I will show you why

Niches (easy to grok)

  • GUI scripting repetitive tasks on deployed *nix boxes (tksoup)
  • GUI targeted interactive things (tkdiff, gitk, tksed, rmimg)
  • Input / output multiplexing (tkaggfifo, organic farm product multiplexer ("veggieserver")?)
  • Driving hardware (original niche)
  • Metaprogramming and extensibility (callbacks on steroids)

List of other big users

  • Funny but ... AOL
  • Eggdrop

Objections and rejoinders

  • Syntax is weird (prefix, deferred eval, minimal -- all good things)
  • Slow/ funny looking GUI
  • Libraries
  • Web programming
  • Limited data structures (use a database or C, new OO for abstract data types, tcllib data structure packages, etc.)

How to write Tcl/Tk scripts

  • Simple filters
  • Simple interactive with global
  • Bigger interactive with models, upvars, traces, vwait
  • Download skeletons HERE

Cool miscellanea

  • Writing own control structures with uplevel and BREAK etc


  • Perfect for the people -- easy! powerful!
  • Download and start playing -- easy!
  • Resources

Talk Context

  • 45 minutes total
  • Sophisticated audience
  • Unix users
  • Skeptical about Tcl/Tk

Things Tcl/Tk does great

  • GUI
  • Event loop (file + sockets + GUI)
  • Deferred evaluation
  • Portability, especially across unices
  • Template with subst
  • C integration
  • Unicode

Complaints -- some fair, some no longer accurate, some due to ignorance

  • Syntax is weird: non-Algol (ignorance, plus people LOVE syntax for its own sake)
  • Slow (no longer)
  • Syntax is weird: names/ values versus variables (ignorance)
  • GUIs look weird because of Motif commitment (no longer)
  • Visual programming tools (true)
  • Object orientation (no longer)
  • Libraries (true -- need a libraries project)
  • Bad apache/ web server integration (true -- sorry tclhttpd and rivet)
  • Not cool like Java/ Ruby/ Haskell/ etc (true, but silly)


  • Hello World button, counting buttons
  • fifo/ barcode event scanner thing
  • tksed
  • postgresql over ssh

Possible new niches

  • Castoff unix boxes + custom doing appliance type work, e.g. counting guests at a soup kitchen with a keystroke "A" for adult, "C" for child, etc, and uploading the results somewhere useful
  • Simple interactive scripts, e.g. deleting files one at a time quickly (with a keystroke) after reading short info about thme
  • Medium size applications like gitk and tkdiff
  • Applications driven with a lot of custom callbacks like eggdrop
  • Lots more Unix machines around and they need a visual scripting language
  • Makers should be driving their things with Tcl/Tk
  • Templating language for apache (using something more like direct subst, not the rivet/ PHP knock-off syntax)
  • New programmers (change through cohort replacement)

Skeleton/ recipe for moderately complex (200 line) visual script

  • MODEL array
  • upvar proc's as callbacks
  • traces to update widgets
  • fileevents
  • vwait
  • overall code layout -- commenting style, code sections, etc.

Notes for using this later

  • All user groups need speakers -- hint, hint
  • Feel free to update, use, comment on successes and failures, etc

Links ...


  • Deployment
    • how is deployment a challenge? Of all the languages on the planet, Tcl is about the only one that has this one nailed because of tclkits, starkits and starpacks.
      • Recently it is not shipping on standard installations, like Free Geek's Ubuntu.
      • Also, I think the starkits whatever is a little confused still
  • Libraries (the community needs a Tcl/Tk library project)

LV I have a question with regards to this last point. What kind of "tcl/tk library project" do you have in mind? Are you talking about one web site at which everyone who ever wrote a piece of tcl registers where their code is located? Or perhaps more along the lines of a CPAN? It seems unlikely that all developers would decide to use a single web site for their development. So I presume that you are talking about something like CPAN, where a copy of a developer's work is maintained. Certainly teacup is an example of a centralized source and/or binary repository that exists in the Tcl community. Other than that, several people have tried to build a central clearing house where a program or extension would be registered and would point to the authority, but for whatever reason, most developers do not appear to use either the Tcl specific ones (like CanTcl) or the public sites like freshmeat.

  • I think that a TIP like process for adding new libraries would be neat, such that a single library gets "blessed" as being "in the core" for a particular application. There needs to be discussion about inclusion, but also a process whereby existing libraries get incorporated once there is consensus. I think "more than one way to do it" is really, really bad in the case of libraries (and widget sets!), and would want something more like the Python library than the Perl/ CPAN model. Tcllib seems pretty haphazard, to be honest, with some packages that should be elevated to core and some that should be relegated to something like a Tcl forge. (Activestate does some of this work too for their "batteries included" distribution.)

LV But the TIP process is already available for proposing, then including, a library into the Tcl core. In Tcl 8.5, we've already seen the large math library go in like this, zlib is in the process, etc. If there is a specific Tcl package or library that someone wants to work with the TCT to include, the process has been defined.

However, what I do grant you is that the philosophy of the Tcl core is definitely not let us just include every library and tcl package that anyone has ever thought about writing.

That, however, is not a library project issue. That is an issue of what is appropriate to include in the Tcl core or perhaps one could refer to it as Batteries Included vs small core?

There are lots of libraries. Some are maintained. Many are not. However, the number of people banging at the door to contribute new code to add functionality to Tcl is not so large that there are spare resources for adding dozens of libraries.

Fabricio Rocha 08-Apr-09 - Hello, Webb. As you said you would like to have some comments from the community, I would like to suggest you some things. In the "complaints" section, I think that the lack of visual programming tools is a candidate -- even though lots of people think that Tcl/Tk is so simple that it would not need it, those tools are usually expected nowadays (I am actually getting my hands dirty with that, but it's a long way to go). Also, if the "complaints" section is something like myths-to-destroy, maybe you could mention the Tk's Motif trauma which is still so-much spread, and present Ttk as the current answer. And in the "things done great" section it would possibly be good to mention the above-average portability Tcl/Tk provides.

By the way, "granpa might be old, but he can still kick your ass" was great! :)

RS 2009-04-08: Re "syntax is weird", see Why is TCL syntax so weird. In fact it's the most regular and systematic syntax (one might debate whether Tcl surpasses LISP here).

D. McC 2009 Apr 8: Easy to learn (for the most part); the most English-like programming language; not slow any more, even in terms of machine time, and often superb in terms of human time expended to get good results.

"GUIs look weird" isn't nearly as true as it used to be, but Tk/Ttk at its best still doesn't look as good--and isn't as easy to make look good--as GTK+ at its best. (At least, I think so, and I'm pretty sure I'm not alone.) A possible solution: gnocl now (in version 0.9.94) has attained a great deal of the functionality of Tk/Ttk, and combines the ease, versatility, and rapid results of Tcl scripting with the good looks and easy "themability" of GTK+. For those used to Tk, gnocl geometry management and widget commands take a bit of getting used to, but in some ways they're actually even easier than Tk.

WJG 08-Apr-09 I think that Tcl/Tk/Gnocl are the best kept secrets in the Opensource community. To be frank, Tcl is in great danger of becoming the "Rover" of the programming world. (For non-Brits Rover was a brand of car made in the UK which, in spite of its technical excellence, "died" because of the public perception of it. Rover was your "grandad's car", a motor driven by 60 year old men at 10 mph. Friend of mine lost their livelihoods because of such public predjidices. Let me ask, are the only users of Tcl old grey beards like myself or does it just seem like it?

If the age of the technology was the issue, then *nix's of any flavour should have been dumped a long time ago in the light of something else. But its still here, why? The excitement of it all. Fashion and public perception is everything. Godammit, just look at the QWERTY keyboard as method that should not have survived!

When I made my presentations on Tcl/Gnocl at LugRadio 2008 I patiently listened to a people struggling with Python and Perl and Gtk bindings saying thinks like, 'Oh, yeah. I've heard about that... antiquated language' and, because they wanted to feel 'hip' or 'cool' preferred to struggle on. Maybe that was the attraction? Tcl needs more passion putting into it, a champion, a voice, not a committe.

What is the strength of Tickle? Tcl. What limits its growth? The availability of support for other graphics packages.

Too many scripters spent their time trying to do wonderful, yet pointless tasks with scripts when the effort could be better put into tasks such as blogging, buildling bindings to other packages and championing and evalgenlising their preferred package. Just add some vowels to the name of the package, to make it more accessible. See what happens. If I were to capture the spirit of Tcl it would be to say: "Develop Once, Deploy Forever!". Use C to build packages and extensions and then script on and on....

DKF: FWIW, Rover died because they didn't offer a product that was good enough given the price they charged.

WJG: Beg to differ there. It wasn't a matter of quality, or price, but public perception. Its related to the 4 "Ps": Product, Pricing, Placement and Promotion. The first two were fine, the last two were not. They tried for something upmarket with an established name. Instead they ended up with a 'grandad car'. They should have gone for something less elite and used one of the many other brands that BMC (the ancient British Motor Corporation) aquired in the past.

AM (9 april 2009) Could you guys elaborate on the statement above: "... but Tk/Ttk at its best still doesn't look as good--and isn't as easy to make look good--as GTK+ at its best." I am in no position to compare the two and my experience of the past couple of years is that GUIs (on Windows and Linux) differ greatly among each other. Windows used to have a specific style, but that is totally gone. Under UNIX there never was a common style and Linux presents me a plethora of styles ... For a simple person like myself there is no recognisable standard. I am not very interested in the detailed esthetics of styles and themes. I just want GUIs that look nice and do not stick out like a sour thumb.

WJG (14-Apr-09) Ok, if you're running on a Windows or Mac box then you may be happy with the theming what Tk has to offer, I was for over 10 years. It not merely an issue of 'looks'. In the 90's the Tk widget was as good as it could be and really was the most covenient way of developing a GUI in X. But, the offerings are pretty well the same today. Today, there are newer, more powerful widget sets out there with lots of developers making enhancement on a regular basis.For Linux users the Gtk/Gnome combination seems to be the most popular and platform developers like their apps to be 'compliant'. I want my Gtk apps to run like all others, to behave similarly, to have the same bindings, themes, native drag and drop, printing, access to the full range of Gnome resources and so on. Tk doesn't offer this. There may be visual similarity in some cases, compatibility? No. The more Tk tries to look like Gtk, the more complex the problem becomes to address changes. In the middle ages, there was an English philospher, William of Occam, who became famous for a dialectic technique now know as 'Occams Razor'. Basically put, he said that of all the possible solutions to a problem, the simplest and least complicated will be the right solution. Adding theming support to Tk is not trivial, adding Tcl support for Gtk is. To make new Gtk/Gnome features availble to the Gnocl binding is merely a code enhancement to expose the new properties and styles to the Tcl interpreter. For Linux/Gtk developers the question should be which language binding offers me the quickest and easiest way of building and maintaining complex and compliant GUIs? And the answer is, of course, Tickle!

WWS 2009-04-15 I am not going to include Gnocl in my talk because the point of the talk is that Tcl/Tk is quick. Explaining "Oh, there is this special GTK widget set that only works on Linux, that requires a special installation, ...." hopefully you get the point... Sorry Gnocl, you don't get to be in my talk, at least this year; if people like awkward they should stick to Java. Once I can I say "Oh -- in the resource database, set Theme = GTK and you have a GTK theme", THEN I will put it in my advocacy talk.

JSB: For the “Things does great section”, I would add to the Event loop (file + GUI) line sockets. Sockets are one of tcl’s very strong and easy to smoke other scripting languages areas. A few line minimal web server would be a good example as well.

Tcl in the real world…… We see tcl and tk used so many times as a starting point for a project or program. It’s been that way for years. Someone needs a quick GUI app, etc and they find a tcl/tk example on the web…. It looks easy to use so they code away and get it to work. Then they go to the book store, talk to their friends/other co-workers or do a google search and see that “tickle aint cool”. The fact that their app was easy to write and maintain and that tcl did a good job for what they wanted and needed is forgotten. Within a smallish amount of time, the code is perceived to be “bad” and needs to be re-written in one of the cool languages. All of their positive tcl experiences are long forgotten.

BTW - Are there any autos made inside the UK still? Pity if not :( WJG Just watch F1 motor racing! And then of course motors such as Lotus, Aston, Jensen, Bentley, Rangerover, Morgan, McClaren... all pretty **cool** motors, just none them for grandads! All are pretty slick motors and promoted well.

AMG: People like to complain about Tcl variables being weird, about how it's tough to remember when a dollar sign is needed. Well, I think Tcl is much more regular in the way it handles variables than languages like C (sometimes need a & when referring to the variable instead of its value) or PHP (always need a dollar sign), where context determines whether to act on a variable or its value. Context can be a complex thing to figure out. For example, in C it makes a difference if the variable is an array: the "value" of an array variable is a reference (pointer) to the variable. And in C++, parameters can be passed by reference as well as by address or value.

The only "problem" with the way Tcl does it is that it's different than many other languages. The benefit is that it allows the programmer to quickly distinguish between a variable name or variable value, without examining context.

  • The way I am think about is that there are two levels in Tcl -- names of things (referencers) and storage of things (referenced). In most languages, the reference is transparent and yields the referenced thing immediately; to prevent this, you need to quote. In Tcl it is the opposite. I think this is a really deep difference, automatically making Tcl more reflexive and self aware, in a funny way. I think Tcl is better -- the question is how to explain.

AMG again: Maybe do a side-by-side comparison of C and Tcl and show how Tcl exhibits a more predictable structure. Something like this:

C Tcl Comment
int a = 5; set a 5 "a" is variable name
int b = a; set b $a "b" is name, "$a" is value
int *c = &a; set c a "c" and "a" are both names
char *d = "a"; set d a names are used instead of pointers
int e = *c; set e [set $c] [set] can take value of variable with computed name
int f[] = {a, b, *c}; set f [list $a $b [set $c]]] [list] makes lists
printf("%d\n", a); puts $a no need to specify format; everything is a string
printf("%d\n", *c); puts [set $b] [set] can access or modify value of variable with computed name
printf("%s\n", d); puts $d names are used instead of pointers
printf("%p\n", &b); puts b names are used instead of pointers
printf("%p\n", c); puts $c names are used instead of pointers
printf("%p\n", &c); puts c names are used instead of pointers
printf("%p\n", f); puts f names are used instead of pointers
printf("%d\n", f[0]); puts [lindex $f 0] [lindex] extracts elements from a list value

But first you must show how commands are used instead of syntax.

  • You do know I am a Tcl user and believer, right? For the talk, I thought I would probably show a quick command, but go into some detail about the syntax, since these should be fairly sophisticated computer folks.

AMG: I'm not trying to convince you. :^) I'm just trying to offer you examples that may help you to educate others.

KWizzz 2009-04-08: I think you should also mention Tcl's stubs mechanism. This is what it sets it apart from languages (just look for libraries that are available only for Python 2.6 -- while Python 3.0 users still have to wait for them). With Tcl, I can simply upgrade to a newer version and enjoy dict or the new oo features while still having access to all the libraries. Hm, I also like the Starkits for -- more or less -- easy distribution of Tcl programs.

WWS 2009-04-08: If someone wanted to give me an explanation of stubs and starkits that I can use to a tough audience, I would be into it, but I don't think there is time and I don't understand them anyway.

AM (9 april 2009) Stubs are a way to load a compiled extension that was created for one version of Tcl/Tk into a Tcl/Tk shell or program that uses the Tcl/Tk library of a later version. The idea is that the extension can be made independent of the particular version it was created with. Technically it is done with smoke and mirrors (function pointers and a table of function pointers with a fixed ordering so that calling a Tcl function like, say, Tcl_Eval() is not done directly - that would create an intimate link between the extension and the Tcl library - but via an indirection, akin to what happens with dynamic link libraries (DLL) or shared libraries (.so)).

A practical example:

If you have an extension built against Tcl 8.3 (the version that was current some six years ago), you can still use that very same extension in Tcl 8.5 or Tcl 8.6 (which is what you would expect to be able to use today) - you do not need to recompile and relink it.

As for starkits and starpacks:

If you want to distribute your application, you need a runtime environment for that particular platform, say wish. You have a number of choices:

  • Have the user install a Tcl/Tk distribution and let him/her run your application as:
     % wish myapp.tcl
  • Create a starkit. A starkit is a single file holding all the source files, data files and (compiled) libraries in a form that a "kit-enabled" shell can run. Starkits are platform-independent (except for bits and pieces like compiled extensions). A starkit presents itself to the shell as an ordinary directory with subdirectories. A special "kit-enabled" shell is tclkit (or any of its variants): it packages the whole installation of Tcl/Tk in a single file. Thus, installing and running your application becomes (assuming Windows for the moment):
     > cd \
     > md myapp 
     > copy ....\tclkit.exe myapp
     > copy ....\myapp.kit myapp
     (Installation done)
     > \myapp\tclkit.exe myapp.kit
  • Create a starpack. A starpack is a combination of a starkit with the runtime "kit-enabled" shell into a single executable file. The above scenario becomes:
     > cd \
     > md myapp 
     > copy ....\myapp.exe myapp
     (Installation done)
     > \myapp\myapp.exe

In other words: using starkits and starpacks you simplify the distribution of your applications to the very basics.

DKF: The other advantage of the Stubs mechanism is that it allows better core developer control over ABI evolution, notably including the ability to support multiple versions of the ABI at the same time. This (which is wholly distinct from API evolution) is very useful as it means that old builds of extension packages can be loaded into up-to-date versions of Tcl. No upgrade treadmill required for Tclers!

WJG Maybe you need to determine what your audience wants to hear and their disposition towards Tickle? Sometimes IT professionals don't like the simple prefering to make everything about their subject arcane and secretive. In which case, talking about how Tickle along with its packages are the easiest thing ever, might come as some bad news. If, on the other hand, the talk focusses on minutia then, to use, salesmens talk, this is a features dump and does not express the user benefits of Tickle. My advice — keep it task based. Give a case study that is meaningful to you; something that you can visibly enthuse over; one which you can demonstrably prove the how the problem was solved quickly as the resources that might have required creating from scratch were there, waiting and ready to be used. I would also pitch the strengths of Tickle against the alternatives. Avoid the navel gazing introspection that is so commonly expressed by Tickle coders. Place emphasis about how it integrates with other packages, libraries and so on rather than how such and such a language expression is spoken in 'Ticklese'. I'n not an IT professional, in fact nowadays I predominantly teach languages (Chinese). Let me draw on this example. There is nothing more interesting to linguists (and I teach a lot of polyglots and language teachers) than talking about comparative-grammar. And that's all it is — banter. It goes nowhere. Tell your audience about contexts and how best the Tickle allows the best expression of certain ideas. Then perhaps, talk about the problems in doing it some other way. Believe me, 45 minutes will go in an eyeblink. Keep with the idea of presenting a case study, a problem solving task and, if the audience is as savvy as you indicate above, they will put two and two together and make for themselves the conclusions you want them to know.

Here's an example on a potentially big problem solved quickly taken from the Gtk Forums. One newbie asked:

Is there a easy way to open a shell in a vte terminal that can accept commands like (cd,ls,dir)?

And the reply....

How simple can this be? Just one line of code in Gnocl and that includes the window to hold it in too!
        gnocl::window -title VTE -width 500 -height 300 -onDelete {exit} \
                -child [gnocl::vte -backgroundColor #ffffdd] ]] 

How easier more can it get? Tickle -easy peasy programming!

I am not going to answer the above in context, but ... I think I am on the right track so far. I probably won't cover gnocl (not in core), or stubs (too complex for 45 minutes). I *will* keep it task based, though I hadn't thought in exactly those terms before.

Re starkits: you are using the "md" command above -- that is the first time I have ever heard of it. RS: md is in Windows shells (cmd.exe) an alias for mkdir (make directory). Is there a "task based" starkit tutorial somewhere online?