4 ms·
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 t
by pslam 12y ago
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 12y ago>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 12y agoAlso 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.
- krupt 12y agoNope, sorry, that was never true. I just peeked at the source for 2.1 (which is on sourceforge) and comments are the same as today.
- pooryorick2 12y agoFunny, 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: http://kazimirmajorinc.com/Documents/Crawler-tractor/index.html http://kazimirmajorinc.com/Documents/Crawler-tractor/index.h... No problem: http://wiki.tcl.tk/40445 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".