4 ms·
Arguments against Tcl like: https://vanderburg.org/old_pages/Tcl/war/0000.html https://vanderburg.org/old_pages/Tcl/war/0000.html aside, I found Tcl/Tk along
by blue-dragonfly 6y ago
Arguments against Tcl like:
https://vanderburg.org/old_pages/Tcl/war/0000.html https://vanderburg.org/old_pages/Tcl/war/0000.html
aside, I found Tcl/Tk along with with the extension Expect:
https://en.wikipedia.org/wiki/Expect https://en.wikipedia.org/wiki/Expect
to be a powerful way to do automation. In the '90s, I automated a process of migrating data from a mainframe to Unix workstations using a Tk GUI run by end users which generated Tcl/Expect scripts to download, convert, and verify massive amount of files in a batch.
- rufugee 6y agoHeck....I just used Tcl/Expect to automate 1000s of transactions in one of our legacy systems. I tried a number of expect implementations (python, go, java), but found them all lacking or overly complicated compared to the original Expect. If you need to automate old terminal apps, you really can't do any better at the moment.
- kevin_thibedeau 6y agoMost of those arguments are out of date. Tcl has evolved significantly since 94. It's never going to win on raw performance, but for its intended use cases, interpreter performance doesn't have to be best in class.
- blue-dragonfly 6y agoI haven't written any Tcl/Tk/Expect recently. It is interesting to know they are still being used, thanks for the updates. Expect was also quite useful for testing command-line applications. Even back then, RMS's arguments may or may not have applied to what he was doing, but our department got a lot of use out of Tcl for our sys admin work. We had many new-hires at the time, some without much CS background, and we found they could acquire and become productive in Tcl quickly, which was important in meeting our schedule.
- deleted 6y ago[deleted]