5 ms·
TCL never got the love it deserves.
by spdegabrielle 5y ago
TCL never got the love it deserves.
- deleted 5y ago[deleted]
- Jtsummers 5y agoAt least outside the electronics and embedded software development space. It's all over this area.
- mleo 5y agoI spent 4 years back around 2000 developing on a CMS that used TCL as the underlying language. It was mostly a hate/hate relationship. More for the CMS than TCL itself, but that can be said about any CMS.
- jgrahamc 5y agoVignette?
- jeffmc 5y agoI worked for a startup in the late 1990s that had a reseller agreement with Vignette. If I recall Vignette was going for something like a million dollars a site license. I took one look at it and ended up rolling our own TCL-based CMS in case the Vignette deal went south. Well I left, Vignette went south and the company ended up using my CMS.
- guenthert 5y agoThe TCL interpreter, unlike other scripting languages, doesn't perform any checks at the start of a program. That is, even silly syntax errors are found not before that very line is reached. If that happens to be in a lesser trodden error path, you might find it only at a very inconvenient time. I learned to hate TCL with a passion.
- hulitu 5y agoWhat checks shall it perform ? It's an interpreter.
- tails4e 5y agoI use TCL as I use EDA SW a lot, but I found the most horrible feature of TCLs language design, comments are not comments. A comment is a command to ignore the line. However a comment with a curly brace in it can break control flow, as its partially interpreted. I found this by commenting out some code (that was malformed) and my tcl program failed to run. I ended up commenting out the entire program save one line and still I got errors. Then I realised to my horror the comments with braces were actually affecting control flow! That said, in EDA in general it works well for the most part.
- _blz2 5y agoI use it daily at work. (EDA space)
- bsder 5y agoTcl (like Perl) shot itself in the foot right as the DotCom/DotBomb went off. Python was effectively completely stable through all this and gained a critical mass following.
- bch 5y ago> Tcl (like Perl) shot itself in the foot right as the DotCom/DotBomb went off. I don’t know what you mean “shot itself in the foot“ here. Some examples? > Python was effectively completely stable through all this and gained a critical mass following. I don’t know how much more “effectively stable” Python was than Tcl. Can you expand on this? I personally see this largely as “luck of the draw”. It seems to me there’s a lot to complain about with Python - the low-fruit classic is the GIL. Despite that huge impediment, it came to be a scientific computing go-to language. Who would have guessed that? We can see things now and say “popular languages are popular”, and that’s about it.
- bsder 5y agoPerl and Tcl carved themselves into incompatible versions (Perl 6 and Tcl 8) at a critical moment. Python, on the other hand, felt like it was at version 1.5.2 absolutely forever. > It seems to me there’s a lot to complain about with Python - the low-fruit classic is the GIL. Except that, in the late-1990s/early-2000s, it didn't matter. Scripting languages were slow relative to compiled languages. Multiple-threads effectively didn't exist. Hyperthreading didn't hit until 2003--after the DotBomb. > Despite that huge impediment, it came to be a scientific computing go-to language. Who would have guessed that? Gee, who could have guessed that a whole lot of scientists and engineers kinda liked Matlab the program but hated Mathworks the company and that providing somewhere for them to jump ship to would be popular? Like ... absolutely everybody? Of course, just the idea isn't enough. The alternative has to be sufficiently capable. Thus ... Enthought. Enthought personnel put in a lot of elbow grease and work to make Python a scientific computing go-to language. As always, the best way to predict the future is to make it.
- bch 5y agoI wasn’t actually maintaining software across this divide, but I do still occasionally see Tcl 7.x installations in the wild and find it quite recognizable. It seemed to me the biggest changes from 7->8 were byte code interpreter and “dual ported” Tcl_Obj to store values vs naive C strings(which should have only exposed themselves as “improved performance”). The release notes[0] for Tcl 8 seem to list minor-ish annoyances, but perhaps you did have to support something across the 7-8 divide; I won’t argue against your experience in that case. > As always, the best way to predict the future is to make it Truth. [0] https://www.tcl.tk/software/tcltk/8.0.html#incompatibilities https://www.tcl.tk/software/tcltk/8.0.html#incompatibilities