Who says Tcl rules...

Purpose: collect positive quotes referring to Tcl. All in good taste, and if possible, provide an exact reference or URL. (escargo adds - and the current date!)

"Tcl is voodoo, it does stuff that shouldn't work but does awesomely. How it does it is just voodoo." [L1 ]

"it's absurdly easy to write a Tcl extension - I wanted to talk to a soft CPU using a Xilinx Platform Cable USB (which isn't supported by OpenOCD). I ended up creating a simple Tcl extension around xc3sprog and it worked a treat - I'm pretty sure the engineering effort to do the same for a different scripting language would have been much greater." [L2 ]

"I had a task involving reading some data files to understand whether they were corrupted or still usable. The software to read the files usually came as part of a proprietary package with a price tag high enough that it made no sense to license for this one small task...

I decided to search online for easy and free ways to read the files... I found Tcl/Tk after a bit of digging and decided to give it a whirl.

In all I spent about 16 hours dinking around with Tcl and had a nice, short program written to read everything, display the data for a QC check, and write it to disk. The documentation was detailed and concise. Of all the programming languages that I have used over the years the fact that I could sit down and find the right set of simple commands and assemble all of it into a working program in a couple of days with no learning curve pain or friction was amazing." [L3 ]

"it's absurdly easy to embed in C and has very powerful constructs once you get used to them and no Global Interpreter Lock like python.

So there was a discussion about why people still use C or similar recently and I think that C+Tcl is a potent combination where you can mix C and Tcl in a very natural way such that you never do in C what Tcl does much more easily but you can still get excellent performance where it counts. It's all theoretically possible in Python but just feels like much more work." [L4 ]

"Creating scripting hooks is absurdly more complicated than you think (look at the grief KiCad has keeping Python supported--Blender had to create a whole GUI library from scratch to have Python hooks--Altium's Python scripting is still a horribly broken bodge). Tcl means that you get scripting hooks that work. I haven't seen any other language do it better yet." [L5 ]

"I've used Tcl extensively over many years. It's a tremendously flexible tool that can be shaped to accomplish many tasks. Tcl was never the most widely used scripting language but it's alive and well, and its development continues with new versions on the horizon. There still is a lot to like about Tcl." [L6 ]

"I adore Tcl, and always have... I've always considered Tcl a kind of "close cousin" of Lisp; both in its code structure and the ability to build new control structures and the like. It feels more Lisp-y to me than it does C-y." [L7 ]

"When I left my Tcl job I felt like I was approaching some next level of productivity that I've never quite found with other languages." [L8 ]

"I like Tcl a lot. The design is simple, extremely easy to learn, and yet the code is still maintainable (looking at you LISP). Among the scripting languages I've used, I probably liked Tcl the most." [L9 ]

"I love Expect. We have a bunch of legacy stuff and Tcl/Expect powers most of it. Every few years people try to replace it with python and pexpect, there was a nodejs implementation, and perl. They sorta worked, but anytime you had to something more complicated than a single session or simple parsing they fell apart." [L10 ]

"I got exposed to Tcl/Tk while working for a National Lab a long time ago. At the time I was a hardcore C++ developer and after a week or two with Tcl/Tk I was almost dying laughing about how easy it was to build really cool applications." [L11 ]

"Modern Tcl may be big, but it is not too big to embed. I know, because I embedded it into a Go system at a previous employer... it required remarkably little glue code. I also evaluated Python and Lua... Python appears to be a right royal pain to embed. I actually had more experience with Lua prior to that project, but that experience leads me to believe that Lua is, generally, the wrong language.

Looking back on the project, I would not hesitate to do the same thing again, ideally as open source so that other Go projects can embed a scripting language. It got the job done, and did it well. Non-programmers on our team were able to write both configuration and logic successfully & productively, and apparently enjoyed the experience. Tcl itself ended up being a pleasure to use." [L12 ]

"You might be surprised how many times Tcl snippets running on IOS are in the critical path of phone calls." [L13 ]

"It's an accessible Lisp with square brackets." [L14 ]

"I totally got turned around on Tcl. I hated it when I started as I was mostly programming in C#, but now after year of sporadic use I absolutely love it for its simplicity when manipulating text files and strings." [L15 ]

"My team and I write Tcl based iRules for F5 devices. We do it a couple of times a week. They are a very nice tool. Sometimes we've had to use it like an emergency super power to patch http applications on the wire.

The reason why some financial institutions are working right now is because of some iRules we wrote a couple of years ago." [L16 ]

"I’ve always loved Tcl because of its absolute purity and simplicity at the language level. I love how you can implement your own control flow operators that look like built-in ones. I love how easily you can make DSLs." [L17 ]

"Sure, it´s a bit unusual to use “set” instead of the much more common syntax x = 1 and to many it may feel too strange but if you can overcome this feeling you´ll see that it´s actually a very elegant way of setting values in a command language.

You see, one of the goals of the language is to have a coherent and simple enough syntax so that you´ll never be trapped in the “but there is more” cycle – instead, learn it once, learn it fast and expect no surprises after that." [L18 ]

"People hate on it, but do you know what language would be perfect these days?

Easy shelling - check.

Easily embeddable - check

Easily sandboxable - check.

Reasonably rich standard library - check.

High level abstractions - check.

If you're still guessing what language it is, it's Tcl. Good old Tcl." [L19 ]

"You know - Tcl/Tk8.6 is insanely great.

I stopped using Tcl/wish in about 2004 - this was a BIG mistake - I can now build GUIs described by pure text. *Nothing is hidden* it's all text - I just need emacs and make.

Why oh why did I ever even click on a button to start Xcode" [L20 ]

-- Joe Armstrong, author of Erlang

"Tcl is a super cool language IMO. It's mature, unixy, and has minimal external dependencies. The ecosystem is stable and slow moving. I would encourage anybody to try it out!" [L21 ]

"Tcl is an amazingly direct programming language, which makes things easy to do, and with the significant advantage of crystal-clear readability, and less error-prone code. (A friend of mine maintains Tcl is really short for "try coding less"...)" [L22 ]

"Good programmers have long known that you should build your language up towards your application, and then write your language within that language... conceptually there is a close parallel between scripting web services, and writing a Tcl script that uses prebuilt commands written in C. If you can see the parallels and see how principles from the one apply to the other, the odds are that you'll be doing both better. Whereas if you don't see it and reinvent the wheel from scratch, you're going to wind up learning lessons the hard way that were learned many, many years ago." [L23 ]

"it's very handy to be able to embed a DSL into a complex project to provide programmability, and most of the modern scripting languages tend to be too large and/or too slow for my purposes. My DSL of choice for this tends to be Tcl-based, as I can easily extend the language in task-specific ways and drop the parts of the language that aren't useful for the task at hand. This results in something capable, tiny and fast." [L24 ]

"Friend 20 years ago worked on a content streaming platform. They needed a dispatcher and someone wrote one in Tcl in a week. Just to get something working. And they never got around to replacing it because it worked 'fine'." [L25 ]

"I solved some tough IPC problems using the Tcl event loop. A product that runs on several thousand machines across the US was designed around a set of distinct C++ processes communicating over sockets. Using the Tcl event loop greatly simplified the design, improved performance and eliminated concurrency bugs present in the bespoke IPC code it replaced.

It should have been written that way on day one but some programmers default to pounding out a bunch of spaghetti instead of learning about the tools at their disposal." [L26 ]

A few years ago I installed XCode on my Mac, started learning it (looked 1000x more complicated than my previous IDE.."Hello world" auto-creates dozens of files and folders..) and read hundreds of pages of docs, started learning Objective-C, to try to draw pixels on the screen. Found out that was impossible! Ok, so basic graphics. Shapes.. I never bothered doing much at all. Too much hassle. Discovered Tcl/Tk a lil while later. They were already on my Mac. With a half-dozen-line program in 1 minute I'd made a window on my screen with text. Graphics not much harder. I couldn't believe I'd gone through all that! haha. Had no idea GUIs could be so simple to write on a Mac. Noone told me. I wrote a couple of games in a few days. Tcl is a kinda weird language, unique, but very easy to get the hang of and be very productive in, a joy. I loved it. [L27 ]

"Tcl cross-platform feature is astonishing. With Androwish it steps even further. I have a bunch of private tools for personal organization (time tracker, todo list, notepad-like app) that I've written in Tcl. Over the years, I used Android smartphones more and more and I just wanted all those small apps for Android too, but never had time to learn mobile development.

With Androwish I can just run them in my Android almost unmodified! And I can also make use of Android features like notifications. I sync the files between devices with Syncthing or another tool and, voilà! I can use the same apps in both Android and Unix!" [L28 ]

"I went from trying to embed python in a C application to embedding Tcl and was blown away how easy it was, and that it supported threads. This was back in 2003. I remember trying it with lua, but the parallelism story wasn't really great until at least 5.1. Tcl did it right from 8.4 and things haven't really changed since." [L29 ]

"Perl is really old news, and for the average DA/ASIC/FPGA/SoC engineer, Perl is probably the worst scripting language they could try to learn, for as many reasons as Tcl/Tk is the right first language."

     - Rich Auletta
       ViaWest  Boulder, CO

"I would still take a hard core Verilog or VHDL coder with Tcl skills over a Perl guy any day of the week."

     - Randy Findley
       Layer N Networks

All from http://www.deepchip.com/items/0401-09.html , an October 17, 2002 discussion archive.


"I started using Tcl back around 1994. I was looking for a quick way to prototype ideas, with the intent that, once the logic was proven feasible, the code would then be redone for production use in a "real" language like C or C++. After a while, it started to appear that the Tcl-based prototypes worked so well that fewer and fewer of our projects required recoding. Several years ago it became clear that the Tcl platform had evolved to the point where it was no longer necessary to recode our prototypes at all. Since then, I've been using Tcl exclusively for virtually all of my development projects, and haven't looked back."

     - Mike Doyle
       Eolas Technologies Inc.

Why have you chosen Tcl?

Because I like "programmable programming languages" like Tcl and Lisp a lot. The programmer is free to reinvent the language, write new control structures, and so on. Tcl is very powerful, but for some reason few programmers fully understand it, so it's often regarded as a toy language. I use Tcl for everything not involving low-level things or speed. For the rest, I tend to use C.

What particular limit or feature does the language itself bring?

One of the best features that Tcl gives you is that you can specialize it so much to have a domain-specific language designed to play with packets. The limitation of all this flexibility is speed. For example, in theory you can use hping3 to write a firewalling engine, but in reality you can't go beyond a "prototype" because a firewall needs to be fast. [L30 ]

     - Salvatore Sanfilippo

From the computer science perspective TCL looks like a more interesting development than Perl as it is the first open sourced embeddable language. IMHO Perl is a kind of mainframe (anti-Unix) style language that very much reminds me PL/1 ("all things for all people" kind of approach; there is always several ways to accomplish anything, etc. -- bonanza for consultants and book writers ;-), while TCL is a more Unix-style language. It does well one thing well: it's a really decent command language for various tools including OFMs.

It's very sad that TCL never become prominent neither in Solaris nor in Linux environment. BTW that definitely attests Linux as a neo-conservative movement as TCL has tremendous potential to lift Unix-style OS to a different level by integrating applications on a new level as well as providing a common internal language to a million of obscure Unix utilities some of which outlived their usefulness. One needs to understand that despite their non-othogonality and obscurity (I would like to see a person who really understands all the differences between find and grep in interpreting regular expressions ;-) the current set of Unix utilities still represents quite an innovative, semantically rich set of commands for the operating system. [L31 ]

     - Dr Nikolai Bezroukov

On comp.lang.tcl [L32 ], Robert said, "... I still use Perl for my web stuff but I am slowly moving all my admin tasks to little Tcl utilities and I had a lot of fun doing it. :-) Just a rave!"

The EDA training company Doulos says this [L33 ]:

"Tcl is a popular and widely used cross-platform script programming language that achieves significant productivity gains when used by skilled engineers. Its combination of text processing, file manipulation and system control features make it ideal for this purpose. Many industry-leading EDA tools use it together with the Tk graphics toolkit to provide a flexible and platform-independent graphical user interface. Included are: ModelSim, Leonardo Spectrum, Synopsys Design & FPGA Compiler, Synplify Pro and Altera Quartus."

In July 2004 Dr. Danny Rittman writes: [L34 ]

"Up to few years ago Perl was the ruler in the EDA world as the main scripting tool. In the recent few years Tcl (Tool Command Language) has become the rising star due to an almost zero learning curve. Compared to Perl that requires memorizing many syntax and idioms Tcl is based on maybe a dozen basic commands to get you up and running. Major EDA vendors offer access to their tool's internal functions via Tcl scripting and it looks like it became a standard.

Scripting languages like Tcl and Perl were created for rapid control and systems integration. In the recent years Tcl has become an integral part of design houses design flows as Perl remain a handy tool for other useful tasks. EDA vendors are standardizing on platform-independent Tcl scripts to automate repetitive design tasks and extend the basic features of their tools. Since most of design flows use applications from multiple vendors, a designer now only needs to learn Tcl in order to control multiple tools. Furthermore, Tcl's power, versatility and ease of use is fast being adopted for a wider range of methodology tasks such as data processing; file management and tool interface solutions. No Doubt, the usage of scripting languages created a whole world of possibilities for the EDA world and therefore became an integral part of today's design flows."

The one real argument for Tcl/Tk [L35 ] (Fixed broken link - Lauri Ojansivu)

What happens when you want to work on a software project with the following requirements:

  • 1. Same source code produces a GUI in both Win32 and Linux.
  • 2. Must not require installation on the target machine.
  • 3. Must be distributable as a single executable.
  • 4. Must be able to run without write access to anything if necessary.
  • 5. Language and API are free of charge or preferably, free software.

If you're having trouble imagining such a thing being necessary, consider the concept of a CD-ROM demo with a front end program that autoruns under Windows (and would under Linux if such a feature existed.) It doesn't need to do much other than let the user select from listboxes, see some pictures, push some buttons and finally launch some applications. Naturally, the source to the app would be somewhere on the CD if the app included GPL'ed software.

My immediate thought was Qt/Embedded, which has some pretty glorious features for a low-footprint API and is pretty easy to learn as long as you can handle C++. The level of features you can include in a Qt/Embedded program with no dependencies could be seen in the early binary demo of Konqueror Embedded, before it was declared too primitive and removed. It was a complete web browser with Javascript, style sheet, and image viewing capabilities and it fit into 2MB with no dependencies. But to develop Windows applications, even free software, using Qt, you have two choices: pay upwards of $1000 for access to the Windows version of the SDK, or force the end user to install Cygwin (a kind of Unix emulation environment) on his machine prior to running your app.

I ran through some other choices but all of them ran afoul of one or another of my requirements, to wit:

SEH -- I won't post the full quote here, go to the link... I'll give away the ending and say that Tcl winds up looking pretty good.

CMcC I really dig the tcl encomium in Mars Rover Project

WJP I came across an interesting positive mention of Tcl in GNU Autoconf, Automake, and Libtool. In the chapter on Unix/Windows Portability there is a brief subsection on scripting languages at p. 172. It talks exclusively about Tcl/Tk except for the last sentence: "Other portable scripting languages are Perl, Python, and Guile.". I think its interesting to see Tcl/Tk front and center in a book with a strong Unix and indeed specifically GNU orientation.

IL From the Expect faq at nist http://expect.nist.gov/FAQ.html ,

 >I have nothing against tcl as such.
 >The reluctance to learn it comes mainly from the feeling that half my
 >life seems to be spent learning new languages that differ very little
 >from existing ones, and differ in annoying little details at that.
 >To add to the misery, every implementation has its own

 Ironically, Tcl was written specifically to halt this very problem.

 The author recognized that every utility seems to have its own idiosyncratic .rc file or 
 programming language.  Tcl was designed as a general-purpose language that could be included 
 with any utility, to avoid having everyone  hack up their own new language.

 In this context, your statements do Tcl a great disservice. 

Amen, brother, amen. :) In addition, while there isn't a specific quote for TCL I can think of the swig author uses TCL as the introduction to the functionality. The entire article paints TCL in a favorable light.

escargo 25 Oct 2005 - I found this looking for information on software testability: Hey Vendors, Give Us Real Scripting Languages [L36 ]

One detail from near the bottom:

Comment: It's nice to see someone else that speaks out against all these proprietary (non-portable) script languages (a.k.a. "vendorscript"). About 3 years ago we switch out internal (home grown) test automation tool from our script interpreter to TCL (and have never looked back). TCL has many nice features with the main ones being readability of the script and its support libraries. Its user community offers great support and it is one of the easiest languages to learn (especially if you skip the GUI "Tk" stuff). I just can say enough about TCL verses the other script languages (including VBA, ECMA, PERL). With its BSD style software licenses ... ~ Michael Jacobson (11/21/01)

Author's Response: I've used TCL and am rather fond of it. You're right: any vendor can bundle it with their tool. I don't know why more don't. ~ Bret Pettichord (11/28/01)

Lars H: On 2006-03-21, the Software Map on sourceforge.net [L37 ] reports

    Hardware (1522)
    Most downloaded: Tcl
    Most active: Tcl

Now, why Tcl should be in this category is not obvious, but it's cool to be #1.

In an ACM interview [L38 ], JG (James Gosling - the guy responsible for Java Virtual Machine) says:

EA Let me ask about a language that may be a little closer to home: Tcl/Tk?

JG That one is pretty nice. It's the child of its environment. It's really very much scripting for C where the data type is all strings, and it works really nicely for that.

iRules Concepts: Tcl, The How and Why:

"F5 uses Tcl as the interpreter for iRules. Many people often ask why that is. This questions is usually followed up by an immediate, "Why not Perl?" or "Why not Java" or "Why not <fill in my preferred language of choice>?". I understand the question, and frankly I'm a Perl guy from way back myself, so when I first landed at F5 and started devouring all things iRules, I was curious about the same thing. Since then I've discussed this topic with some of F5's best, in my opinion, and have come to understand that there are many solid reasons for choosing the runtime that we use.

When asked "Why Tcl?" my standard response centers around varying degrees of discussing:

  • Speed
  • Embeddability
  • Usability

These all remain true today, and I will expand on each of them in hopes of illuminating our position with Tcl and iRules, and why the Perl lover in me was, and is to this day, convinced that we made the right choice."

F5 DevCentral: "iRules Concepts: Tcl, The How and Why" [L39 ]

The ensuing discussion on Reddit was also mostly positive - CGM.

SEH 20120412 -- Extensive performance test (speed, memory) on string handling, comparing Java, C, Perl, Tcl and several others: [L40 ]

tl;dr -- Tcl speed middle of the pack, memory usage one of the lowest.

I noticed that the Tcl test code was not put into a proc, hence not bytecode-compiled.

Tcl was invented around 1988 as a distillation of the fundamentals of programming language which had been learnt over the previous decade. Tcl represents perhaps the most concise distillation of what a programming language needs to be, and as such is never likely to be improved on. It is so simple its rules can be written on the back of a postcard with no fineprint. [L41 ]

"it is dead easy to prove that something is overengineered. You may not know it, with such a background, but complexity is a well defined, objective, measurable thing. If you're curious, look up what an 'Algorithmic information theory' is. An existence of a formally simpler model with a more flexible functionality is a very clear evidence that the other, more complex system is overengineered. Just compare something like Tcl/Tk with your awful web stack." [L42 ]

"When you have something to compare with, something as simple and beautiful as Tk, all the complexity of the modern web looks like a steaming pile of stupidity." [L43 ]

"...I've come to a realization that a lot of programming problems can be solved very easily using meta-programming or basically the code that writes code. Some of the potential applications include but are not limited to: extending the language to break away from its limitations, eliminating boiler-plate, creating domain-specific languages.

"So why Tcl and not Lisp? A number of good reasons. Tcl was meant to be embedded whilst there is a very limited amount of Lisp implementations that were meant for that exact purpose... Tcl is arguably more powerful than newLisp: everything can be mutated and you're not stuck inside dynamic scoping - you have both: the dynamic and the lexical one! I also like the fact that if need be the code can be simply manipulated as text whereas in a Lisp you're committed to lists. It provides yet another degree of power unheard of in Lisp land. Tcl is very easy to build and is about as fast as the vanilla Lua interpreter. Unlike Lua Tcl is a minimal language following the extend it as you go philosophy of Lisp and that's exactly what I want in my programming languages." --Alisa Dolinsky

"Once you accept that everything is a string, you’ll enter a zen-like trance and every atom of your being will vibrate in harmony with Tcl’s interpreter." --Dave Ray

"I develop speech rec\tts applications, commercially. Went to AVIOS looking hoping for a quick meeting with one of Microsofts Speech\Language product managers in order to demo the product and determine if I had may head screwed on straight with regard to the best use of available technologies.

He said ten minutes at most, had two other presentations to make. Forty-five minutes later, after interacting with the bot\simulator, he stepped back and said 'I know what language you used - Tcl'.

Blew me away. 'How could you possibly know?' His response 'Cause it would be nearly impossible to do this with any language that Microsoft makes available'" [L44 ]

"Matlab / Octave is a lot like SQL and Tcl: lots of haters, unfashionable, but usually the most elegant solution." [L45 ]

"Why Tcl is 700% faster than Python for database benchmarking" - HammerDB maintainer [L46 ]