Tcl's C API is very nice, and makes it easy to either integrate Tcl into a larger C app, or write bits and pieces of C as Tcl commands.
I helped work on the 2nd edition of this book, which I think is still fairly relevant: https://amzn.to/2IB9OyR
I helped work on the 2nd edition of this book, which I think is still fairly relevant: https://amzn.to/2IB9OyR
More often then not, the problems I was involved with resolving on emergency escalation (line down) calls was on the SAP side of the world and never in the integration code in TCL and C.
The biggest drawback with the TCL implementation from our application vendor was that they did not implement multi threading for TCL and instead implemented a node.js like event loop. As SAP calls were locking, this did cause locks for all other TCL calls.
Who’s event-loop is like who’s? ;)
It is probably one of the best languages to extend. Sadly it is also one of the slowest.
Early Tcl was slow - but it was being compared to pure C. Recent Tcl is as snappy as any HLL.
In terms of pure runtime performance (CPU efficiency I guess), do you know of any reasonable benchmarks comparing TCL to say, Python and Ruby? I wonder if they might all be in the same ballpark?
It was a great experience and we had quite a few in-house tooling that I only saw years later in Rails.
Those issues lead us to become early .NET adopters as Microsoft was searching partners for getting their products ready to ship when .NET 1.0 would be announced to the world.
Since then I only use scripting languages for shell scripting.
Hm.
In fact, the .NET re-rewrite was quite successful and many of the people involved on that team went on to create a very successful product based on the field lessons we had with the Tcl version.
And in the end we gave up for .NET.