Episode: 2386
Title: HPR2386: The Decline and Fall of Tcl
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2386/hpr2386.mp3
Transcribed: 2025-10-19 02:06:56

---

This episode of HBR is brought to you by An Honest Host.com, get 15% discount on all shared
hosting with the offer code HBR15. That's HBR15. Better web hosting that's
Honest and Fair at An Honest Host.com Hi, I'm Clark Gay. I've long been fascinated by
tickle and I used it sporadically about a decade to a decade and a half ago. At work I
created a GUI around a repeatedly run XSLT transformation that one of my users
would have to do on a somewhat recurring basis and in university was used for package definitions
on the Solaris machines. I did use it more recently but just for some SQLite interfacing.
The tickle and SQLite communities have some pretty close connections and tickle even uses fossil
as the inversion control system just like SQLite does. Fossil is of course developed by SQLite
people and it uses a SQLite backend. So what fascinates me about tickle is how it's basically
everything that list isn't especially scheme but it still manages to do many of the same things
but sort of backwards if you come from a list kind of mindset. So scheme and tickle form sort of
dual in the mathematical sense and back in the day when I was a frequent reader and writer of
the C2 Wiki I remember there was a tickle user there that was always showing list spurs how
everything they thought was impossible to do in tickle was actually possible just not in the way
they wanted to do it and probably in a way that list spurs found a bit revolting but the history
of tickle is mixed in with the scheme history because of the tickle war that actually started
guide development. So there's a link for that in the show notes about the tickle war.
So tickle was only its way to greatness in the 90s and then something happened and I found a
blog post by a long time tickle contributor and he has analyzed why and I'm going to read the
whole blog post verbatim. The link is in the show notes. It's not a super recent post it's from
2010 but I think the observations are interesting whatever year it is. There is no explicit licensing
on the blog so I contacted the author and he gave me permission to do basically whatever I want
as long as I provide the attribution. So here it is where tickle and tk went wrong by David
Ann Welton at the DEDASIS journal posted on the 30th of March 2010.
Where tickle and tk went wrong? I've been pondering this subject for a while and I think I'm finally
ready to write about it. Tickle was for many years my go-to language of choice. It's still near and
dear to me in many ways and I even worked on a portion of a book about it. Link to book.
However, examining what went wrong is quite interesting. If one attempts as much as possible a
dispassionate and a litigal approach that aims to gain knowledge rather than assign blame or
paper over real defects with a rose colored vision of things. It has made me consider and learn
about a variety of aspects of the software industry such as economics and marketing that I had not
previously been interested in. Indeed my thesis is that tickle and tk's problems primarily stem
from economic and marketing so human factors rather than any serious defects with the technology itself.
Before we go further I want to say that tickle is not dying. It's still a very widely used
language with a lot of code in production and importantly a healthy, diverse and highly talented
core team that is dedicated to maintaining and improving the code. That said since its heyday
in the late 90s it has not thrived I guess we can say. I would also like to state that
hindsight is 2020. It's easy to criticize after the fact and not nearly so easy to do the right
thing in the right moment. This was one reason why I was ready to send to write this article.
Let me repeat that I'm writing it not out of balance or frustration. I went through a frustrated
phase but that's in the past but because at this point I think it's a genuinely interesting case
history of a rise and gentle decline of a widely used software system and that there is a lot
to be learned. At the height of its popularity tickle was up there with Pearl which was
de-scripting language in those days. Pearl, tickle and Python were often mentioned together.
Ruby existed but was virtually unknown outside of Japan. PHP was on the rise but still hadn't really
come into its own. Lua hadn't really carved out the niche for itself yet either.
tickle is no longer one of the popular languages these days so to say that it hasn't had problems
is to bury one's head in the sand. It has fallen in terms of popularity.
To examine what went wrong we should probably start off with what went right. TK.
This was probably the biggest draw. Easy cross-platform GUI's were and are a huge reason for
the interesting tickle. TK is actually a separate bit of code but since many of the widgets
subscript in the tickle the two are joined at the hip. Still though TK is compelling enough that
it's utilized as the default GUI library for half a dozen other languages.
A simple powerful language. Tickle is easy to understand and get started with.
It borrows from many languages but is not an esoteric creation from the CS department that is
inaccessible to average programmers. Easily embeddable extendable. Remember that tickle was
created in the late 80s when computers were orders of magnitude less powerful than today.
This meant that fewer tasks could be accomplished via scripting languages but a scripting language
that like you write routines in C or conversely let the main C program execute bit subscript code
from time to time was a very sensible idea and tickle still has one of the best and most extensive
C APIs on the game. An event loop. Lately systems like Python's twisted and no JS have made event
driven programming popular again but tickle has had it for years. BSD license. This meant that
you could integrate tickle in your proprietary code without worrying about the GPL or any other
legal issues. These features led to tickle being widely used from Cisco routers to advanced
television graphics generation programs to the AOL server web server which was busy serving
at large quantities of dynamic web pages when many of us were still filling around with comparatively
slow and clunky CGI programs in Perl. Note also that there have been a lot of cool things to have
gone into tickle in the meantime. It has a lot of impressive features many more than most people
realize and has had a lot of them for a while. Check out tickle.tk to learn more about the good
stuff but that's not the point of this article. There was a healthy active community of developers
producing lots of interesting add-ons for the language and working on the language itself.
This culminated in its adoption by some microsystems which hired the language creator Dr. John
Austerholt and a team of people who added a lot of great features to the language.
Quoting from Austerholt's history of tickle page and note from Cluckier I have no idea how to
pronounce this name but it looks Dutch so I've pronounced it in what I believe is Dutch pronunciation.
The additional resources provided by Sun allowed us to make improvements to tickle and TK.
Scott Stanton and Ray Johnson ported tickle and TK to Windows and the Macintosh so that tickle
became an outstanding cross-platform development environment. Windows quickly came to be the
most common platform. Check up Levi and Scott Stanton overhauled the IO system and added
socket support so that tickle could easily be used for a variety of network applications.
Brian Lewis built the bytecode compiler for tickle scripts which provided speedups of as much
as a factor of 10 times. Jacob Levi implemented safe tickle, a powerful security model that
allows contrastive scripts to be evaluated safely. Jacob Levi and Lauren Demaley built a tickle
plugin so that tickle scripts can be evaluated in a web browser. We created Jackal and tickle
blend which allowed tickle and Java to work closely together. We added many other smaller
improvements such as dynamic loading, namespaces, time and date support, binary IO, additional
final inflation, commands and an improved font mechanism. Unfortunately, after several years,
Sun decided that they wanted to promote one and only one language and that language was Java.
So, Austerhold and many people from his team decamped to a startup that Austerhold founded
called Scriptix where the tickle and TK innovations continued.
In 1998, Scriptix made several patch releases for tickle A.0 to fix bugs and add small new features
such as better support for the incertical extension. In April 1999, Scriptix made its first
major open source release, tickle TK A.1. This release added unicode support for international
ization, thread safety for multi-threaded server applications, and an all new regular expression
package by Henry Spencer that included many new features as well as unicode support.
However, as many a company based around open source was to find later, it's a tough space to
be in. Scriptix changed its name to a juba and was eventually sold at a healthy profit apparently
making it a relative dot com success story all in all to interwoven for the B2B technology
that a juba had developed. Interwoven was not interested in tickle particularly,
so to create a system for the ongoing development and governance of the language, the tickle core team
was created. This was something of a blow to tickle, but certainly not fatal. Pearl,
Python, Ruby, PHP, Lua have all had some paid corporate support, but it has by no means been
constant or included large teams. At the same time in the late 90s, open source was really
starting to take off in general. Programmers were making all kinds of progress and have begun
to make Linux into what it is today. Make Linux into what is today the world's most widely
used server platform and laying the groundwork for the KDE and GNOME desktops. While these may
still not be widely used, they are for the most part very polished systems and leaves and bounds
better than what passed for their Unix desktop experience in the 90s. One of the key bits of work
that was added to TK was to make it look pretty good on Microsoft Windows systems.
This was in a time when the enterprise folks were turning away from Unix in the form of AX,
Solaris, HPUX at all and taking up NTE as the platform of choice. So it wasn't some way sensible
to make TK work well there, and in any case a cross-platform GUI tool kit it ought to work well
there in any case. And on the Unix site, TK emulated the expensive professional motif look and
feel that serious Unix programmers used. What could go wrong? As GNOME and KDE continued to mature,
though, what would become one of TK's major, in my opinion, marketing blunders to Groot? I have it
on good authority from someone who was there in the office that the scriptics guys working on TK
viewed GNOME and KDE and the GTK and Qt toolkits are not really worth their while.
To be fair, since TK has always been under a liberal BSD style license,
the Qt tool kit has always been off limits. Still though, the attitude was that TK was a standalone
system and since it ran on pretty much any Unix system, it didn't need to bother with GNOME or KDE.
Gradually though, as more and more people used GNOME and KDE exclusively on Linux,
the TK look and feel began to look more and more antiquated. A relic from the 1990s when Motif,
which has since pretty much disappeared, was king. TK applications started to really stand out
by not looking at all like the rest of the operating system. And while Linux may not be responsible
for a vast portion of the world's desktops, it's widely used by developers who were turned off by
the increasingly creaky look of the TK applications they saw. TK is and was actually a fairly flexible
system and it wouldn't be impossible to tweak the look and feel to make it look a bit better on Linux
without even doing any major work. Maybe not perfect, but certainly better looking. Nothing happened
though. Another problem was that TK and TK made it so easy to create GUIs that anyone could
indeed, despite in many cases, a complete lack of design skills. You can't particularly blame the
tools for how they're used, but there was certainly a cultural problem. If you read most of the
analytical and TK books, and even many of the modern ones, there are hundreds of pages dedicated
to exactly how to use TK, but few to none explaining even basic user interface concepts,
or even admonitions to the user to seek out that knowledge prior to attempting a serious Google
program. The end result is that a lot of TK programs, beside just looking old-fashioned,
had fairly poor user interfaces, because they were made by programmers who did not have a UI design
culture. Contrast that with NOM and KDE, which have made a point of focusing on how to make a good
GUI for the systems, complete with guidelines about how applications should behave. It may have
taken them some time to get things right, but they have done a lot to try and instill a culture of
creating high quality, well-integrated GUIs that are consistent with the system when they run.
Lately, there's been a lot of work to update the TK look and feel, and it has finally started
to bear fruit. However, in terms of marketing, the damage has already been done. The image of
old Crafty TK has been firmly planted in countless developer's minds, and no amount of facts
are going to displace it in the near future. Another problem tickled faced as it grew was the
tug of war between those wishing to see it small, light, and easy to distribute embedded within
some other program, and those wishing it to become a full-fledged programming language,
with lots of tools for solving everyday programs. Unfortunately, that tug of war seems to have
left it somewhere in the middle. Lua is probably more popular these days as an embedded language,
because it's very small and very fast and doesn't have as much baggage as tickle.
Meaning, of course, that it doesn't do as much as tickle either, but for a system where we're
merely wishes to embed a scripting language without much extra stuff, tickles extra functionalities
perhaps and burden rather than a bonus. On the other hand, while Pearl was happily
chugging along with their C-PAN system for distributing code, giving users easy access to
huge array of and-on functionality, and Python was building up a battery's included distribution,
that included a lot of very useful software straight out of the box. Tickle on the other hand,
chose to keep the core distribution small-ish, and only lately has got some semblance of a
package and distribution system. That is, however, run by active state and is at least according
to cursory glance at the tickler's wiki, not even fully open source.
The lack of a good distribution mechanism, and in the meantime,
is skewing a larger battery's included main distribution. Left tickle users with the language
that out of the box did significantly less than the competition. Technically, a Python-style
big distribution would not have been all that difficult, so once again, I think this is a marketing
problem. A failure of the tickle core team to observe the market,
assess what users need and act on it in a timely manner.
Somewhat related to the large tickle versus small tickle issue was one particular extension
or extensions to the language that was noticeably absent, a system for writing object-oriented
code. Tickle at heart will never be an OOO language through a through like Ruby or small talk,
but that doesn't mean an OOO system for it is not a useful way of organizing larger tickle systems.
Indeed, tickle syntax is flexible enough that is possible to write an OOO system in tickle itself,
or optimizing for speed, utilizing the extensive CAPI in order to create new commands.
Over the years, a number of such systems have risen. The most well-known being
Inkru Tukko, a play on the Inkru command, which is akin to plus plus equals one in languages like C.
However, none of these extensions were ever included with the standard tickle distribution or
somehow blessed as the official OOO system for Tukko. This meant that a newcomer to tickle wishing
to organize their code according to OOO principles had to pick a system to use from several competing
options. And of course, newcomers are the least able to judge a complex feature like that in
a language, making it a doubly stressful choice. Furthermore, even experienced tickle programmers who
wanted to share their code could not utilize an OOO system if they wanted the code to work with
just standard tickle. Also, if the code had a dependency on some OOO system, it would require the
user to download not only the extension in question, but the OOO system it was built on, which,
naturally, might conflict with whatever system the user had already selected. As of tickle 8.6,
thanks to the work of Donald Fellows, tickle is finally integrating the building blocks of an OOO
system in the core itself. But this effort is probably something like 10 years too late.
Some other more or less minor things that have taken too long to get integrated in the
tickle RTK distributions include the PNG format still not there in the production release of tickle.
A readline-based command line, TKconn is nice, but not a replacement for simply being able to type.
Tickle shook and get a nice functional shell like Python, Ruby and most other languages have.
This could easily lead to a bad first experience for someone trying out tickle.
Tickle also took too long to integrate a first-class hash type access to the DICT command,
which only appeared in 8.5. It's a raise on bad, but don't quite have the full power of a
hash table as DICT implements them. Once again, the code to do these things was is out there.
It has just been a matter of integrating it into tickle and TK, which has been a slow process.
One actual technical problem that tickle faces is the concept that all values must be representable as a string.
This is more or less okay for things like lists, hash tables or numbers,
but it's problematic when the user wishes to represent the value that simply isn't a string.
A basic example is a file handle, which at the CAPI level is a file star.
How does tickle get around this? It keeps an internal hash table with a tickle script accessible
string, such as file file, that points to a file star value that is used internally by file
commands. This works pretty well, but there's a big but. Since you can compose a string like
file 5 at any time that must be able to access the actual file pointer, you can do any sort of
garbage collection to determine when to clean things up automatically. Other languages have
explicit references to resources, so the program knows when a resource is no longer referenced
by the rest of the program and can clean it up. Therefore, the programmer must explicitly free
any resources referenced this way. This explanation is simplifying things somewhat,
but it's something of you as a technical problem with tickle.
If you've been following along, you've noticed a lot of these days, and recently,
that's because tickle is still very actively developed, with a lot of new ideas going into it.
However, if you look at the release dates, it seems that after a jubo was sold off,
and I also called pretty much abandoned an active role in the language for good,
placing it in the hands of tickle core team, there was a law in the momentum,
with tickle 8.5 taking 5 years to be released.
This is actually, in my opinion, an interesting phenomenon in languages.
You risk hitting some kind of local maximum when your language is popular enough to have a lot
of users who will be angry if things are changed or accidentally broken in the course of big up
hills. So you have to slow down, go carefully, and not rock the boat too much. On the other hand,
there is an opportunity costing that newer languages with less to lose can raise ahead of you,
adding all kinds of cool and hand-new things, or simply fix and remove broken features.
Erlang is another system that has, in my opinion, suffered from this problem,
problem to some degree, but this article is long enough already.
Once again, though, not really a technical issue, but a problem with how the code was managed.
And not an easy one to solve at that.
A tickle failure that I was personally involved with
was the web infrastructure. What went on to become Apache Rivets was one of the first open-source
Apache tickle projects. It was actually quite a nice system. It was significantly faster than
PHP yet, of course, made use of tickle, which at the time had a large library of existing code
and could be easily repurposed for projects outside the web. Or the other way around,
non-web code could be brought into a web-based project. One thing I also have done
differently with the Apache Rivet project was listen to the wise advice of Damon Courtney,
my partner in crime on the project, who wanted to see Apache Rivet have a fairly fat
distribution with lots of useful goodies. Rails and Django, these days, have shown that that's
a sensible approach, rather than relying on lots of little extensions that the user has to go
around and collect. The code was out there. I should have helped. I should have helped make Rivet
do more out of the box. A problem that is and isn't. The syntax. Tickle syntax is amazingly
flexible. Since everything is a command, you can write new commands into it itself. And that
goes for control structures too. For instance, tickle has a while command, but no due while.
It's very easy to implement that in tickle itself. You simply can't do that in most everyday
languages. However, this comes in something of a cost. The syntax for your average programmer who
doesn't want to go far out of their comfort zone is perhaps a little bit further afield from the
C family languages than they would prefer. Still though, a human problem rather than a technical one.
Perhaps sadly, the message is that you better not scare people when introducing a new language,
by showing people something that doesn't look at least a little bit familiar. Conclusions.
First and foremost, that gradually tickle and decay continue to be improved. However, if one visits
developer forums, there are also a lot of negatives associated with the tickle and decay brands.
And I'm not sure it will be possible to rectify that. So, what can we learn from the rise and
subsequent stagnation of tickle? Success in the first place came from doing one particular thing
very well and making it a lot easier than other existing systems at the time. That's a good strategy.
Not staying up to date can be deadly. Of course, it can be tricky to know what's a genuine trend
than what's just a fad in this industry and picking the right things to stay up to date with
can be tricky. That said, there are a number of areas where tickle and decay failed to follow what
became very clear directions, until way too late. Do your best not to get trapped between existing
users who don't want to rock the boat and don't lose your agility and ability to iterate
with the system you're developing. Long delays between releases can be deadly.
Don't lose touch with your roots. In this case, the open source community that is a breeding ground
for new developers and projects. Tickle and TKB can passay in that environment, which has
led to its lack of adoption for new projects not only in the world of open source but in business as well.
Don't isolate yourself. Tickle and TK stopped appearing at a lot of the open source conferences
and events and in magazines, books and articles online. Either because with no figurehead or leader
to invite there there was less interest in speakers and authors or because the rest of the tickle
court team wasn't particularly engaged or formed whatever other reason. This created something of
a negative feedback loop, where tickle and TK were things associated with the past rather than
something currently talked about and discussed. End of blog post
I've been listening to Hacker Public Radio at Hacker Public Radio not a work. We are a community
podcast network that releases shows every weekday Monday through Friday. Today's show, like all
our shows, was contributed by an HPR listener like yourself. If you ever thought of recording a
podcast and clicking our contribute link to find out how easy it really is, Hacker Public Radio was
founded by the Digital Dog Pound and the Infonomicon Computer Club and it's part of the binary
revolution at binwrap.com. If you have comments on today's show, please email the host directly.
Leave a comment on the website or record a follow-up episode yourself unless otherwise stated,
today's show is released under a creative commons attribution share-like three-point-hole