The recent posting about "Lua, the Misunderstood Language" here (https://news.ycombinator.com/item?id=33022031) brought up memories of another "misunderstood" language, namely Tcl and it's useful graphical add-on Tk.
My memories of using Tcl are that the language was shockingly simple (every line is a command, everything is a string), but as long as your goal was also simple, you could bang things out and be happy. As a C programmer, writing the extension glue code was tedious but straightforward (this as way pre-SWIG), and then the ability to whip up some kind of GUI (blissfully absent any UI design concerns, as noted in the article) for that C code was exhilarating.
But then what. As soon as the program got a little more complicated you were wishing the language was a little more powerful, but it never made sense to rewrite logic or functionality and push it back down into C, so that the Tcl/Tk layer on top could be paper-thin like at the fun start. I remember eval commands becoming more common, and then the legibility/reasonability went to hell. The article mentions that it didn't have a package distribution system until too late, and I don't think I missed that; for me the problem was that the incremental creation of any non-trivial Tcl program led to something that somehow stubbornly resisted being re-organized into manageable pieces. For some reason I didn't fall into these situations with Python.
Everything in the article rings true, but for me the basic problem was that it was too easy to do really simple things, and then you were trapped.
My experience was similar. There where some nifty tools like Expect, but for more complicated tasks I preferred Perl, which had a package system and one of the packages was Perl::Tk so I could build graphical interfaces too, if Curses wasn't sufficient.
5 comments
[ 2.1 ms ] story [ 19.2 ms ] threadBut then what. As soon as the program got a little more complicated you were wishing the language was a little more powerful, but it never made sense to rewrite logic or functionality and push it back down into C, so that the Tcl/Tk layer on top could be paper-thin like at the fun start. I remember eval commands becoming more common, and then the legibility/reasonability went to hell. The article mentions that it didn't have a package distribution system until too late, and I don't think I missed that; for me the problem was that the incremental creation of any non-trivial Tcl program led to something that somehow stubbornly resisted being re-organized into manageable pieces. For some reason I didn't fall into these situations with Python.
Everything in the article rings true, but for me the basic problem was that it was too easy to do really simple things, and then you were trapped.