I am forced to use tcl a lot at work because that's what the ASIC tool vendors settled on for a scripting language. It's awful. Just plain awful. I avoid it as much as I can, but I'm forced to use it thanks to Synopsys.

The Synopsys extensions are a bear to work with but at least you can define procs which was impossible to do with their old scripting language where you had to simulate them with repeated includes.

...TCL doesn't have macros, it has fexprs, and uplevel. It also has no effective hygene mechanisms, and unless you want to use regex to parse the tree every time your function fires, you can't do the kinds of code transforms macros can.

Don't get me wrong, TCL is super cool, but it doesn't have quite the same powers as lisp. Although you are correct, it's a better lisp than ruby.

Do you know about the sugar package? Sugar implements real lisp macros.

http://wiki.tcl.tk/11155

Huh. Meh, the lack of Macros aren't a problem. The problem is lack of arbitrary code transformation, which isn't as fixable.

There is arbitrary code transformation in tcl through subst or string map

Yeah, because regex is so great at parsing code. It's not like that'll break in unexpected ways. And we all just love writing parsers in our macros.

Oh, wait.

Wish more people understood this about tcl

Maybe this is meta (the wish) :-)

I remember tcl in the early 90s then it disappeared from my radar, mostly web and mobile apps. Honest question: is it still relevant in some application area?

It's still great at what it was always great at: embedding, acting as a CLI, and doing random grunt work. It's Lua's main competitor, but it can also go toe-to-toe with python and ruby in terms of libraries in some areas (although by no means all of them). In particular, the ease of construction for graphical applications is arguably unmatched (IUP is probably the closest), SQLite was built to work with it, metakit is handy as well in the DB area, it has a great event loop, several OO models, solid unix integration, sold FFI and excellent embedding (as you'd expect), Starkits, which means you can distribute your whole TCL sourcetree as a single file, and a ton of other stuff.

So while it's not as popular, relevancy isn't an issue.

This comment is a great representation of tcl's relevance, which is nice to see because tcl is often dismissed nowadays by people who don't understand it

Hah yeah I realized that meta joke after I posted

Tcl was what made possible one of the best startups I had the privilege to be part of.

They had a Rails like stack in the first .com wave, but implemented in a mix of Tcl, Apache and C.

Can I get your email? Would love to hear about that stack

It had an architecture similar to AOL Server, just that the founders did their own thing instead.

Tcl was used for almost everything, C for performance critical modules and DB FFI.

The interpreter was loaded as an Apache module.

We supported Informix, MS SQL Server, Sybase SQL Server and Oracle.

All major UNIX variants from late 99's and Windows NT/2000.