2 ms·
I had to use TCL at a company where Prof. Ousterhout was on the board. I had used it a bit at university but I was coming from a Python job so, naturally, I ha
by t43562 2y ago
I had to use TCL at a company where Prof. Ousterhout was on the board. I had used it a bit at university but I was coming from a Python job so, naturally, I hated its syntax BUT:
1. The project was in ancient C++ for many reasons and even the most modern C++ is at least 5x more difficult to write code in than TCL. So why write code that runs once in the life of the program in C++? There's often plenty of code that doesn't benefit from being compiled - that looks for a configuration file, reads and validates lines and calls functions to build initial datastructures...setup code, string handling. You save a millisecond or two by doing it in C++ but only once in a program that runs for hours - why waste all that dev/debug effort?
If you choose judiciously then you can end up doing a lot of your performance insensitive, setup-type code in TCL and a great deal of the time you'll be able to debug and fix bugs in an interpreted language without recompiling anything.
2. Python, though great, has a global interpreter lock. TCL fits in with threaded programs excellently. This can be a make-or-break feature.
3. TCL's syntax which I dislike, seems to map excellently into C - calling C from TCL just seems a lot easier than in python.
- neofytos 2y ago> 2. Python, though great, has a global interpreter lock. TCL fits in with threaded programs excellently. This can be a make-or-break feature. Tcl's threading and event management are indeed standout features. It excels in threaded programs, thanks to its robust C API, especially functions like Tcl_ThreadQueueEvent ( https://www.tcl.tk/man/tcl9.0/TclLib/Notifier.html https://www.tcl.tk/man/tcl9.0/TclLib/Notifier.html ).
- sllabres 2y agoThere is another currently new hacker news thread [1] referencing this post [2] where the influence of the performance of the GIL is evaluated. It seems not so large, of course depending on the tasks performed by the interpreted part. At a former workplace we had a C/C++ application which allowed integration of customer code via TCL which worked well and had acceptable performance even with the TCL code in a hot path of the application code. Inspired from this I once did a C/Perl integration, but the Perl code was minimal (just user exists with special case handling) and Perl is another language disliked by many today. But the program was written around the 2000 and Perl was more widespread without additional installations on the target systems and far better than any ksh/sed/awk combination. But it worked well too. [1] https://news.ycombinator.com/item?id=41006946 https://news.ycombinator.com/item?id=41006946 [2] https://www.maartenbreddels.com/perf/jupyter/python/tracing/gil/2021/01/14/Tracing-the-Python-GIL.html https://www.maartenbreddels.com/perf/jupyter/python/tracing/...