4 ms·

Unpopular opinon: I've used TCL and didn't like it and wouldn't recommend anyone use it. The shell-like "everything is a string" is seductive at first but in p

by kanox 6y ago

Unpopular opinon: I've used TCL and didn't like it and wouldn't recommend anyone use it. The shell-like "everything is a string" is seductive at first but in practice you spend way too much time messing up your quoting. It's similar to how sometimes people suggest dropping yaml/json for a "simple ini file": it quickly breaks down and you end up with a custom ill-defined mechanism for nesting values. TCL can handle more than just string variables: you have arrays, dicts and a bazillion libraries implementing object orientation. The result is that manipulating structured data is still more awkward than in any other modern language, except perhaps shell scripting. Unless you're interfacing with a legacy or third-party system please don't use it. If you think you need expect please just use pexpect.

jeffh 6y ago
I suspect your experience with Tcl is a bit old. Tcl finally standardized on a single core OO library several years ago. The quoting issues can be a pain, but if you learn to treat it like a language rather than extended shell, you learn the tricks to avoid escaping/quoting issues.
- kanox 6y ago
  My experience with TCL is from scripting tools which picked it as an extension language many years ago. Tools like that have their own object-like systems and are likely not going to migrate, ever. Maybe if TCL had a single standard OO library in the late 90s it would have been more successful? But I still think that languages with native OO constructs are much better that a shell-like string-oriented interpreter.
elvis70 6y ago
I think you haven't used it enough to appreciate its true value.
- flubert 6y ago
  >...If, in order to "really" enter a programming culture, I need to both "be solving a significant real problem in the real world" and exercising "the freedom to change the language, the compiler, the OS or even the hardware design", then there are very few options for entering this culture indeed. https://yosefk.com/blog/my-history-with-forth-stack-machines.html https://yosefk.com/blog/my-history-with-forth-stack-machines...
  - lmm 6y ago
    If you trust yosefk's judgement you might want to read his take on TCL: https://yosefk.com/blog/i-cant-believe-im-praising-tcl.html https://yosefk.com/blog/i-cant-believe-im-praising-tcl.html
    - 7thaccount 6y ago
      "lovecraftian toolchain" is one of the greatest phrases I've ever heard and I use it all the time now to describe portions of the tech stack I'm exposed to at work.
cmrdporcupine 6y ago
I'm not sure that's an unpopular opinion? Tcl has declined in use over the years, and while there's a vocal community of people who like it, I never got the impression that Tcl was popular nor that its popularity was increasing.
- dialamac 6y ago
  For a time in the 90s it was very popular. It was often paired with AOLserver for web applications. And it became a glue/scripting language for some heavyweight programs like EDA tools. I mean it was popular enough to somewhat ironically just pull it into the python standard library.
  - pak9rabid 6y ago
    Yep, this is exactly how the company I used to work for used it (tcl/AOLServer) in order to create a web interface for managing paid-for network connections in hotels & what not.
- mschaef 6y ago
  > Tcl has declined in use over the years, and while there's a vocal community of people who like it, To my way of thinking, Tcl is one of the languages that falls into the same category as Lisp, Smalltalk, and Forth. Like those three, Tcl takes a relatively smaller number of concepts compared to most other languages and tries to get more mileage out of combining them together than resorting to adding new conceptual layers. For Tcl, the core concepts strings and string manipulation. Most languages have these things, but very few languages build their list libraries, evaluators, etc. nearly as directly upon them as does Tcl. The net result of this approach is a language that's almost guaranteed to feel strange for the vast majority of developers, who work in languages that tend to be composed of larger numbers of more specialized features. So immediately off-putting to large numbers of potential users. The other property these languages share, once you get past the initial barriers to entry, is a certain sense of enablement and power. The first few times, you realize how control flow structures, etc. are easily implemented in terms of user-visible language constructs, it's at first gratifying and exciting to see and then potentially enabling. After all, it's easier to write a custom expression evaluator in Tcl than, say Java or Python. So the community of opinion around these opinions tend to bifurcate along lines of whether or not the individual in question has spent enough time to truly 'grok' the nature of the language. And note that this can be totally orthogonal to opinions on whether or not the language should actually be used. It's easily possible to not 'get' the nature of Tcl or Lisp and yet have it be the thing you have to write to program your EDA tool or AutoCad. Similarly, it's easily possible to see the power of a language like Tcl and lament either that too few people understand its full power or that it's full power is maybe too flexible to be used in a production setting on a large industrial project. None of that means these languages are not worth pursuing, but I do think this line of thought helps explain how they succeed and fail in the marketplace of ideas. > I never got the impression that Tcl was popular nor that its popularity was increasing. Because it was developed as part of work on EDA tools, it developed a niche there. Also in early web via AOLserver. Where it truly shown, however, was in GUI programming on Unix. Tcl and its GUI library Tk were around X11 before virtually anything other than the original Xt-derived widget libraries. Even more than that, you could open up an interactive 'wish' session and get an active and clickable button on the screen in literally three interactive commands. Compared in ease of use of almost anything other than Visual Basic, Tcl/Tk was light years ahead, and Tcl/TK far surpassed VB in expressivity. (For the reasons I mention above.) Between this and a few other libraries like 'expect', it's hard to overstate exactly how much power Tcl/Tk put in your hands, and relatively easy to use at that. To be honest, there are still large swaths of modern development where we've really regressed in expressive power. (Although HTML/JS does make it pretty easy to get a button on the screen in the simplest case.)
prussian 6y ago
I tend to agree. I am just finishing up a tool I'm using to automate a bunch of interactions I have with the 4 USB UARTs on my desk and I ended up going with expect. If I knew about pexpect I would have probably used that. However, since I did use expect and spent some time learning Tcl, I actually did appreciate one useful thing about it. It's very easy for me to in-line Tcl code into, say, a configuration, parse it with the help of `[info complete]`, attach it to a list and then expand that list `{*}$some_list` as an argument to `expect` or `interact`. I can now have UART specific macros that are bound to keystrokes like Ctrl-t x. Sure I could do something like that in python, but it probably wouldn't be as clear-cut as: # Fix terminal row/col height for less, vi, etc # type Ctrl-t r bind[r] = { # depends on xterm size info, may not be universal send "\{ " send {old=$(stty -g);} send {stty raw -echo min 0 time 5;} send {printf '\033[18t' > /dev/tty;} send {IFS=';t' read -r _ rows cols _ < /dev/tty;} send {stty "$old";} send {stty cols "$cols" rows "$rows";} send {unset old cols rows;} send {shopt -s checkwinsize;} send {clear;} send " \}\r" }
- kanox 6y ago
  If you want to resize the remote terminal it might be easier to determine the size locally with an ioctl and only execute "stty cols/rows" remotely. It might also help to export the local TERM value remotely because it's not otherwise passed through a serial port.
  - prussian 6y ago
    Thanks to you and the other comment under mine, I revised my snippet. I use to just copy/paste it into screen or tio, but now that I have this tool[1] I don't need to. You're absolutely right I could get the terminal size with tools like resize locally and I probably should set TERM to match. [1] the tool if anyone is interested: https://gist.github.com/adedomin/7e615405a2275b01dbae35521161ba87 https://gist.github.com/adedomin/7e615405a2275b01dbae3552116...
- shrubble 6y ago
  In a regular shell, would eval 'resize' Do the same thing?
bsder 6y ago
> The shell-like "everything is a string" Exactly. Tcl is what we should be using for "shell scripts" instead of bash.
sigjuice 6y ago
Unfortunately, pexpect does not do everything. I use this scheme to have keyboard shortcuts for devices on the other of serial ports. spawn -open [open /dev/ttyUSB0 w+] interact { `u {send "uname\n"} `v {send "show-version\n"} `` exit # lots more } I have looked into it a couple of times, but I haven't been able to figure out the pexpect equivalent.
mwfunk 6y ago
That's not just a popular opinion, it might be the general consensus for the last 20+ years. That's why articles about people still using Tcl or even just people liking Tcl have so much novelty value. Tcl created a language niche that Perl/Python/Ruby quickly took over. It was all downhill for Tcl from that point on, for all the reasons you mentioned. It was really cool for a little while though- I have fond memories of using it for a couple years in the mid '90s, but I would never go back to it once I moved on. Also, at the time I remember thinking Tk (Tcl's GUI toolkit) looked mostly modern and nice, maybe even more modern and nice than other GUI toolkits common on Unix systems at the time (Athena widgets, Motif, OpenView, etc.). As ancient and bizarre as it might look nowadays, back then it looked halfway decent if not outright OK. I don't know what Tk looks like now but I have to think it's not that different from 20+ years ago, with the weird autolayout/resizing policies and everything. Tk was a huge draw then but probably not so much now.

by kanox 6y ago

jeffh 6y ago

I suspect your experience with Tcl is a bit old. Tcl finally standardized on a single core OO library several years ago. The quoting issues can be a pain, but if you learn to treat it like a language rather than extended shell, you learn the tricks to avoid escaping/quoting issues.

kanox 6y ago
My experience with TCL is from scripting tools which picked it as an extension language many years ago. Tools like that have their own object-like systems and are likely not going to migrate, ever. Maybe if TCL had a single standard OO library in the late 90s it would have been more successful? But I still think that languages with native OO constructs are much better that a shell-like string-oriented interpreter.

elvis70 6y ago

I think you haven't used it enough to appreciate its true value.

flubert 6y ago
>...If, in order to "really" enter a programming culture, I need to both "be solving a significant real problem in the real world" and exercising "the freedom to change the language, the compiler, the OS or even the hardware design", then there are very few options for entering this culture indeed. https://yosefk.com/blog/my-history-with-forth-stack-machines.html https://yosefk.com/blog/my-history-with-forth-stack-machines...
- lmm 6y ago
  If you trust yosefk's judgement you might want to read his take on TCL: https://yosefk.com/blog/i-cant-believe-im-praising-tcl.html https://yosefk.com/blog/i-cant-believe-im-praising-tcl.html
  - 7thaccount 6y ago
    "lovecraftian toolchain" is one of the greatest phrases I've ever heard and I use it all the time now to describe portions of the tech stack I'm exposed to at work.

cmrdporcupine 6y ago

I'm not sure that's an unpopular opinion? Tcl has declined in use over the years, and while there's a vocal community of people who like it, I never got the impression that Tcl was popular nor that its popularity was increasing.

dialamac 6y ago
For a time in the 90s it was very popular. It was often paired with AOLserver for web applications. And it became a glue/scripting language for some heavyweight programs like EDA tools. I mean it was popular enough to somewhat ironically just pull it into the python standard library.
- pak9rabid 6y ago
  Yep, this is exactly how the company I used to work for used it (tcl/AOLServer) in order to create a web interface for managing paid-for network connections in hotels & what not.
mschaef 6y ago
> Tcl has declined in use over the years, and while there's a vocal community of people who like it, To my way of thinking, Tcl is one of the languages that falls into the same category as Lisp, Smalltalk, and Forth. Like those three, Tcl takes a relatively smaller number of concepts compared to most other languages and tries to get more mileage out of combining them together than resorting to adding new conceptual layers. For Tcl, the core concepts strings and string manipulation. Most languages have these things, but very few languages build their list libraries, evaluators, etc. nearly as directly upon them as does Tcl. The net result of this approach is a language that's almost guaranteed to feel strange for the vast majority of developers, who work in languages that tend to be composed of larger numbers of more specialized features. So immediately off-putting to large numbers of potential users. The other property these languages share, once you get past the initial barriers to entry, is a certain sense of enablement and power. The first few times, you realize how control flow structures, etc. are easily implemented in terms of user-visible language constructs, it's at first gratifying and exciting to see and then potentially enabling. After all, it's easier to write a custom expression evaluator in Tcl than, say Java or Python. So the community of opinion around these opinions tend to bifurcate along lines of whether or not the individual in question has spent enough time to truly 'grok' the nature of the language. And note that this can be totally orthogonal to opinions on whether or not the language should actually be used. It's easily possible to not 'get' the nature of Tcl or Lisp and yet have it be the thing you have to write to program your EDA tool or AutoCad. Similarly, it's easily possible to see the power of a language like Tcl and lament either that too few people understand its full power or that it's full power is maybe too flexible to be used in a production setting on a large industrial project. None of that means these languages are not worth pursuing, but I do think this line of thought helps explain how they succeed and fail in the marketplace of ideas. > I never got the impression that Tcl was popular nor that its popularity was increasing. Because it was developed as part of work on EDA tools, it developed a niche there. Also in early web via AOLserver. Where it truly shown, however, was in GUI programming on Unix. Tcl and its GUI library Tk were around X11 before virtually anything other than the original Xt-derived widget libraries. Even more than that, you could open up an interactive 'wish' session and get an active and clickable button on the screen in literally three interactive commands. Compared in ease of use of almost anything other than Visual Basic, Tcl/Tk was light years ahead, and Tcl/TK far surpassed VB in expressivity. (For the reasons I mention above.) Between this and a few other libraries like 'expect', it's hard to overstate exactly how much power Tcl/Tk put in your hands, and relatively easy to use at that. To be honest, there are still large swaths of modern development where we've really regressed in expressive power. (Although HTML/JS does make it pretty easy to get a button on the screen in the simplest case.)

prussian 6y ago

I tend to agree. I am just finishing up a tool I'm using to automate a bunch of interactions I have with the 4 USB UARTs on my desk and I ended up going with expect. If I knew about pexpect I would have probably used that. However, since I did use expect and spent some time learning Tcl, I actually did appreciate one useful thing about it. It's very easy for me to in-line Tcl code into, say, a configuration, parse it with the help of `[info complete]`, attach it to a list and then expand that list `{*}$some_list` as an argument to `expect` or `interact`. I can now have UART specific macros that are bound to keystrokes like Ctrl-t x. Sure I could do something like that in python, but it probably wouldn't be as clear-cut as: # Fix terminal row/col height for less, vi, etc # type Ctrl-t r bind[r] = { # depends on xterm size info, may not be universal send "\{ " send {old=$(stty -g);} send {stty raw -echo min 0 time 5;} send {printf '\033[18t' > /dev/tty;} send {IFS=';t' read -r _ rows cols _ < /dev/tty;} send {stty "$old";} send {stty cols "$cols" rows "$rows";} send {unset old cols rows;} send {shopt -s checkwinsize;} send {clear;} send " \}\r" }

kanox 6y ago
If you want to resize the remote terminal it might be easier to determine the size locally with an ioctl and only execute "stty cols/rows" remotely. It might also help to export the local TERM value remotely because it's not otherwise passed through a serial port.
- prussian 6y ago
  Thanks to you and the other comment under mine, I revised my snippet. I use to just copy/paste it into screen or tio, but now that I have this tool[1] I don't need to. You're absolutely right I could get the terminal size with tools like resize locally and I probably should set TERM to match. [1] the tool if anyone is interested: https://gist.github.com/adedomin/7e615405a2275b01dbae35521161ba87 https://gist.github.com/adedomin/7e615405a2275b01dbae3552116...
shrubble 6y ago
In a regular shell, would eval 'resize' Do the same thing?

bsder 6y ago

> The shell-like "everything is a string" Exactly. Tcl is what we should be using for "shell scripts" instead of bash.

sigjuice 6y ago

Unfortunately, pexpect does not do everything. I use this scheme to have keyboard shortcuts for devices on the other of serial ports. spawn -open [open /dev/ttyUSB0 w+] interact { `u {send "uname\n"} `v {send "show-version\n"} `` exit # lots more } I have looked into it a couple of times, but I haven't been able to figure out the pexpect equivalent.

mwfunk 6y ago

That's not just a popular opinion, it might be the general consensus for the last 20+ years. That's why articles about people still using Tcl or even just people liking Tcl have so much novelty value. Tcl created a language niche that Perl/Python/Ruby quickly took over. It was all downhill for Tcl from that point on, for all the reasons you mentioned. It was really cool for a little while though- I have fond memories of using it for a couple years in the mid '90s, but I would never go back to it once I moved on. Also, at the time I remember thinking Tk (Tcl's GUI toolkit) looked mostly modern and nice, maybe even more modern and nice than other GUI toolkits common on Unix systems at the time (Athena widgets, Motif, OpenView, etc.). As ancient and bizarre as it might look nowadays, back then it looked halfway decent if not outright OK. I don't know what Tk looks like now but I have to think it's not that different from 20+ years ago, with the weird autolayout/resizing policies and everything. Tk was a huge draw then but probably not so much now.