But isn't the whole point of Tcl to be a lightweight embedded scripting language?
No doubt it's not going to be dethroned in any way from the numerous industry tools (most CAD systems support it for example) but if you want to embed a scripting language, is there any reason to use Tcl over Lua these days?
Tcl was never lightweight. If you know how it works internally, you know that it consumes more memory and more processing time than most other scripting languages.
As an example, a few years back some coworkers and I were interviewing a candidate and he used a lookup take to avoid having to constantly calculate sin and cos. We wrote some tests to discover what the performance improvement was and found out there was none. It was slower to read a value out of an array than it was to calculate the sin or cos of a value.
Tcl might have been a good option back in the day, but they just don't keep up with everyone else, both in terms of performance and feature set.
Thats simply not true. Tcl was pretty heavy in the 90s, but its always been comparable to Perl, and slightly better than python. I would be EXTREMELY curious to see what TCL version you were running, and for what values of sin/cos.
EDIT: Here is a benchmark that shows TCL/Lua both in a good light for hash table lookups.
http://playcontrol.net/opensource/LuaHashMap/benchmarks.html
Perhaps it's a matter of "too little too late" to have a significant effect on Tcl's adoption rate, but in versions 8.5[1] and 8.6[2], Tcl gained a number of language-level features that, as a language, seem to put in on the same level as ES6 and other modern scripting languages. Highlights include lambdas, coroutines and stackless evaluation.
For what domain? In games, Lua was always dominant, and in the browser space JavaScript is about as entrenched as it can be...
On the other hand, there are enough applications in enterprise and manufacturing where Tcl/Tk applications run happily along and there's no good reason to replace them. Your nuclear power plant might have a neat little charts GUI done with Tk's canvas and Tcl scripts to tie all kinds of sensors and gauges together. Your automotive supplier might still do CAD/CAM file conversion/distribution/deployment with a Tcl server.
For new applications, it's probably a hard sell these days. Don't get me wrong, I personally think it's a great little system, especially when you're in an 'ivory tower' situation where you control the whole setup and don't need a lot of interop middleware and libraries. It's easy to create simple GUIs for all kinds of tasks and I've rarely seen systems that make it easier to leverage 'non-programmers', i.e. get some user scripting done.
For ugly, dirty hack jobs like web programming, I'd rather go with something more standard or -- if I feel inclined to reinvent the wheel -- with something more powerful and/or rigid (whether that's CL, Haskell or Ada...).
Although weirdly enough, web client programming is certainly something that checks both the 'ivory tower' and 'non-programmer' boxes...
I think it's still superior for equipping tools with a REPL. Say you're making something that has smart users who won't freak out about typing commands and editing a complicated config file to achieve advanced results, then it makes great sense.
Tk seems pretty pointless now. Wx obviates it, in my opinion.
Apart from maybe Shoes, I've yet to see something that approaches Tk's whipupitude, which is a great benefit for adding some small dialog or report window to a script. And its Canvas was great for data visualisation. It was hard to get something really good-looking out of it, but if you want to draw a picture of the machines in your manufacturing plant with a item count and on/off switch next to each...
Dunno about Wx. Last time I looked at it, it was a horrible morass of classes and constants that actually made me long for Swing...
I think tcl/tk was the very first scripting language for the web. In 1992, with the release of tkWWW, it was possible to use tcl/tk to script HTML pages. [1]
> The Tk browser has the following advantages.
> 2. More important, it is possible to imbed Tk code into hypertext documents. To see an example of this, load in the hypertext file file:$pwd/Tcl/text2.html
18 comments
[ 5.5 ms ] story [ 45.0 ms ] threadSo the momentum is about the same and therefore both are relevant.
No doubt it's not going to be dethroned in any way from the numerous industry tools (most CAD systems support it for example) but if you want to embed a scripting language, is there any reason to use Tcl over Lua these days?
As an example, a few years back some coworkers and I were interviewing a candidate and he used a lookup take to avoid having to constantly calculate sin and cos. We wrote some tests to discover what the performance improvement was and found out there was none. It was slower to read a value out of an array than it was to calculate the sin or cos of a value.
Tcl might have been a good option back in the day, but they just don't keep up with everyone else, both in terms of performance and feature set.
Have you even looked at it recently? Just curious.
http://www.nist.gov/el/msid/expect.cfm
Exploring Expect by Don Libes, the principal author of Expect, is a classic among tech books:
http://shop.oreilly.com/product/9781565920903.do
[1] http://www.tcl.tk/software/tcltk/8.5.html
[2] http://www.tcl.tk/software/tcltk/8.6.html
On the other hand, there are enough applications in enterprise and manufacturing where Tcl/Tk applications run happily along and there's no good reason to replace them. Your nuclear power plant might have a neat little charts GUI done with Tk's canvas and Tcl scripts to tie all kinds of sensors and gauges together. Your automotive supplier might still do CAD/CAM file conversion/distribution/deployment with a Tcl server.
For new applications, it's probably a hard sell these days. Don't get me wrong, I personally think it's a great little system, especially when you're in an 'ivory tower' situation where you control the whole setup and don't need a lot of interop middleware and libraries. It's easy to create simple GUIs for all kinds of tasks and I've rarely seen systems that make it easier to leverage 'non-programmers', i.e. get some user scripting done.
For ugly, dirty hack jobs like web programming, I'd rather go with something more standard or -- if I feel inclined to reinvent the wheel -- with something more powerful and/or rigid (whether that's CL, Haskell or Ada...).
Although weirdly enough, web client programming is certainly something that checks both the 'ivory tower' and 'non-programmer' boxes...
Tk seems pretty pointless now. Wx obviates it, in my opinion.
Dunno about Wx. Last time I looked at it, it was a horrible morass of classes and constants that actually made me long for Swing...
> The Tk browser has the following advantages.
> 2. More important, it is possible to imbed Tk code into hypertext documents. To see an example of this, load in the hypertext file file:$pwd/Tcl/text2.html
[1] http://lists.w3.org/Archives/Public/www-talk/1992JulAug/0034...