What is Tcl?
wiki.tcl.tk
wiki.tcl.tk
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".
That is why tcl is dead.
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...
And, to add to your point, it wasn't even listed on the JSON page you mentioned until the "Misc" conversation section.
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).
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.
When I search for 'ruby json' I get 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?
* 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.
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
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.
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
Coming from C/C++ it drove me nuts.
# I want to escape the { in the next line
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:
http://kazimirmajorinc.com/Documents/Crawler-tractor/index.h...
No problem:
http://wiki.tcl.tk/40445
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.
> It seems to be used in GUIs for biological and medical
> sciences only, which is distant from my field.
`brew install expect`
`apt-get install expect`
Readily available on many other platforms as well, including Windows.
[1] http://www.nist.gov/el/msid/expect.cfm
[2] http://shop.oreilly.com/product/9781565920903.do
[3] http://expect.cvs.sourceforge.net/viewvc/expect/expect/examp...
http://www.gnu.org/software/dejagnu/
It works for what it does.
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.
For example have a look at the build scripts in MacPorts, those are valid Tcl programs (if you load the needed procs first). https://guide.macports.org/chunked/development.examples.html
As Tcl is very often used for DSL style usecases, you might mistaken Tcl code for more or less pseudo code, config files or something like that.
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.
It lacks some advanced features, but so does bash- to me, Tcl makes the most sense when you think of it as a shell.
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.
I think of it as lisp's rather less clever little brother.
Untrue. Part of the point of the referenced article is to dispel such outdated misconceptions.
I quite like Tcl. Many of the 3D graphics packages have a Tcl console (at least the older ones do) and the OBJ file format is basically a Tcl file.
Tcl/Tk was a fast and easy way to get a GUI up and running on Unix/Linux. Expect is still extremely useful at times.
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.
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.
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 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.
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.