6 ms·
I actually was forced to use Tcl recently on a project, and I came across this article at the time. It so happens that I was getting into Lisp at the same time
by jgw 14y ago
I actually was forced to use Tcl recently on a project, and I came across this article at the time.
It so happens that I was getting into Lisp at the same time, and the parallels between them are obvious. You effectively get macros, so it's a pretty expressive language. There's even an object system in Tcl based on CLOS. But ultimately, it feels like a language with lots of good ideas, implemented poorly. I'm not a PL theorist or purist, but "everything is a string" constantly feels like a really poor abstraction.
Tcl is practical for small, quick projects, but you soon run into insane things like the fact that curly brackets are syntactically significant in strings - and comments.
- ZoFreX 14y ago> curly brackets are syntactically significant in strings - and comments. The latter trips me up far more than I would like to admit :( It's a great example of the nature of Tcl as a language, though. Sometimes I love the simplicity, sometimes consequences of it drive me nuts. For those who haven't used Tcl: You write comments like this: # this is a comment But, in keeping with Tcl's simple and tiny nature, this isn't a special case. "#" is simply a procedure that ignores all arguments supplied to it! While this is extremely elegant, and means you could implement comments in Tcl itself rather than the interpreter, it does mean that you have to balance your curly brackets within comments, which is hugely annoying when you forget.
- rotskoff 14y agoI use Tcl for a number of analysis scripts inside some scientific software. Recently, I came across a situation in which I had nested loops: for {set i 0} {$i<$n} {incr i} { # Some comment for {set j 0} {$j<$n} {incr j} { The script refused to run and eventually I figured out that the comment was somehow impeding execution. I still don't understand why.
- engtech 14y agoThis also breaks, because comments are syntax. proc some_proc {a b} { } # some_proc
- ZoFreX 14y agoThat's easier to explain though - you are passing the arguments {a b} { } # and some_proc to the procedure some_proc. Because comments are just another command, the # has to be the first non-whitespace character on the line.
- vorg 14y agoBased on the instructions in the article (tho I haven't tried it out), putting a semicolon before the hash would work... proc some_proc {a b} { } ;# some_proc
- ZoFreX 14y agoAre you sure the comment didn't have some curly brackets in it or something like that?
- ul5255 14y agoTo my best knowledge, the hash mark comments are parsed as comments by the Tcl parser. The interpreter will not execute a "hash mark" procedure. You can check for the parsing and semantics of Tcl by googling for "Tcl dodekalogue".
- karl_gluck 14y agoI actually wrote some code to find unbalanced braces in the codebase I was maintaining at work. One big downside of Tcl is that the parser gives you practically no help with syntax errors--never a line number, and only sometimes does it give you context. Another common mistake is that curly brackets are VERY significant in [expr]. The author writes statements like "expr $i * $i" in several places, and it makes me cringe for two reasons: 1- This code prints "5" because expr does a double-substitution: set a 5 set b {$a} puts [expr $b*1+0] What's going on here is that $b is evaluated (to the string "$a") before calling expr, then expr itself evaluates its argument: $a*1+0 to 5. This is a problem because $b can be anything--for example, a call to [eval] arbitrary code. 2- Calling expr without putting braces around the argument is unfathomably slow. Tcl precompiles procedures as much as possible, and calls to functions requiring dynamic evaluation (like eval or expr without braces) can't be precompiled. I once solved a huge performance problem by finding and fixing calls to expr made without braces. What was a process that took 40+ hours to finish was reduced to around 45 minutes by this change alone. edit: formatting
- tarabukka 14y agoWhy do I see people talking about this kind of thing in Tcl being perfectly okay, while PHP is nowhere near as randomly dynamic and gets a lot of hate?
- mst 14y agoI suspect for two reasons - first, that Tcl is always dynamic the same way and in clearly documented places, whereas PHP is a lot less consistent about it; and second, that in Tcl a lot of the core language constructs do so, so it's something you get familiarised with early rather than bitten by later. Plus, PHP users seem to be most likely to either go "err, so?" or "YOU DON'T UNDERSTAND THE TRUE GLORY OF PHP!!!" in response to being asked about it, whereas Tcl users generally tend to respond "yeah, you need to learn about that and get used to it" - which tends to significantly alter the next comment made. (not trying to imply that PHP doesn't have users in the third category, just that the first two are the more visible and it alters the discussion's tone)
- 14y ago
- luser001 14y ago> But ultimately, it feels like a language with lots of good ideas, implemented poorly. I'm not a PL theorist or purist, but "everything is a string" constantly feels like a really poor abstraction. I see where you're coming from, but IMHO: Tcl's ideas make total sense if you understand why the language was invented. The name is the hint: Tool Command Language. It was never intended to be a "proper" programming language, AFAIK. That is, a "sh++" CLI to be embedded in big programs. The role of the CLI is to be a thin layer between the data structures in the embedding program and the user. The EIAS approach makes it easy to write commandline scripts. I've seen non-programmers abuse the hell out Tcl but the underlying C function still got the correct arguments.
- smrtinsert 14y agoYou can also write your own object system in like half a day, I think you peeked, but didn't completely open the door.