
What is Tcl? - blacksqr
http://wiki.tcl.tk/299
======
towelrod
I frequently write tcl, and I work in a company that has been using it in
production for 20+ years. I've written thousands of lines of Tcl, but I only
go back to Tcl when I have to work on legacy stuff these days. I wouldn't even
remotely consider writing something new in Tcl.

I really wish someone would take charge of wiki.tcl.tk and cut out all the
nonsense. For example, I am currently in need of producing some JSON from one
of our Tcl apps. So I search for JSON and I get this:

[http://wiki.tcl.tk/13419](http://wiki.tcl.tk/13419)

It starts out pretty promising -- listing a bunch of competing JSON
implementations for tcl -- which is unusual for a wiki.tcl.tk page. But then
it quickly devolves into the usual stream of consciousness that infects every
tcl wiki page. What am I supposed to actually do?

At first we have a big list of different implementations; that makes sense,
every language is kinda like that.

But before the first page is even finished, we get weird "string is double
gotcha" stuff from gchung, including "you should use the following" 100
character regex! How about: you should use this module for doing this usual
thing that every language in the world can do?

Then, we get JMN's thoughts about how a JSON generator is better than a JSON
parser. Apparently TCV solved this himself in 2009 (but, no code referenced).
Very quickly we get into "here's my version!".

I'm not complaining about all these guys contributing different solutions. But
can't the community gather around one of them? It's like searching wikipedia
but always landing on the "talk" page.

Hey tclers, try this on for size. Google for "perl json" and see if you get a
real response that explains how to do it, or a bunch of random guys talking
about how they solved it themselves. Then try "ruby json", "java json",
"python json".

That is why tcl is dead.

~~~
blacksqr
I found your comment, though intemperate, to be illuminating. You criticize
the nature of the first search result you find, but I note the second (in my
browser) points the searcher to the Tcl library packages for processing JSON,
whose docs provide what you ask for: simple explanations and examples on how
to do it.

Now on to the other languages you mention:

> Hey tclers, try this on for size. Google for "perl json"

OK. The first result I get is a man page for a module that claims to be a
bridge for two other modules, one pure perl the other perl+C. There's
paragraphs and paragraphs of warnings about version incompatibilities and
advice about handling corner cases, which if you're not careful about lead to
data loss, because in perl Everything Is Not A String.

First two results for "ruby json" are for gems tailored to two different ruby
versions. Of course ruby is famous for breaking backward compatibility even
for minor releases, so make a choice and it may work out for you. Keep in mind
the reports of massive security vulnerabilities when using ruby to parse JSON.

First result for "java json" is a page full of pointers to class definitions,
and a link to a package whose author claims to have no time to maintain it and
hasn't used it in a decade. If that makes you uncomfortable, the home page of
the first link helpfully provides references to 26 separate Java JSON
libraries.

First two results for "python json", like ruby, are for the unpredictably
compatible versions 2 and 3. Like perl and ruby, there are many paragraphs of
warning about corner cases and data loss because Everything Is Not A String.

The top paragraphs of these results I admit make things look simple, but mask
significant implementation issues that tend to trap the unwary newbie or
explode outright, that aren't issues at all with Tcl.

It may be that the appeal of Tcl will always be limited to a minority who
prefer to discuss a little first and consider issues of compatibility,
stability, scalability, maintainability and security before implementing. Like
the people who run your company? 20+ years in business, presumably it's
profitable.

~~~
towelrod
Maybe we get different search results. When I search for 'perl json' it leads
to
[http://search.cpan.org/~makamaka/JSON-2.90/](http://search.cpan.org/~makamaka/JSON-2.90/)
which is a mature and easy to use JSON client. It does talk about backwards
incompatible changes from version 1.0 -- but that was back in 2007.

When I search for 'ruby json' I get [http://ruby-
doc.org//stdlib-2.0/libdoc/json/rdoc/JSON.html](http://ruby-
doc.org//stdlib-2.0/libdoc/json/rdoc/JSON.html), which is part of the standard
library.

When I search for 'java json' I get several libraries, all of which are
actively supported: www.json.org/json, gson, and Jackson.

I don't really understand your comment about significant implementation issues
that aren't issues at all with Tcl. Could you give an example? What edge cases
aren't covered by the standard Perl and Ruby JSON libraries?

------
schlenk
I don't write much Tcl the last few years (mostly Python now, as it pays the
bills), but looking from the Python perspective towards Tcl, i see a lot of
good things i left behind:

* No GIL. Real threads with no silly global locks

* A very cool VFS layer, a bit like the stuff you can see in windows powershell with the Registry/Certstore/etc drives

* A beautiful implementation really worth a read (no silly 'XXX: don't know what to do, lets print to stderr' inside a library like you find in pythons source)

* An extremly consistent language far more than python which does all kinds of junk 'to make parsing easier' even if it makes the language harder

* Sandboxing interpreters (doesn't work with python, no chance)

* Stacked channels and a cool streams abstraction (Pythons io module is still some way behind its options)

* A built in event loop (Python just got one with 3.4...)

* A standard lib that mostly takes event driven as given (unlike pythons blocking stuff)

* very powerful metaprogramming support (e.g. have some logging code with 'ZERO' overhead when disable at runtime)

* good C-API and excellent support for embedding

* Stable ABI since more than 10 years (e.g. you can load a binary extension compiled against 8.1 into a current 8.6 interpreter and it just works, one of the reasons many Tcl projects didn't release new versions, no need. Unlike the python nonsense with -2.5,2.6,2.7 versions for every package, okay Python got a partial stable ABI now too, years later)

* mostly sane platform abstractions (the world isn't posix everywhere)

* packaging with starpacks (python's pyinstaller comes close, but lacks the VFS stuff, years later), a bit like cross-platform OS X app bundles

* Non mutable values by default, no pointers, so it is kind of functional

* A nice package system that doesn't mix up filesystem layout and namespaces and supports version

So if you look at it, it is kind of a weird crossover between ideas you now
find in: Go, Node.js, Lisp, Powershell. Just a bit outdated and in need of
some love.

------
RHSeeger
Personally, Tcl is by far my favorite language to program in. While I admit
it's not the right tool for every job, but I feel a great sense of job when it
IS the right tool because writing code in it always makes me happy.

When I'm writing pseudo-code for someone, I almost always wind up writing
something that looks like Tcl (which a bit of OO/functional mixed in).

I think there's a number of reasons why I enjoy it so much:

\- I find it's minimal syntax very easy to work with (for normal cases,
admittedly it has it's warts)

\- I've been using it so long (since about '95) that I tend to "think in Tcl"

\- The ability to add new control structures to the language makes simplifying
other code (ie, adding try/catch/finally to the language yourself) amazing.
It's somewhat lisp-like (though not as powerful)

My use of Tcl over the years has spanned many different environments

\- Interacting/automating network hardware tasks (SNMP, Expect, device
scripting)

\- AOLServer

\- Vignette

\- Personal tasks (lots of them)

\- (minor) modifications to the core

\- Plugins/Scripting for various other programs

------
pslam
TCL is an incredibly useful language to quickly construct small code snippets
in, and is especially good as a REPL language - as a command line interface.

On the other hand, it's the bane of my life. It's particularly bad (and
verbose) at anything involving expressions. Unfortunately, that's mostly where
I find it being used, because it's very popular in hardware. You'll find it
being used for emulators, simulator, FPGAs, JTAG interfaces, and so on. There,
it's shuffling a lot of data around, and in particular performing bitfield
operations. It's notoriously verbose at doing all of that.

Hardware register definitions and the like are also usually expressed in a
C-like fashion - that is to say they're usually using square brackets e.g
"some_reg[2]" notation. This is annoying for TCL, because square brackets are
its "string eval replace" construction, so you end up escaping stuff.

Its error traceback, usually "puts $errorInfo", is also awkward and often
doesn't give you the right locality of where the error was, especially if it's
syntax-related. One of the most infuriating aspects is that the comment
character "#" doesn't obey the rules you see in other languages - it's not
like a pre-processed character. Scope rules _still apply_ within comments, e.g
you can open a proc definition and it'll complain about a dangling brace
because it _still parses the comment line contents_.

The everything-is-a-string design is awesome but also makes it inherently
slow, to the extent that even on a modern system it can end up being the
bottleneck in execution. It also results in really weird parameter passing
rules between functions. I'm not a fan of having to occasionally add magic
intermediate string evaluation steps, or the wildcard expansions necessary for
passing lists. It's error-prone and sometimes feels like just hammering the
interpreter until it _Does What I Mean_.

Everything-is-a-string is also damn dangerous, and can result in arbitrary
code execution if you're not careful. Anyone who's ever run an IRC script or
bot has probably experienced this, and knows what I mean.

That's not to say Tcl is crappy. It's just a language which was designed in
another age, and it's really showing it. It's awesome as a command line REPL,
but I highly recommend something else (Python or Lua) if you're doing anything
even moderate scale behind the interface.

~~~
na85
>comment character

Yes the comment syntax can be infuriating if you're not ready for it.

This might not be true any longer, but a number of years ago when I was still
using Tcl,

    
    
        # this was a valid comment
        #this was not a valid comment
    

due to the parser reading "# this" as a comment token followed by its string
arguments (I guess it's semantically a noop that takes a string arg) and
"#this" which threw an invalid token error.

Coming from C/C++ it drove me nuts.

~~~
towelrod
Also in the older tcl (not sure about 8.5+), it would parse { characters
inside comments as if they were real braces in the code. So if you put a
comment like:

    
    
        # I want to escape the { in the next line
    

then it would cause your code to fail because of unbalanced { characters.

------
exogen
I had an unexpected need to write some Tcl recently when I had to wrap a
command line tool in a helper script in order to add some features and
automation. Turns out the Unix tool `expect' was designed exactly for this
purpose and was already available on my Mac, and thus seemed like a practical
solution. Expect programs are written in Tcl:
[http://en.wikipedia.org/wiki/Expect](http://en.wikipedia.org/wiki/Expect)

------
vortico
Despite the numerous books and talk about Tcl, I've _never_ seen any actual
Tcl for two reasons.

1) It seems to be used in GUIs for biological and medical sciences only, which
is distant from my field.

2) There are absolutely no code samples on the surface of tcl.tk or on this
article, and after clicking "Random Page" a statistically significant number
of times I found that only _1 /6_ pages have any Tcl code at all. Even the
tutorial for the language itself has a strangely low code-to-text ratio. It
makes me wonder that the developers are wanting to hide the code due to shame,
or the CEO bosses behind the project only feel that advertising features of
the implementation, applications, and the language's popularity are important,
while in fact these are relatively useless to speculating and beginner Tcl
programmers.

~~~
cleverjake
way back when, a large amount of AOL stuff was written in tcl. AOLServer was
one, and they actually opened sourced it -
[https://github.com/aolserver/aolserver](https://github.com/aolserver/aolserver)

~~~
evilotto
And lest you think that AOLserver is dead based on the lack of new activity on
that github repo (which is just a mirror, BTW), Naviserver -
[https://bitbucket.org/naviserver/naviserver](https://bitbucket.org/naviserver/naviserver)
\- which was forked from AOLserver some time ago, just released a new version
yesterday.

------
Zuider
Tcl was not originally intended to be used for writing large programs on its
own, but to act as an interface to compiled programs.

The actual heavy lifting was meant to be done in C, while interactions with
the user could be quickly prototyped in Tcl. Tk simply added a way to do this
graphically.

The name 'Tool Control Language' points at its intended niche.

~~~
pjmlp
Yes, its FFI API is quite clean because of that goal.

------
sentenced
"That thing you had to know if you wanted to write Eggdrop scripts."

------
abfan1127
TCL is the defacto language in EDA ASIC Design Tools (synthesis, place-and-
route, static timing analysis). In my opinion, its a terrible language,
especially since the tool vendors all add their own flavors. The flow control
is painful to use, it lacks OOP data structures. If given the opportunity, I'd
avoid it at all costs.

~~~
viggio24
I'm in the EDA world since 15 years at least and I'm still surprised why many
(but not all) vendors have adopted TCL as their scripting language of choice
for their public API; my opinion is because it is quite close to shell
scripting and so more suitable than Perl or Python for engineers which are not
experienced with real software development. Another reason is due probably to
the good integration with the Tk UI library that allows to easily associate a
UI interface to some of the scripting tasks, something that is highly
appreciated by many engineers: this is not easy to accomplish if you use
Pyhton or Perl. However I agree that Tcl is a terrible language that I would
avoid for any modern project.

~~~
rffn
I think there is another reason, besides Magic being scripted in Tcl. Back in
the days when some EDA companies decided on Tcl there were only a few
languages which could be embedded. Tcl was the only one with some popularity,
documentation about embedding including sample code and a commercially viable
license. For Perl for instance the embedding feature was largely undocumented
at the time (early 90s I think) and Perl is GPL which is a no-go for
commercial software. Ruby did not exist yet and Python maybe just was not
visible enough.

~~~
viggio24
Very good point, especially the GPL license one.

------
zak_mc_kracken
If you think Brainfuck is a sadistic language, you probably haven't heard of
Tcl's upvar:

[https://www.tcl.tk/man/tcl8.4/TclCmd/upvar.htm](https://www.tcl.tk/man/tcl8.4/TclCmd/upvar.htm)

~~~
cafard
Upvar, properly used, is an excellent tool. Years ago I went looking for an
equivalent of PHP. One of the first links thrown up by Google was a PHP
discussion thread on which the fellow wishing for upvar was told that he was a
bigot (or worse) for even thinking of such a thing.

------
alexholehouse
In the biomedical community the standard way to interact with VMD[0] - one of
the major molecular viewers and really a workhorse of modern biology - is
through Tcl.

I always think this is rather unfortunate, because it means that for many
people, their first introduction to scripting ever comes in the form of trying
to decipher the Tcl docs and just figure out the simplest things.

[0] -
[http://www.ks.uiuc.edu/Research/vmd/](http://www.ks.uiuc.edu/Research/vmd/)

------
pjmlp
A great dynamic scripting language that helped the first startup I worked for,
to have a very capable web application middleware for its products.

Similar to AOLServer, and with features comparable to Ruby On Rails, but
around 2000.

It also taught me that if one wants performance in scalable application
servers, in the end a JIT or AOT compilation support is a must have.

------
trimbo
Fun fact, in TCL, everything is a string:
[http://wiki.tcl.tk/3018](http://wiki.tcl.tk/3018)

Nuke -- the image compositing system used in visual effects -- has included
TCL from its origin as far as I know. That would be 1993. Nuke now offers
Python, but TCL's still in there.

~~~
evilotto
Well, kinda.

The novice says "everything is a string."

The adept says "tcl values are implemented as dual-ported objects, meaning
that the internal representation of every value is automatically and
transparently converted to the type that is needed at that time."

The wizard says "everything is a string."

Everything can be a string. From the outside, everything looks like a string.
And it's considered bad style to violate this principle. But if you're talking
implementation, everything isn't exactly a string.

------
gshrikant
IIRC, Xilinx's EDA toolchain (ISE; I haven't used Vivado) used Tcl for
scripting. So does OpenOCD [1] (a ISP and hardware debugging tool).

[1] [http://openocd.sourceforge.net/](http://openocd.sourceforge.net/)

~~~
kevin_thibedeau
Vivado is even more heavily dependent on Tcl as they've merged all the
separate tools into one application guided solely by Tcl commands. It feels
much more like Synopsys Design Compiler which also migrated from its homebrew
scripting language to Tcl a few years ago.

------
danjayh
If you've dealt with vxWorks and Wind River's toolchain, you've been using TCL
for over a decade.

------
tateeskew
iRules within the F5 BigIP products are written in Tcl. I spent a lot of time
over the last 15-20 years writing/managing iRules and I always quite enjoyed
it. Don't have much recent exposure over the last few years, though.

------
biomimic
This:
[http://genopharmix.com/TuataraSum/index-142.html](http://genopharmix.com/TuataraSum/index-142.html)
100% Tcl.

------
BioVector
I find it the most useful of any language I've used over the years.

~~~
towelrod
Can you expand on this? What other languages have you learned, and how are
they less useful than Tcl?

~~~
estava
I don't know Tcl much. But when I learned about Tk in Ruby I kind of expanded
my knowledge of Tcl since Tk was the GUI toolkit of Tcl that was borrowed by
many other scripting languages.

Tcl/Tk had features like distribution of a deployment binary. It could create
an .exe file for Windows deployment for example.

Tk included a Domain Specific Language for layout/GUI controls which was
useful, without requiring an additional form designer as in other languages.

Others have mentioned Expect above, it was a good reminder, imagine creating a
GUI application to control a command-line tool, Expect allowed for that very
easily, as it could keep open the output/input of the tool it was adding a GUI
to.

Since it included so much by default, the community could easily contribute
with some other tools that you could reuse in your solution. Before "RubyGems"
even existed, people were already reusing libraries in Tcl/Tk. :-)

The problem of other languages is that they come with more abstractions than
people needed. We can fight against "state" in modern programming languages,
but it doesn't change the fact that the more complex we make it, the harder it
is for people to just get something up and running quickly. That's why systems
like Tcl/Tk cannot be retired.

