Version 47 of Who says Tcl rules...

Updated 2016-02-06 22:06:51 by SEH

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!)


"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.

ee


"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. [L1 ]

     - 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. [L2 ]

     - Dr Nikolai Bezroukov

On comp.lang.tcl [L3 ], 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 [L4 ]:

"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: [L5 ]

"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 [L6 ] (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
 >idiosyncracies...:-(

 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 [L7 ]

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 [L8 ] 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 [L9 ], 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" [L10 ]

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: [L11 ]

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. [L12 ]


"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." [L13 ]