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:
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".
> It's like searching wikipedia but always landing on the "talk" page.
I think the TCL wiki is old enough that it dates to the era when that was what a wiki was supposed to be. The original c2.com wiki has a lot of that flavor too. The Wikipedia idea of having main pages that serve as working drafts of "articles" and moving the discussion to separate "talk" pages caught on a few years later. Of course that doesn't preclude switching now...
Tcl suffers in this respect from the same problem that FORTH does - the language is so malleable that everyone does it their own way. For example, before tcl got it's own native OO system, there were LOTS of competing OO systems, some which were compiled extensions, others written in pure tcl. All had proponents, none were standard.
Within the tcl community, this problem is well known, it just seems no one has the time to take on the enormous, thankless, never-ending task of curating all the useful bits that have been dropped over time. A few wikignomes bravely try to improve things, but it is like moving a mountain of sand with a pair of tweezers. (or emptying a well with an eyedropper).
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.
Maybe we get different search results. When I search for 'perl json' it leads to 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 '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?
If it helps, I've recently used huddle[0] to create arbitrarily-nested dictionaries and output JSON of them. It can be quite slow to do a jsondump for large dictionaries though: it sometimes takes a few minutes to output a multi-megabyte file.
And, to add to your point, it wasn't even listed on the JSON page you mentioned until the "Misc" conversation section.
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.
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
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.
Funny, I used Python for nearly a decade before ditching it for Tcl, and I
haven't looked back. I've used Tcl daily for years now, and haven't
experienced the issues you describe. I've never had any more difficulty in Tcl
than I had in Python finding the error locus based on error output. On that
rare occassion that a brace character conflicts with commenting a chunk of
code, some simple idioms come to the rescue. How often do you find yourself
commenting out just the first line of a proc definition, not the whole proc?
Everything-is-a-string is not any more dangerous in Tcl than any other
language, since the same rule-of-thumb, "don't execute untrusted code", doesn't
require any more care than any other language. It's also not inherently slow.
Look into the the "dual-ported" aspect of the design of Tcl and you'll find a
brilliant mechanism that provides everything-is-a-string semantics at the
script level while using structured representations on the implementation side.
Uplevel and upvar are powerful, and call for judicious use. People complain
about the dangerous things that can be done with them. I find that aspect of
Tcl liberating. It gives the script author total control, and the script
author is in turn expected to develop the skill to wield the tool.
The world seems to have embraced SQLite. It's less well-known that its author
designed it specifically for use with Tcl and is himself a proponent of Tcl.
Tcl is so unique that it's really difficult to discard all the psychological
baggage of other language traditions and catch the zen of it. But once you get
in the zone, it's a really fun place to be. It's the only language out there
that can be anything you want it to be. Someone recently challenged me to make
Tcl do this:
I've taught both Python and Tcl to kids and teens, and have had had much better
results with Tcl. With Python, the lessons have more of a "learn Python"
flavour, but with Tcl the flavour becomes "learn programming".
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.
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.
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
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.
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
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 - which was forked from AOLserver some time ago, just released a new version yesterday.
Almost all of my exposure to TCL was IRC clients (xircon) and bots (eggdrop) in the 90s. Also my first job used it in some capacity that I forget, but it was through the tcl at that job that I had my first exposure to an event driven framework with chaining (twisted python style). It's a pretty odd language, but has some interesting and powerful ideas in it.
Expect[1] (a Tcl-based tool) is still quite useful despite its age, and Don Libes' book[2] is a devops classic (if there is such a thing). The examples directory[3] from expect's source code repository should help you get the flavor of good Tcl programming.
`brew install expect`
`apt-get install expect`
Readily available on many other platforms as well, including Windows.
I can vouch for (1) being correct since I am managing an HPC Cluster for a company right now. The way to to is modules.sf.net (or the newer and nicer Lmod which is Lua).
The usual need is for a multitude of versions being avaible and easily usable. This starts at the compiler level and goes up to stuff like I have 5 versions of Tool X. This needs Python 2.7.3 (yes exactly that version). Now make it easy for me to use it.
It has been my only touching point with TCL so far -- I. Don't. Like. It.
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.
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.
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.
I think Tcl's popularity in EDA has to do with the fact that the very first EDA tool, Magic, was scripted in Tcl. In fact, Magic and Tcl were written by the same person.
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.
Mentor Grpahics Calibre has a very good interface written in Tk. Also some utilities from the Encounter suite have Tk interfaces (not the whole suite of course as Tk is not suitable for graphicslly intensive applications)
The other thing I use Tk for at work is writing test scripts for hardware. Often the hardware has a serial port or an ethernet connection in it somewhere. Tcl includes serial port support, and also has an event loop that supports callbacks for both serial port and sockets. I don't think _any_ other solution beats Tcl/Tk for this type of thing. In a way, it's a shame so few people know about Tcl/Tk these days ...
For my modelsim scripts, I usually incorporate a menu in the main modelsim toolbar for my projects. The menu will incorporate menu items for things like library compile, rtl compile, testbench compile, listing all available testbenches for selecting and running. Usually my menu will be organised using submenus. That sort of thing is very quick to do, and it makes developing RTL a little less painful.
I stand corrected. Added in 2013! That explains why I haven't seen it. It won't see its way into the EDA tools where I use it for 10 years. :)
http://wiki.tcl.tk/21276
I disagree. Complex scripts end up having wonky naming conventions and odd dependencies as procedural code gets longer and longer. I'd much rather see code grouped together in classes. Its clearer when code is grouped together, easier to see the purpose, and can help reduce the spaghetti I so often see... IMO at least.
OK. I'd stick with procedural, but if you want OO there are plenty of options, your best choice would depend on how OO intensive your use of OO would be. If you want to use a lot of OO features (inheritance, etc) then a Tcl extension would be your best bet. You should be able to find something suitable even for Tcl8.4, which I think is still used in some EDA tools, even though 8.4 it's no longer developed :). At the other extreme, if you were just thinking of classes for scoping variables and procedures, but aren't going to be creating more than one object of a "type", then consider using namespaces instead. Another alternative, somewhere in the middle ground, if you wanted a class for scoping and for creating multiple objects of a "type", without heavy use of other OO techniques, then you don't need a Tcl extension for that, you can do that with about half a page of code. Dare I say it, you should be able to find all that stuff on the Tclers Wiki :)
I'll give you defacto standard, but all of the vendors have their own flavor (Synposys, I'm looking at you). Cadence still actively develops their Skill language (Virtuoso). I just saw some VPX last week too. I see it as a very old language that hasn't evolved like almost every other decent language.
> I see it as a very old language that hasn't evolved
Part of the point of the referenced article is to dispel such notions. In fact, it has evolved aggressively and continues to do so; e.g.: coroutines, effective threading, Unicode, virtual filesystems, programmable channels, etc. -- many of whose features are unmatchable in other languages.
LOL, I've always wondered why TCL didn't become more popular since it has a lot of advantages, on paper. The one thing that really turned me off of it was the way it looked, really butt ugly.
oh, its hideous. Especially when hardware design engineers write it. No tests, no real comments, just code that didn't work commented out. For all of the flack PHP receives, TCL is a hammer with the steel claw removed and replaced with a picture of a butterfly.
Yeah, I'm a hardware engineer, and I've come across code like that! But it's not Tcl's fault that hardware engineers can't write code, or even comments to go with the code.
I guess beauty is in the eye in the beholder. I like the syntax, but you're right that a lot are put off by what the syntax looks. If you get past that however, it's a very, very nice bit of kit.
Many EDA tools are using outdated versions of Tcl. 8.5 and 8.6 added significant improvements with hash objects and native OO among them. I've been writing a Tcl clone for use in VHDL and I'm happy with where the language has gone. It was only meant to be used for scripting in the original sense. I like to think of it as the executable JSON with shades of lisp. Detractors should realize that it is still well suited for its niche.
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.
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.
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.
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.
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.
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.
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.
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
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.