4 ms·

Tcl had been a pretty good way to create things like embedded command shells for C-based programs, and this was great as long as people operated in fairly seque

Tcl had been a pretty good way to create things like embedded command shells for C-based programs, and this was great as long as people operated in fairly sequential ways like “command1, command2, command3”. The problems with Tcl start to show up when invariably somebody decides they want something more logically complex than a sequence of commands. Debugging Tcl is extremely difficult, which makes it a huge maintenance liability. For example, a “line number” isn’t much help if the “line” refers to 90% of the file and Tcl thinks all of that is essentially one statement (no matter how many braces are in it). As another example, there are tons of places where a variable is referenced both like "$this" and "this"; that is just a whole series of accidents waiting to happen, especially when you consider that many functions depend on argument order and they don’t necessarily produce obvious malfunctions when variables are misused.

bch 9y ago
> For example, a “line number” isn’t much help if the “line” refers to 90% of the file and Tcl thinks all of that is essentially one statement I think this may have improved since you last looked: $ cat j #!/usr/bin/env tclsh puts [ set a [ expr { 9 + [set x]}]] $./j can't read "x": no such variable while executing "set x" invoked from within "expr { 9 + [set x]}" invoked from within "set a [ expr { 9 + [set x]}]" invoked from within "puts [ set a [ expr { 9 + [set x]}]]" (file "./j" line 3) > there are tons of places where a variable is referenced both like "$this" and "this" $this is essentially [ set this ], returning its value, or deferencing the value, if you will. The entire set of rules that Tcl abides by are contained entirely in a small document (here [0], with commentary). It's really not difficult to figure out. [0] http://wiki.tcl.tk/10259 http://wiki.tcl.tk/10259
- makecheck 9y ago
  That trace is not as bad as I remember but if you write that in a nice long multi-line series of if-statements (say) it’ll still print out the whole mess and only tell you one useless line number. If there’s a "proc" it’s a little better but it can only show the bad line number relative to the "proc", requiring you to do some manual work to find the function within the file and then the offending statement line. Also, I have no problem with the logical "$x" syntax; rather, the fundamental flaw is that the string "x" could be used to change the variable "x" without any clue in the syntax that this may happen (e.g. no "&x" like in C, no "\$x" like in Perl; just "x", or worse "$y" that resolves to "x"). And don’t even get me started on multi-level "upvar". This whole thing is a minefield, especially if people use simple variable names that can’t be searched in a code base. If you’re really unlucky, you accidentally swap the order of parameters and it just so happens that your "$x" value is almost plausible so you never notice the disaster you just created. It’s simply a “write once, modify never” coding style: it saves the programmer 10 seconds and creates the most brittle of code. I would never recommend it to anyone.
- KasianFranks 9y ago
  Why would you set a var to null in a language that expects a string every time you invoke set to null?
sumedh 9y ago
> Debugging Tcl is extremely difficult Used to work on TCl around 10 years back, I dont remember much but I do remember that debugging it was difficult or maybe I was not so smart. When I used Python I quickly loved it because atleast I could debug any issues quickly.

bch 9y ago

> For example, a “line number” isn’t much help if the “line” refers to 90% of the file and Tcl thinks all of that is essentially one statement I think this may have improved since you last looked: $ cat j #!/usr/bin/env tclsh puts [ set a [ expr { 9 + [set x]}]] $./j can't read "x": no such variable while executing "set x" invoked from within "expr { 9 + [set x]}" invoked from within "set a [ expr { 9 + [set x]}]" invoked from within "puts [ set a [ expr { 9 + [set x]}]]" (file "./j" line 3) > there are tons of places where a variable is referenced both like "$this" and "this" $this is essentially [ set this ], returning its value, or deferencing the value, if you will. The entire set of rules that Tcl abides by are contained entirely in a small document (here [0], with commentary). It's really not difficult to figure out. [0] http://wiki.tcl.tk/10259 http://wiki.tcl.tk/10259

makecheck 9y ago
That trace is not as bad as I remember but if you write that in a nice long multi-line series of if-statements (say) it’ll still print out the whole mess and only tell you one useless line number. If there’s a "proc" it’s a little better but it can only show the bad line number relative to the "proc", requiring you to do some manual work to find the function within the file and then the offending statement line. Also, I have no problem with the logical "$x" syntax; rather, the fundamental flaw is that the string "x" could be used to change the variable "x" without any clue in the syntax that this may happen (e.g. no "&x" like in C, no "\$x" like in Perl; just "x", or worse "$y" that resolves to "x"). And don’t even get me started on multi-level "upvar". This whole thing is a minefield, especially if people use simple variable names that can’t be searched in a code base. If you’re really unlucky, you accidentally swap the order of parameters and it just so happens that your "$x" value is almost plausible so you never notice the disaster you just created. It’s simply a “write once, modify never” coding style: it saves the programmer 10 seconds and creates the most brittle of code. I would never recommend it to anyone.
KasianFranks 9y ago
Why would you set a var to null in a language that expects a string every time you invoke set to null?

sumedh 9y ago

> Debugging Tcl is extremely difficult Used to work on TCl around 10 years back, I dont remember much but I do remember that debugging it was difficult or maybe I was not so smart. When I used Python I quickly loved it because atleast I could debug any issues quickly.