
Happy 25th Tcl - draegtun
http://blog.tkdocs.com/2014/01/happy-25th-tcl.html
======
Toenex
Loved this from the announcement:

 _In other words, Tcl as a language is what would happen if Lisp and csh met
at a party, got way too drunk, hooked up, got pregnant, and kept drinking
throughout the pregnancy._

When I was using it (early 1990's) I really appreciated that Tcl provided C
coders with an easy way to create a scripting environment for your libraries.
And with Tk you could get a GUI running pretty quickly as well. The structure
of the source code was also very neat and well managed making it easy to
understand and extend.

In many ways I see Lua as the spiritual successor to Tcl; neatly designed for
embedding and extension.

~~~
kingmanaz
>Tcl as a language is what would happen if Lisp and csh met at a party, got
way too drunk, hooked up, got pregnant, and kept drinking throughout the
pregnancy.

Below is one of the SICP authors writing on the lispish nature of Tcl. (TL;DR:
Tcl is like a lisp that exchanged theoretical purity for pragmatic simplicity
of implementation):

""" If in reading this introduction, you've come to realize that "Hey, Tcl is
just like Lisp, but without a brain, and with syntax on steroids", you might
wonder why Lisp isn't a more popular scripting language than Tcl. Lisp hasn't
been a complete failure, by the way; it is used as an extension language by
users of some popular programs, notably AutoCAD. But Tcl has been much more
successful. It has been compiled into hundreds of larger programs, including
AOLserver, which is why we wrote this book.

As a software developer, you're unlikely to get rich. So you might as well try
to get through your life in such a way that you make a difference to the
world. Tcl illustrates one way:

    
    
        * make something that is simple enough for almost everyone to understand
        * give away your source code
        * explain how to weave your source code in with other systems
    

In the case of AOLserver, for example, Jim Davidson and Doug McKee had only a
few months to build the whole server from scratch. They wanted users to be
able to write small programs that ran inside the server process. They
therefore needed a safe interpreted language so that a programming error by
one user didn't crash the server and bring down all the Web services for an
organization.

Tcl was available. Tcl was easy to download and designed to fit inside larger
application programs. But the Tcl interpreter as distributed had one terrible
bug: it wasn't thread safe, i.e., you couldn't have two copies of the Tcl
interpreter running inside the same program at the same time. Doug and Jim had
to read through the Tcl source code and modify it to be thread safe. So it was
critically important for them that Tcl was open-source and simple enough so as
to not require months or years of study to understand the whole system.

Compare this to Lisp. Some of the best and brightest computer scientists
raised money to build commercial Lisp implementations that they then went out
and hawked in an indifferent and confused marketplace. They succeeded only in
breaking their hearts and their investors' wallets. A handful of academics
produced free open-source implementations, notably CMU Common Lisp (see
[http://www.cons.org/cmucl/](http://www.cons.org/cmucl/)) and various versions
of Scheme (see the links from
[http://en.wikipedia.org/wiki/Scheme_(programming_language);](http://en.wikipedia.org/wiki/Scheme_\(programming_language\);)
Scheme 48 is the closest to Tcl in spirit). But these multi-megabyte monsters
weren't designed to fit neatly into someone else's program. Nor was there any
document explaining how to do it.

Lisp developers have the satisfaction of knowing that they got it right 30
years before anyone else. But that's about all they have to show for 40 years
of hard work and hundreds of millions of dollars in government and private
funding. These days, most former Lisp programmers are stuck using Unix and
Microsoft programming environments and, not only do they have to put up with
these inferior environments, but they're saddled with the mournful knowledge
that these environments are inferior. """

[http://philip.greenspun.com/tcl/introduction.adp](http://philip.greenspun.com/tcl/introduction.adp)

~~~
davidw
One of the things that Tcl - and also to some degree Perl and Python got right
is that they are 'promiscuous' in that they are happy to integrate with the
rest of the world. Languages like Lisp and Forth tend to have more 'turtles
all the way down' philosophies.

Tcl's C is very clean and pleasant code to read, by the way.

------
mih
Congrats Tcl indeed. One of my fondest memories working with Tcl was in the
EDA industry. Thanks to its legacy, Tcl/Tk enjoys widespread usage in the
entire workflow - from logic design to sign-off. Quite odd to think that
development of semiconductor chips around me is dependent on such a relatively
obscure language.

Despite its odd syntax which sometimes tends to get in the way, Tcl is one of
the rare examples of a functional programming language actively used in the
industry (I'm looking at you Lisp). Though I did often find myself wishing
that something like Python would replace it instead for better readability.

~~~
dded
> One of my fondest memories working with Tcl was in the EDA industry. Thanks
> to its legacy, Tcl/Tk enjoys widespread usage in the entire workflow - from
> logic design to sign-off

Those of us actually using EDA tools are not necessarily so fond of Tcl. Not
me anyhow. Tcl is awkward to debug, and its everything-is-string semantics
make programming an exercise in quoting. Just when I think I understand the
scoping, I screw it up.

> Despite its odd syntax

Tcl's syntax is one thing that I actually _do_ like about the language. It's
odd, yes, but it's simple and clean.

> Tcl is one of the rare examples of a functional programming language
> actively used in the industry (I'm looking at you Lisp).

Cadence actually uses a real Lisp in some of their tools; they call it Skill.
Skill is, in fact, a joy to code in; and I greatly prefer it to Tcl. They also
have a lexically scoped version called Skill+, which I've never got to use.

> wishing that something like Python would replace [Tcl]

Python, yes! Or Scheme. Or even Perl. I don't know Lua, but have always
imagined it to be better than Tcl and it seems to occupy a similar niche. But
no one even talks about Tcl getting replaced.

~~~
taway2012
> everything-is-string semantics make programming an exercise in quoting.

Is your code filled with literal strings? Otherwise why your code be "an
exercise in quoting"?

re Python: Remember that EDA tools aren't libraries, they're actual command
line program programs. So those tools will still need a command line language.
Python is horribly unsuited as a command line language, so the tool will
probably continue to have Tcl to present the text user interface.

So you'll then end up with two interpreters in the same tool. Hardly a
desirable state of affairs. So yeah, I think the ROI of embedding Python in
EDA tools is probably not doing to be worth it.

A lot of the C code backing the Tcl APIs directly build Tcl objects or store
pointers to Tcl objects in C. It will be giant task to make those APIs work
correctly with Python also.

~~~
davidw
I think a lot of the EDA people learned just enough Tcl to kind of sort of do
stuff, and perhaps did not learn enough, or put that much effort into writing
it _well_. Also, a lot of those packages are pretty old and thus could not
take advantage of a lot of the improvement in the language over the years.

That's just what my spider-sense says though - I've never actually looked at
those things or their code.

------
cnvogel
I think what's hiding behind the baroque syntax and "everything is a string"
approach is the fact that for a long time tcl sat on the sweet spot between
the limited low-level functionality of a unix-shell and the missing high-level
functions of traditional scripting languages (especially in the mid-90s when I
started learning about tcl).

There was the insanely useful event-loop built into tk (obviously, for GUI
applications), but also in tclsh (see, for example,
[http://www.tcl.tk/about/netserver.html](http://www.tcl.tk/about/netserver.html)
where [socket -server _on_connect_callback_fct_ _portnum_ ] creates a
listening tcp socket).

This made it (for me, in 1997...) an ideal glue-language for network
management tasks (monitor events on a router, graph temperature on a UPS, see
[http://wiki.tcl.tk/691](http://wiki.tcl.tk/691) ) but also for simple
laboratory automation (GUI in tk for controlling a power supply), most often
running simple line-oriented ASCII protcols between GUI and daemon.

Even later, I did research in a Physics collaboration that did automate their
whole measurement apparatus on the HERA accellerator in Hamburg using a really
scary and intricate mixture of tcl/tk, blt for data visualization and a
obscure particle-physics database (ADAMO) made network aware: [http://www-
hermes.desy.de/pink/](http://www-hermes.desy.de/pink/) ...

------
smrtinsert
Happy bday TCL!

As I spend my time more and more in clojure these days I can't help but be
reminded of some of the cool stuff you could do with TCL, which isn't
surprising given its lisp heritage. Any language that cleanly lets you add new
constructs is ok in my book!

Aolserver, that was fun too :) It's always amazing to me how TCL didn't stay
more prominent. When Blizzard scripted WoW with TCL I was like "finally,
someone gets it!" but that was more an anomaly than anything else.

~~~
Slackwise
WoW is scripted in Lua, and the UI is done in XML. (I'm a former WoW mod dev.)

~~~
smrtinsert
Now that I search for it I can't find any evidence of it, but I swore it was
there!

~~~
pwelch
TCL was/is included in Cisco routers for scripting. So some other companies
get it.

~~~
bch
...and F5 load balancers, and A10 load balancers, and Tealeaf network
monitoring, and helping animate battling orcs in Lord of the Rings trilogy,
manages NBCs control room, runs astrological equipment, was involved with Mars
Pathfinder programme, has excellent testing facilities (at the core of dejagnu
(used for testing GCC, among other things)), and on, and on, and on.

------
wainstead
A good overview of the language features (and why Tcl is different from other
languages) can be had in this excellent post:

[http://antirez.com/articoli/tclmisunderstood.html](http://antirez.com/articoli/tclmisunderstood.html)

------
forkandwait
Tcl is the scripting language i hate the least. The string / macro / lispy
syntax paradigm works great for driving sql and simple guis. You trade macro
hassles like quoting for anti-macro hassles like inheritance or complex
parameter specs, but engineering = tradeoffs...

And if you need something compex, do it C for chrissakes.

EDIT: And event loops are beautiful!

------
cafard
I learned it roughly 20 years ago because of Expect
([http://en.wikipedia.org/wiki/Expect](http://en.wikipedia.org/wiki/Expect)),
and later used it with Oratcl and AOLServer. And I even did a little C
fiddling.

------
codegeek
I learned/used Tcl/Tk at my very first real job not too long ago circa 2003.
At the time, it was for a financial trading system and I loved the simplicity
of it since I had already been doing Java/C++ in my CS program at college. The
best part of it is the pronunciation "tickle". Still makes me smile.

~~~
commandar
I learned/used TCL for the first time not too long ago... in 2013. It's still
used in the healthcare industry.

~~~
davidw
By the way: it's Tcl, not TCL.

~~~
commandar
Huh, never noticed that. I guess the fact that's it's an acronym (unlike, say,
Perl) threw me. :)

~~~
davidw
Perl is an acronym too.

~~~
draegtun
Actually Perl comes from the shortening of _Pearl_. It then later became a
backronym.

ref:
[http://en.wikipedia.org/wiki/Perl#Name](http://en.wikipedia.org/wiki/Perl#Name)

------
profquail
I ran across an interesting implementation of Tcl for .NET once; in case
anyone else wants to check it out: [http://eagle.to/](http://eagle.to/)

The code is available on CodePlex, under a BSD-like license:
[https://eagle.codeplex.com/](https://eagle.codeplex.com/)

------
buro9
Oh man, the hours spent hunting down orphaned or misaligned brackets in some
include file as part of a multi-million line of code program.

TCL + Vignette, takes me back to 1998.

~~~
reuven
I met with a company in 2011 that was using Vignette, and was considering
creating their own CMS. I said something like, "I know that the really old
version used to work on Tcl, but I assume that you're long past that."

I was met with blank, embarrassed stares, until the manager finally said, "Um,
we're actually still using that ancient version built on Tcl."

So far as I know, they're still using it -- they never upgraded, switched, or
developed an alternative. I'm not sure if that speaks to the company's ability
to absorb pain, or to the excellent, long-term software engineering that went
into that version of Vignette.

~~~
buro9
That version of Vignette was little more than a wrapper for a TCL web stack.
The function of the wrapper was to provide caching and cache invalidation, and
some extra things to help make that fractionally easier (dependency
management).

But... it was always sold and justified it's price on the basis of
personalisation. Everywhere I ever saw Vignette the managers believed that
they had purchased the holy grail of personalisation.

The personalisation stuff was based on server-side includes that pulled in
uncached files, and used cookies to track individuals and then would build a
file on the individual and tailor the SSI for the individual.

Sounds perfectly reasonable. Except I never saw it working outside of a demo
for a single user.

Vignette was a great "web stack with static file caching", and on the 4
servers we had at British Telecom we could serve our 6 million customers the
BTinternet portal when they all logged on the minutes after 6pm (remember when
it was free internet in the evening? and BTinternet was the default home page
in IE for our users).

But if you turned on personalisation, everything ground to a halt immediately.

~~~
reuven
Funny you should mention that... the company in question was a large (by
Israeli standards) newspaper, with lots of popular sites. But I don't believe
that they have any personalization, or that it's active for any meaningful
number of users.

------
taway2012
This is a relatively obscure feature of Tcl, but it has some great ideas on
how to safely execute user-supplied scripts in a sandbox.

Pretty cool.

[http://www.tcl.tk/man/tcl8.5/TclCmd/interp.htm](http://www.tcl.tk/man/tcl8.5/TclCmd/interp.htm)

------
hamzakc
I remember using it for the first time in 2001 in a summer job I had while at
uni. We were using it to develop a web site built with the open source version
of ACS (from philip greenspun). As a small team we managed to deliver the
entire site in 8 weeks. Goes to show how good the ACS framework was and how
flexible and efficient Tcl is.

Also at the time AOLServer was amazingly fast. Shame development stopped on
it.

ACS got bought by Red Hat later on, but it still lives on as openACS
[http://openacs.org](http://openacs.org)

------
Millennium
Congrats to the Tcl team. Tk may still be the sanest GUI toolkit out there,
despite its relative stagnation.

------
pjmlp
Happy birthday Tcl!

The first web application server I used, between 1999 and 2001, was an in-
house framework built on top of Apache + C + Tcl.

Quite similar in principles to AOL Server, actually.

------
protomyth
I would put Tcl on the list of languages to learn just because it is one very
different and it can be used to build some cool projects (the web server).

------
jnazario
tcl was one of the first "respectable" languages i used (having learned basic,
some java, and bash/awk scripting). i still dislike it for its wonkiness, but
i did use it towards the end to learn some FP paradigms. (tcl, it turns out,
is big in network device testing. ugh.)

let's hope the next 25 years don't ever contain tcl's breakout year.

------
revelation
Happy birthday Tcl! Let us use this moment to commemorate our enormous luck
that you didn't spread further.

~~~
gaius
Tcl spread further than you think, if you think computing begins and ends at
websites. I shake my head sadly when I see guys running around reinventing
badly all the things Tcl did well. Node.js being one of the most egregious
examples, but there are others, Enaml, Lua, the vast tomes written on Ruby
deployment when it's trivial in Tcl...

~~~
reuven
I teach a lot of programming classes (mostly Ruby and Python), and it never
ceases to surprise me to discover how many people are still working in Tcl. It
would seem that Tcl really took over a lot of the embedded world, such that
companies working on routers and such still use it, or at least did so until
recently.

I never loved Tcl, but it was a very clever language for its time, and did
wonders to justify the acceptability of doing things in "just" a scripting
language.

~~~
gaius
As an industry, we've got to get over this notion of "still", it's like civil
engineers saying are you still making things out of concrete? 25 years I would
say is a proven, mature technology, not obsolete. Think how much progress we
could make if we didn't reinvent the wheel every few years...

~~~
dded
Yeah, but I'm glad we don't still use corduroyed roads.

Tcl is a wheel worth reinventing.

~~~
cmacleod
Perhaps that's why it's been reimplemented so many times :-) - see
[http://wiki.tcl.tk/17975](http://wiki.tcl.tk/17975)

------
stkni
Ah! I still remember the day I discovered that some of the project I had
inherited was Tcl that was generated at runtime by Tcl.

There's somethings you can do when everything's a string that you can't easily
do in many other languages, unless that language is Lisp-based of course.

------
subbz
Congrats, Tcl! I remember sitting down for hours fixing syntax errors for
Eggdrop scripts in 1999 or something. Great learning.

------
gnachman
Happy 25th Tcl! I miss you.

------
kingmanaz
Tcl is pragmatic. I still use it for one-off projects with simple GUIs via Tk.
I get grief from co-workers for the language, but my projects are typically
done and correctly functioning in a fraction of the time it takes our Java and
C# devs to even prototype a utility.

Below is a walkthrough of Tk which compares identical implementations of
examples in Pearl, Ruby, Python, and Tcl. See if you can spot which of the
scripting languages are more concise. Hell, I'd even call Tcl more _readable_
in most of the cases:

[http://www.tkdocs.com/tutorial/](http://www.tkdocs.com/tutorial/)

~~~
draegtun
Tk was very handy for whipping up GUI apps. However those comparison examples
written in Perl (not Pearl!), Ruby & Python could be improved to look (at
least a little!) better.

For a completely different comparison (non Tk) here is the first example
([http://www.tkdocs.com/tutorial/firstexample.html](http://www.tkdocs.com/tutorial/firstexample.html))
written in Rebol:

    
    
      Rebol []
     
      convert-to-metres: func [in-feet] [
          (round 0.3048 * in-feet * 10000.0) / 10000.0
      ]
     
      default-feet: 1
     
      my-window: layout [
          style input-feet field 80 left
          style label      lab   90 left
          tabs [140 230]
          across
     
          tab feet: input-feet (to-string default-feet)
          tab label "feet"
          return
     
          text "is equivalent to"
          tab in-metres: text (to-string convert-to-metres default-feet)
          tab label "metres"
          return
     
          tabs 230
          tab button "calculate" [
              in-metres/text: to-string convert-to-metres to-decimal feet/text
              show in-metres
          ]   
      ]   
     
      view/title my-window "Feet to Metres"
    

The above is written in the Visual Interface Dialect of Rebol 2. I made it
look visually _identical_ to the example provided however this was the first
time I've ever written any VID code so I'm sure it can be improved upon :)

