I can’t believe I’m praising Tcl

About Tcl and the embedded world, a few years ago I wrote a single-file Tcl interpreter that is mostly compatible with current Tcl implementations (something is missing like namespaces, something was added like anonymous functions):<p><a href="http://jim.tcl.tk/index.html/doc/www/www/index.html" rel="nofollow">http://jim.tcl.tk/index.html/doc/www/www/index.html</a> (source code is here: <a href="https://github.com/msteveb/jimtcl" rel="nofollow">https://github.com/msteveb/jimtcl</a>)<p>Now maintained by Steve Bennett, and actively used by some embedded folks.

If one looks at the EDA industry you will have to appreciate the breadth of applications Tcl is used in. Usually there is a Tcl interpreter with custom commands written in C for optimization.<p>The ease with which one can quickly create interfaces between different tools I think is one of the contributing factors to its success. That and of course, the legacy codebase.

You can get lisp to interact more like a console language. Write a parser to accept python-ish whitespace syntax (whilst still allowing parens syntax), and transform that s-expressions so you can pass to the interpreter<p>To imply:<p><pre><code> (define (fn a b) (list (car a) (car (car b)))) </code></pre> You could type:<p><pre><code> define: fn a b list: car a car (car b) </code></pre> As it's a console, in practice you'll mostly be typing commands like this:<p><pre><code> load x y z </code></pre> but you have good mechanisms for going deeper. And if you just want to write in s-expressions you still can.

IMHO, nothing beats Tcl/Tk when you need to write a small distributable application with a GUI. The last ones I wrote were for purging files acording their date and for compiling Forms/Reports. With freewrap I can build an executable with no effort at all.

I think it was antirez who said that Tcl had one of the best C codebases he had ever seen. Since then it's on my code reading list.

I spend a lot of time using Tcl (I have to) and I spend almost as much time wishing I could be using Perl instead. This is partly because of weirdness, as described by the author of this article, and partly because I routinely run into things that seem to be far more difficult to do in Tcl, than they ever would be in Perl.<p>Can I get one of the Tcl adherents in this thread to comment- have I got things completely wrong? Need I simply become better with Tcl? Or does it truly lack things like powerful string handling and hash tables?

I'm not as fond of the language as some, primarily because it is unnecessarily hard to debug errors and unnecessarily hard to read code and data.<p>For example the interpreter can basically say "there's a syntax error somewhere in this giant block of yours" and not have <i>any idea</i> where.<p>A related issue is that a single delimiter (the brace) is bad for readability, even if it's easy to parse. Just try reading a gigantic dictionary; it isn't anywhere near as clear as Python/JSON-style can be (where there are obvious commas, colons, quoted strings and more to show you exactly what you're looking at).<p>Another headache for debugging is that commands frequently accept the <i>names</i> of variables. In unfamiliar code you can't even answer simple questions like "where are all the places 'xyz' is used?" because a reference to 'xyz' could be hiding almost anywhere. You can change something and not fully understand the effects that your change could have. While I'm sure this allows for very clever code to be quickly <i>written</i>, it fails the more-important test of producing code that is easy to <i>read</i>.<p>It is even possible for commands to silently accept mistakes and seem correct, with major consequences. Suppose "x" just happens to be a one-element list containing a number, '{0}'. With this input, "lindex 0 $x" is legal (even though "lindex $x 0" is the correct argument order). Worse, the wrong form <i>returns something that seems reasonable without error</i>. In this case what it <i>actually</i> does is grab the index that it found by magically looking inside the <i>list</i> ($x) and return one of the values from <i>the implicit list containing "0" that was given on the command line</i>; it returns a "0" but not the "0" that you'd think it does!<p>While one can argue that each language has "best practices" and intended usage, the examples above are largely pulled directly from built-in commands and data types. These are things that people encounter all the time, they are not caused by any particular TCL programming practice.

Circa 1999, I wrote a simple reminder script - which I still use - that brings a popup on the desktop, in like 3 lines of Tcl/Tk using the wish shell. I shed a tear at how easy it was compared to anything else at the time. I am not even sure if it's that easy with anything else today.

Tcl is one heck of a Swiss-army knife solution. The core team is of the first order. The best thing is that it's so easy to use pipes to integrate a 'C'/C++ console mode program and control it via stdin/stdout/sockets. That turns out to be a significant architectural plus - rather than using some MVC C++/Java type library, you get complete seperation of concern. You don't even have to integrate it tightly with 'C' code; just use stdin/stdout and wrap a Tcl package to build a pipe around it.<p>Tcl might have been <i>too</i> easy. I also recall ESR dismissing it at one point in favor of Python.

My introduction to TCL was in the mid-90's via Expect:<p><a href="http://www.nist.gov/el/msid/expect.cfm" rel="nofollow">http://www.nist.gov/el/msid/expect.cfm</a>

Isn't that what Ousterhout and his students designed Tcl for? I fooled around some with AOLServer years ago, and have used it with Oracle's "Intelligent Agent".<p>But I didn't know how much I liked it until I Googled for "PHP upvar" and found a forum thread with bunch of people telling some guy that he was a language fascist for wanting such a thing.

Tcl was lua before there was lua. It pops up under the cover as the scripting language of so many useful tools.

I used to really like Tcl and it have one the nicest communities but I think it needs two things 1- a CPAN 2- Killer app (and no aolserver or openacs are not)

I work for a medium-large technology company supplying mission critical software (very large amounts of money are involved). We use Tcl for the vast majority of our software. We may head towards Java in the future, but not so much due to any failings of Tcl, more because it is easier to recruit Java programmers.<p>I think the general consensus at our company is that Tcl was the right choice, although our programmers do occasionally gripe at some Tcl shortcomings.

I love the TCL foreach loops. TCL is the only language that lets you iterate through multiple data structures with the same loop. It is actually really useful. Just try this statement with any other language:<p>foreach animal { "dog" "cat" "bird" } color { "brown" "black" "red" } { puts "See the $color $animal?" }

a scheme repl could borrow a leaf from tcl's book by preprocessing everything you typed in to let you (a) omit the outermost parens and (b) mix () and [] freely. would be an interesting experiment to see if it had a better feel for this sort of interactive scripting

Tcl is a bloody good language+ but seems to have languished in obscurity. I can't count the number of times I've heard people in the Python and Ruby (and Lua and Processing, and node.js, for that matter) communities announce some wizzy new thing that Tcl had 5 or 10 years earlier. I've never understood why that is. The problem with the computing community in general is that it can't see over its own shoulder. Every few years, we reinvent the wheel.<p>+ By this I mean you can get a lot done, in not very much code, and maintain it afterwards, and read and modify other people's code easily.

I did my first professional programming in Tcl/Tk used by a trading system. It was awesome and even though most people have not heard of it when I talk to friends/clients, glad to see this post.

Tcl is an interesting beast indeed, since it takes its extreme love for strings so far, it's actually homoiconic.