Tcl the Misunderstood (not too new) | Hacker News Reader

Tcl the Misunderstood (not too new)

antirez.com

31 pointspmarin17 comments

True John Ousterhout (creator of Tcl) story.

I worked for John for many years, but our first meeting (when he was interviewing me for the job of VP of Engineering under him) was when he met me for lunch at Scott's Seafood.

Early on in the lunch interview he said "You've probably heard of me..." and talked a little about Tcl and his experience. Unfortunately, I had said "No" almost as soon as the first five words were out of his mouth.

So, then he was forced to tell me about Tcl (which I had never used) and went on to explain that Tcl was a really easy language for people to learn (which he illustrated with various interesting examples) and that it incorporated a complete regular expression engine from a lot of power was derived.

Right there, I blurted out "Don't you think those two things are contradictory? It can't be easy to learn and have regular expressions since regular expressions are one of the hardest things for a novice to pick up".

His eyes sort of bugged out of his head and he said, "Oh. Perhaps you are right. I hadn't thought of that".

Luckily for me it turned out that making John have a novel thought was the right way to impress him. Despite apparently having a big ego he turned out to be the best boss I ever had, I learned an enormous amount from him and later we co-founded Electric Cloud.

I am a huge fan of Tcl. It's one of those languages that can be intimidating up front (when do I need $ and when not? etc) but it is in fact enormously simple once you get used to concepts like "everything is a command". There is no syntax. # (the comment character) is a command that ignores all its arguments. Tcl's event model makes many classes of applications (network servers, GUIs) much easier to write than in multi-threaded languages (tho' Tcl does do threads too if you need them).

The ability of Tcl to implement new control structures (e.g. Tcl doesn't have do...while but you can easily add it yourself) puts it up there with Lisp as a programmable programming language... I really don't understand why it isn't more popular with hackers. The tcl.tk Wiki has some "Lisplay" articles where people have experimented with Lisp-style coding in Tcl, it's surprisingly easy. And Tcl has the real-world libraries (e.g. GUI, Oracle access, etc) that working programmers need.

There's also AOLserver which still holds up as a nice app server.

The first iteration of our website ran OpenACS on AOLServer. It was an interesting experience. I actually found AOLServer quite charming...but OpenACS, not so much.

I didn't really have any complaints about Tcl, as a language, but OpenACS was really difficult to work with. It seemed like second system effect had had its way with the whole project and in a bad way. So, I ended up scrapping OpenACS and AOLServer, and I haven't touched Tcl since.

I don't think hackers hate Tcl because it's "intimidating". They hate it because it's verbose, slow, and lacking in abstraction power. (Last time I used it, associative arrays weren't first-class, i.e. you can't have a list of anonymous associative arrays; is that still the case?) Also, Tcl was originally aimed at the niche that Lua now occupies — lightweight embedded scripting language — but Tcl is 720k of code while Lua is 82k, and isn't verbose, slow, or lacking in power. Finally, the libraries available for Tcl, while they do cover some pretty important stuff, are a tiny fraction of what's available for C, C++, C#, Java, Perl, Python, or even Ruby.

The article says it's "more or less as fast as ... Ruby". Well, that's pretty slow!

The string-substitution execution model is easy to explain, and it's easy to do higher-order programming with, but it's very error-prone and very difficult to implement efficiently. If you use Tcl in a disciplined way, you won't have too much trouble with this, but it is not nearly the advantage that this article makes it out to be.

Tcl does have some nice advantages: it's optimized for use as a UI with an embedded DSL, not for use as a programming language, and its support for event-driven programming and securely running untrusted code are first-rate. Yosef K. (Yossi Kreinin) recently blogged about some of this.

Oh, and you say, "# is a command that ignores its arguments". You're wrong about that; try "# [set x 3]" or "# comments do not end at semicolons; puts hello" if you don't believe me.

Well, Tcl is faster than Ruby and now we don't use the associative arrays we use the dict instead. What version of tcl have you used?

You seem to think that dicts aren't associative arrays.

I think the last version I did any significant amount of work on was Tcl 8.3. But I wasn't any kind of expert on it then.

It might be true that Tcl (8.6?) is faster than Ruby now, but the article that started this thread didn't dare to claim that, and these benchmarks of Tcl 8.5b3 don't support that claim:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

   # [set x 3]
   set x
   can't read "x": no such variable
   # puts hello
   --nothing happens--

What are you talking about?

Compare the behavior of # to the behavior of puts. If you puts [set x 3], not only does it print out 3, it also sets x to 3. If you # [set x 3], it does not set x to 3, because # is not actually a command that ignores its arguments; it is a comment, just like in Python, Perl, or sh.

Similarly, if # were a command, a semicolon would terminate it and start a new command, but it doesn't. The comment continues to the end of the line.

If # were a comment character in the language you could do this:

    % puts "hello" # hello
    bad argument "hello": should be "nonewline"

But this works:

    % puts "hello" ;# hello
    hello

That's the point; that nothing in Tcl is "special" or "reserved", everything is a command that takes parameters.

I didn't remember that you can't have a comment inside of a statement, but you're still wrong!

It's true that you can't have comments in as many contexts in Tcl as you can in most languages, but it is not true that they are just ordinary statements; ordinary statements evaluate their arguments. "#" comments don't evaluate their "arguments", don't terminate at semicolons, and you can't redefine the meaning of "#" with "proc", so "#" is special and reserved — just in fewer contexts than in other languages that use it as a comment character.

I used Tcl in the 1989-1993 timeframe as my default application configuration language. I stopped doing this when I realized the maintenance problems I was experiencing with my Tcl-based configurations were never going to go away.

Then for a while I used Apache httpd.conf style markup for configurations. That worked better but I missed being able to do the macro-style programming you can easily do in a dynamic language. I tried XML for a while until I realized that it wasn't much better and didn't make things easier.

Then I started doing more with Python and Ruby applications and found that in most cases I could easily just extend whatever configuration scheme the application used for my purposes.

These days I'm using Lua in everything I write that doesn't already use Python or Ruby for the same kind of things I would have used Tcl. Lua is efficient, easy to read by others and plays very nice with the surrounding environment.

So far Lua is working out pretty well but in fairness I spend a lot more time thinking about configuration issues up front than I did 20 years ago.

Tcl is one of the things that got me curious about marketing. The implementation of the language is really nice in some ways (sure, it has its defects too, but so does everything else), so my conclusion was that the problem was elsewhere: marketing. It's hard to find such a cool project that has been marketed so poorly.

Some specific examples:

* Tcl, like Lisp, is flexible enough that it's possible to write an OO implementation in the language itself. That said, it's probably a good idea to call out to C to speed things up a bit. One of the problems that has dogged Tcl is that instead of having one standard OO implementation, it has had multiple, competing OO implementations, which are a splendid example of "the paradox of choice".

* Tk was the cross platform toolkit for a long time. However, around the year 2000, instead of looking at things like Gtk and Qt and trying to improve, some of the head Tcl guys poo-pooed them and ignored them, with the result being that only now is Tk getting a nice looking look/feel update in the form of Tile. Even without Tile, there were some very simple tweaks that would have made Tk look nicer on Linux, that were ignored by the people at the top.

This is out of date largely because recent improvements in Tcl have actually dealt with some of the limitations (apply and dict are the most significant for me, making Tk look more like the native widgets is another), more improvements are on the way in Tcl 8.6.

There are also some really useful things that do not get mentioned there (he says as much): sandboxed safe sub interpreters, easy deployment as a binary, two inline C extensions, etc.

Yes It is out of date but I think the author did a great work explaining the language's features.

I have been able to do powerful things in TCL, and quickly. However, I believe it is one of the most difficult languages to debug, and its maintainability cost is extremely high. You can't underestimate the risk that this is to a project.

Part of the problem is that the language doesn't defend well against bugs. Consider what happens if you pass your index and list arguments in the wrong order to "lindex"...it silently takes the index from your list, and then includes your intended index as part of the list! This is the kind of mistake that can silently appear to work, or fail in subtle ways, and it's not worth the debugging time in my opinion.

It certainly looks cool. Another language in my "To play around with" list :D

Reply on news.ycombinator.com