Happy 25th Tcl(blog.tkdocs.com)
blog.tkdocs.com
Happy 25th Tcl
http://blog.tkdocs.com/2014/01/happy-25th-tcl.html
22 comments
>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:
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/) and various versions of Scheme (see the links from 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
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
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/) and various versions of Scheme (see the links from 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
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.
Tcl's C is very clean and pleasant code to read, by the way.
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 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 ) 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/ ...
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 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 ) 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/ ...
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.
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.
WoW is scripted in Lua, and the UI is done in XML. (I'm a former WoW mod dev.)
Now that I search for it I can't find any evidence of it, but I swore it was there!
TCL was/is included in Cisco routers for scripting. So some other companies get it.
...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.
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
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!
And if you need something compex, do it C for chrissakes.
EDIT: And event loops are beautiful!
I learned it roughly 20 years ago because of Expect (http://en.wikipedia.org/wiki/Expect), and later used it with Oratcl and AOLServer. And I even did a little C fiddling.
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.
I learned/used TCL for the first time not too long ago... in 2013. It's still used in the healthcare industry.
By the way: it's Tcl, not TCL.
Huh, never noticed that. I guess the fact that's it's an acronym (unlike, say, Perl) threw me. :)
Perl is an acronym too.
Actually Perl comes from the shortening of Pearl. It then later became a backronym.
ref: http://en.wikipedia.org/wiki/Perl#Name
ref: http://en.wikipedia.org/wiki/Perl#Name
I ran across an interesting implementation of Tcl for .NET once; in case anyone else wants to check it out: http://eagle.to/
The code is available on CodePlex, under a BSD-like license: https://eagle.codeplex.com/
The code is available on CodePlex, under a BSD-like license: https://eagle.codeplex.com/
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
Pretty cool.
http://www.tcl.tk/man/tcl8.5/TclCmd/interp.htm
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
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
Congrats to the Tcl team. Tk may still be the sanest GUI toolkit out there, despite its relative stagnation.
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.
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.
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).
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.
let's hope the next 25 years don't ever contain tcl's breakout year.
[deleted]
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.
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.
Happy 25th Tcl! I miss you.
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/
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/
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) written in Rebol:
For a completely different comparison (non Tk) here is the first example (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"
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.
TCL + Vignette, takes me back to 1998.
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.
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.
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.
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.
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.
Happy birthday Tcl! Let us use this moment to commemorate our enormous luck that you didn't spread further.
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...
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.
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.
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...
Yeah, but I'm glad we don't still use corduroyed roads.
Tcl is a wheel worth reinventing.
Tcl is a wheel worth reinventing.
Perhaps that's why it's been reimplemented so many times :-) - see http://wiki.tcl.tk/17975
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.
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.
> 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.
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.
> 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.
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.
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.
That's just what my spider-sense says though - I've never actually looked at those things or their code.
It's also still common as language for hardware debuggers.
Congrats, Tcl! I remember sitting down for hours fixing syntax errors for Eggdrop scripts in 1999 or something. Great learning.
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.