
Tcl the misunderstood (2006) - throwaway344
http://antirez.com/articoli/tclmisunderstood.html
======
arnsholt
An interesting corollary to concept 5 (the fact that everything in Tcl is a
string) is that this means that Tcl is actually homoiconic. It does it
completely differently from Lisp, but still ends up in the same place: code
and data have the same representation.

~~~
NigelTufnel
Interesting. I've never worked with Tcl, is it possible to write Common Lisp
loop macro in Tcl?

~~~
takeda
I'm not familiar with lisp loop macros, but here is how this works.

For example the Tcl does not have try-catch-finally statement. If that happens
in other languages you just need to accept it. In Tcl you can implement it
yourself for example:

[http://code.activestate.com/recipes/68396-try-catch-
finally/](http://code.activestate.com/recipes/68396-try-catch-finally/)

------
ewindisch
TCL is great at being an embedded language, especially when you want something
that looks like a DSL using safe-interpreters. (Basically, these are sandboxed
interpreters with access to limited built-ins, plus any methods you might
inject into the global namespace)

TCL lends easily shell-like syntax so it is great for adapting your DSL to a
REPL and even maps fairly cleanly to REST.

Years ago, I built a REST-like API that had one URI to which one could POST a
TCL script. That script in its most basic form would be a series of pipelined
API calls. There was even limited transactional support. I saw this important
for mobile applications as it would reduce latency.

While the scripts were technically TCL, it was easier for developers than
Javascript or Ruby (which we also beta'ed). It didn't look as much like a
programming language as it did a series of shell commands.

The biggest problem with the above is that TCL safe interpreter still allow
loops and other blocking operations. It means that you need to write a reaper
to kill long-running threads / processes.

Combining such techniques with ZeroVM (or even Docker, or both) would be
interesting.

~~~
bch
Since Tcl 8.5 (Dec 2007) interps have timed resource limits available for
them.

    
    
      bch$ tclsh8.5
      % interp limit {} time -seconds [expr {[clock seconds] + 15}]
      % while 1 {set a 9} ;# 15s elapse, then...
      time limit exceeded
      bch$
    
    

edit: Add release date for Tcl 8.5

------
Spooky23
I agree with the sentiment, but who is actually claiming that TCL is a toy
language? Random uninformed people on Reddit opine about all sorts of stuff.

It is an old language with lots of cruft, but it's been used in all sorts of
places for something like 25 years. Perhaps people's experiences with the
language are colored by using it as a means to customize behavior in some big
hairy enterprise app.

~~~
sliverstorm
I don't love TCL, but "toy language" is frankly a _comical_ representation. At
least from what I see, it's practically the exact opposite. Nobody I know uses
TCL because they like it or because it is fun; they use it because they _must_
, to get work done (to control big hairy enterprise software).

~~~
lilyball
> Nobody I know uses TCL because they like it or because it is fun

I haven't written TCL in a few years, but back when I did (when I worked on
MacPorts) I actually did think it was fun.

------
j45
Tcl is certainly not a toy language. I was introduced to it when running an
eggdrop bot in the irc days, and I suspect for many of us was one of the first
more feature complete languages we had no choice but to learn because we
wanted to add custom functionality to our bots.

I haven't kept up with it and enjoyed seeing there's still those who find it
productive

~~~
vog
Well, back in those days (around 1998-2002), when I was a kid at school,
Eggdrop bots were a bit slow, which often became an important factor on
channel wars: channel overtakes, net splits, and so on.

So we (some friends and me) created our own bot (with a very simple DSL) just
for fun in pure C, and it was very fast
([http://davis.sourceforge.net/](http://davis.sourceforge.net/)). Of course,
our DSL was never as well designed as Tcl.

~~~
j45
Haha! I didn't get much into channel wars, diplomacy got a lot further when
there was always legit bandwidth kicking around.

Tcl in some ways was the cause of, and solution to a lot of problems on IRC..
I ended up becoming friends with some of the people who'd try to takeover a
channel I might be in and we'd realize we had more in common than not, such as
how to customize those damn bots. Still have some of those friends years
later, and I'm not sure if I'm the only one. Tcl feel good story.

------
nivertech
Funny, that recently I was thinking how elegant and LISPy Tcl is.

I just finished building a CAD-like visualization utility in Tcl/Tk which
using a complex Tcl-based internal DSL to define complex multilayer
geometries.

Tk and it's Canvas widget are great for things like this.

Many years ago I also wrote an IDE for Image Processing algorithm development
in Tcl/Tk, which also heavily used Canvas. I was able to build a complex GUI
Imaging application literally in the wish shell, all while learning Tcl/Tk and
[Incr Tcl] OOP system.

The trick was to bind key like F11 to reload source files and redraw GUI.

For the Image Processing stuff or anything else compute intensive - Tcl was
very slow, so I either spawned external processes or used native implemented
Tcl commands.

Tcl versions changed native command API, so many native extensions weren't
ported to newer Tcl versions. I have some code that uses old 2001-based Tcl,
because the native packages weren't ported.

I know that there is a package manager for Tcl, but I don't think it's widely
used.

So, if you need to glue many different utilities with simple control logic and
put some GUI above it - Tcl/Tk is great.

------
aristus
Back at the beginning of time I worked with Vignette StoryServer, which spun
out of aolserver, one of the first "database-backed dynamic website" servers.
The scripting language was TCL 7.something.

I never encountered it again, but its elegance always stayed with me. Except
for uplevel. Fucking evil.

~~~
gaius
It gives you the capability to extend the language itself, something you can't
really do in most other languages. Tcl, Forth and Lisp are the only ones I can
think of. These days you get "monkey patching" and so on, but it's nowhere
near as nice.

~~~
draegtun
Rebol, Smalltalk, Perl6 and Io are some other examples that have the
capability to (easily & cleanly) extend the language itself.

re: uplevel - Interesting Perl5 has this feature via a CPAN module! -
[https://metacpan.org/pod/Sub::Uplevel](https://metacpan.org/pod/Sub::Uplevel)
Also another variation is
[https://metacpan.org/pod/Scope::Upper](https://metacpan.org/pod/Scope::Upper)

------
fuzzix
> i18n just happens

No it doesn't... unless machine translation is "there" and built into Tcl.

> Every string is internally encoded in utf-8, all the string operations are
> Unicode-safe, including the regular expression engine. Basically, in Tcl
> programs, encodings are not a problem - they just work

Really? Perl's Unicode support is pretty much second-to-none, IME, but you
still need to know the encoding of your file handles and so on. Once it knows
this, Perl will Just Work(TM). How is this handled in Tcl?

~~~
binarymax
I don't understand the purpose of your comment. OK so perl is great. This
article isn't about Perl...it's about the semi-obscure and commonly
underestimated Tcl (which is also a great language).

~~~
fuzzix
To state the problem explicitly, internal storage format of strings doesn't
mean you can handle all data streams seamlessly. Internal consistency is fine,
but ultimately your program will have I/O.

If I open an ISO-8859-15 or UCS-2 file in a Tcl program, how is this handled?
Does it seamlessly detect encoding and translate to UTF-8 or is there more to
this issue than what's stated in the article? Also, are the strings stored in
a canonicalised form? If not, how simple is it to perform normalisation?

I brought up Perl because it's my experience of a language with excellent
encoding support and helps make the point that the issue is probably more
complex than just how strings are stored and manipulated internally.

~~~
mst
This article is from 2006.

Perl's unicode support is excellent now. In 2006 5.10 wasn't out yet, and
anything before 5.8.5 had all sorts of odd unicode bugs.

Or: Tcl got there significantly before we did.

~~~
fuzzix
That is a fair point, but I'm not trying argue that Perl is somehow better. I
am just using it as a reference point. I'm more suggesting the article may be
overstating the ease-of-use / capabilities of Tcl.

To be clear, I'm not arguing against using Tcl in favour of Perl or anything
else. It's just that my experience with a language with great encoding support
doesn't jive with what's claimed here.

~~~
na85
Well I think that particular clause was written for C-style language users
where the unicode support is definitely subpar.

------
VMG
I came away from this impressed, but still thinking that it is a "toy
language" in the sense that it is too powerful. You sometimes do not want to
have to worry what a line of code means, and TCL does not allow that.

> The Tcl community developed a number of OOP systems, radical language
> modifications, macro systems, and many other interesting things, just
> writing Tcl programs

Well there's your problem. It becomes impossible to learn the language as a
whole, because it is so flexible and everybody does things differently.

~~~
na85
>You sometimes do not want to have to worry what a line of code means, and TCL
does not allow that.

Comments in Tcl work perfectly fine.

~~~
dded
> Comments in Tcl work perfectly fine

I agree with what you're saying, but allow me to go meta.

Comments in Tcl are a bit strange. This works:

    
    
      # say howdy
      puts hello
    

But this does not:

    
    
      puts hello   # say howdy
    

For the later, you have to insert a semicolon:

    
    
      puts hello;  # say howdy
    

I get bitten by this time and time again.

~~~
na85
Yeah I got bit by that too, once. But it makes sense. If everything is a
command, then "#" must also be a command. Essentially like a NOOP.

Once I visualized it that way, I never got tripped up by that again.

And regardless of this fact, comments exist. They may not be as convenient as
using // or / __/ in C its friends, but they exist. To say that _tcl does not
allow one to know what a complicated line of code means_ is absurd.

~~~
dded
> If everything is a command, then "#" must also be a command

In my mind, that's an argument that at least something shouldn't be a command.
But perhaps it simplifies implementation enough to be worth it.

> To say that tcl does not allow one to know what a complicated line of code
> means is absurd.

Fully agree with you there. And for what it's worth, in the Tcl I encounter,
there's rarely a line of code that complicated. Perl is often accused of being
a write-only language. I think Tcl, if anything, is the opposite. It always
seems readable.

------
plg
A really nice article to get one started! thx

Another topic I would like to see introduced in a similarly friendly way is
event loops. At my work I am dealing with some Tcl/Tk code that uses event
loops and it's a bit of mental gymnastics to get my head around what gets
executed when.

------
justincormack
Although antirez made the sane choice of embedding Lua in Redis.

------
0xdeadbeefbabe
upvar always eluded me. TCL got heavy use at AOL in aolserver, a project that
just switched from CVS to git
[http://www.aolserver.com/](http://www.aolserver.com/)

