This is a page for me to outline a 45 minute talk I am giving this summer on Tcl/Tk
http://opensourcebridge.org/events/2009/proposals/24
http://tcl.projectforum.com/roadmap/Home
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/d6f ...
http://code.google.com/p/spiderhacks/
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.
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.
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.
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:
% wish myapp.tcl
> cd \
> md myapp
> copy ....\tclkit.exe myapp
> copy ....\myapp.kit myapp
(Installation done)
> \myapp\tclkit.exe myapp.kit > cd \
> md myapp
> copy ....\myapp.exe myapp
(Installation done)
> \myapp\myapp.exeIn 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:
And the reply....
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?