Really enjoy the language, even if I don't use it much these days. Does it still produce GUIs from 1995 on Linux? I'd still be using it today if it had halfway reasonable support for building GUIs on Linux, like they've had for ages on other platforms.
Tcl 9.0
81–90 of 247 posts
Re: Tcl 9.0
#82It’s not exactly encouraging when a website for a UI tool contains absolutely no visual examples of UI on any of its main pages.
Re: Tcl 9.0
#83Earlier quoted context omitted.
It's the scripting language of the EDA industry. If you're designing computer chips, you're using TCL. Cadence and Synopsys standardized on TCL 30+ years ago. It's strength is that you get to operate EDA tools as if they were shell script commands, like run_my_task -option_a -option_B If you aren't designing computer chips, you have no reason to use it. It's a horrible language. The sooner the EDA industry can get ri…
I'm curious why you feel this way. A long time ago as a college student I used Tcl in an EDA internship. It was awful for reasons completely unrelated to Tcl. There was a library of tool-specific primitives. The primitives were badly documented, badly tested, and nobody actually understood how any of it worked except cargo-culting and copy-pasting each others' scripts. Code only worked on the happy path and there was…
It's basically like shell scripts, and really only useful for running shell-like commands. You don't want to do anything complicated with it, such as any direct data processing. I mean, you can, but your code is not going to be readable. As a Cadence Applications Engineer, I had to decode so many customer TCL scripts, some tens of thousands of lines, to figure out what they were trying to do. It's not fun.
As a language, Python is the correct answer.
And now, Python just has so much more widespread support. You can get any library you want in Python, with its millions of packages available. Want to do some AI processing on your schematics while printing out a graph? There are all sorts of libraries for that. You can't get that in TCL.
Re: Tcl 9.0
#84Earlier quoted context omitted.
It's the scripting language of the EDA industry. If you're designing computer chips, you're using TCL. Cadence and Synopsys standardized on TCL 30+ years ago. It's strength is that you get to operate EDA tools as if they were shell script commands, like run_my_task -option_a -option_B If you aren't designing computer chips, you have no reason to use it. It's a horrible language. The sooner the EDA industry can get ri…
> If you aren't designing computer chips, you have no reason to use it. It's a horrible language. What an unfair statement to make; by no means is it an horrible language. Just because it doesn't fit your tastes doesn't make it "horrible". That's like me saying having to start a line of Python with three spaces is annoying design which makes it an horrible language. Take your statement elsewhere.
30 years of TCL here. It really is the worst.
I immediately moved my scripts to Python 1.0 when Python arrived on the scene because TCL (and PERL) were so horrible.
Re: Tcl 9.0
#85Earlier quoted context omitted.
One example from the document: > Consider the naive attempt to clean out the /tmp directory. > cd /tmp > foreach f [glob *] {file delete -force $f} > A file ~ or ~user maliciously placed in /tmp will have rather unfortunate consequences.
i once managed to create a directory named ~ using the mirror tool written in perl. then i naively tried to remove it using "rm -r ~" and started wondering why removing an empty directory would take so long, until it dawned on me... i learned a few new habits since then. i almost never use rm -r and i avoid "*" as a glob by itself. instead i always try to qualify "*" with a path, remove files first: "rm dir/*"; and t…
I love zsh auto completion for this stuff. It automatically escapes really messed up paths like paths with new lines or emojis and crazy characters like that. Its really rare but I still intentionally practiced removing these things just so I can do it safely if it ever happens.
Re: Tcl 9.0
#86Earlier quoted context omitted.
Tcl is widely used in EDA automation in general - it's not just an Intel thing. Xilinx, Synopsys, Cadence, and Mentor all use Tcl extensively, for example.
Super interesting, what's the rationale behind its use there?
John Ousterhout realized that every single EDA tool at Berkeley wound up implementing a crappy extension language. So, he implemented a language so that there could be a single, not-so-crappy extension language for the Berkeley EDA tools. He made C integration particularly easy (something the lisps of the time didn't really do). As his students spread out, each company they hit had a shitty extension language and they lobbied to get it replaced with Tcl and thus Tcl spread.
The issue with languages is that memory, CPU, and disk in the early 1990s are still fairly expensive. You need a language that is small yet still complete. Even today, the only languages that really fit that bill are Scheme/Lisp, Tcl, and Forth.
The memory limitations releasing are why you see the "stringly-typed" scripting languages like Tcl, Perl, etc. from the late 1980s transition to "dynamically typed" languages in the 1990s like Python, VB, later Ruby, Javascript, etc.
Tk popped up because GUI development at the time was utter shit (web doesn't exist, VB6 doesn't exist, etc.). It is really hard to describe just how much better Tk was than anything else in the time frame.
Re: Tcl 9.0
#87It’s not exactly encouraging when a website for a UI tool contains absolutely no visual examples of UI on any of its main pages.
There is a redesign of the website in progress. In the meantime, take a look at https://wiki.tcl-lang.org/page/Showcase .
Re: Tcl 9.0
#88Earlier quoted context omitted.
I should also note that Richard Hipp, the creator of SQLite, says that SQLite is coded in Tcl. The database engine itself is coded in C, of course; but the vastly larger test suite is mostly coded in Tcl; and it's the test suite that makes SQLite the reliable engine that it is. The test suite persists; the engine's been re-written in whole and in part.
Indeed, SQLite started life as simply a Tcl extension[0] that “escaped into the wild”. Redis was initially prototyped in Tcl too, and ‘antirez has nice things[1] to say about Tcl. [0] https://sqlite.org/tclsqlite.html [1] http://antirez.com/articoli/tclmisunderstood.html
I'm curious about why they chose Tcl, particularly over languages like Python or Perl. Were there specific aspects of Tcl that made it appealing for SQLite and Redis, or was the choice more about familiarity with Tcl? Either way, I'd love to understand what they found interesting or advantageous about Tcl in these projects. BTW, I chose Tcl/Tk in the past because it was the easier way I found to quickly built an UI on Unix/Linux.
Re: Tcl 9.0
#89Earlier quoted context omitted.
It's unfortunate that people who dont "get" Tcl feel forced to use it because they are in EDA. I used to have the opposite problem. My employer would not allow me to write anything mission-critical in Tcl because they thought other people would not be able to maintain it. But now that I'm retired I can write as much Tcl as I like, which is quite a lot :-)
From the (little) I've seen of that world, I'm not sure the EDA vendors understand Tcl very well either; I wouldn't want to work with scripts for Cadence's schematic capture tool, and that's not because of Tcl, it's because their scripting interface is a disaster. (Exposing C++ iterators at the script level, for example.)
Ironically the schematic capture scripts were likely written in SKILL (LISP-like language) and not TCL.
SKILL is much better than TCL for data processing. TCL's strength is in command control flow.
Re: Tcl 9.0
#90The only time I’ve dealt with Tcl in recent memory was for some MacPorts portfile stuff. Anybody using it for something else and can speak to why you’d use it today? Genuinely curious; I don’t hate the language but can never bring myself to enjoy it either.
Copy-pasting a "hype" checklist I made some eons ago:
* Extremely consistent and elegant syntax - whole syntax/grammar is described in 12 rules in a single man page (Tcl(n)) of 150 lines and there's no reserved keyword. Nearer to CL than Python on that point.
* Homoiconic through strings (like almost every language with eval) but most importantly, through "list-like" strings.
* Official man pages! No web-only and spec-like doc like cppreference nor lackluster "minimalist" stuff like pydoc (compare `pydoc print` with `man n puts`, for example).
* One of the simplest if not the simplest interaction with C, letting you write C plugins very easily (with critcl and swig to help).
* Not slow, not fast. In the same ballpark as cpython or Perl; doesn't need a tracing garbage collector, refcounting does the job since no cycles are possible by design (worse for throughput, but lighter runtime).
* Fun type system that is superficially "everything is a string" (like sh) but in reality "everything is a tagged union with on-the-fly conversion when needed and a guaranteed string representation". Allows for transparent serialization (`puts $mydict stdout` `set mydict [read stdin]`), like CL's read/write.
* Powerful introspection through `info` (mainly). Allows for stuff like getting the name/body/arglist of a procedure, get all the registered procedures, know if a variable exists, get information on the stack frames and their content, etc... Together with `trace`, you can even write an internal debugger in few lines.
* Procedure arguments are passed by pointer with a copy-on-write system: don't modify the argument and you don't get any memory copy. To you, it just looks like regular passing by value.
* Modifying the procedure arguments is done via `upvar`: in Tcl, a variable reference is just a name (string) attached to a relative stack frame number, quite elegant considering the language's core concepts.
* If you use at least the builtin extensions (thread, http, tdbc, tcltest, msgcat) and the very basic tcllib/tclX/tclUdp/tklib packages, you're almost set for life. Personally, I also recomment the very convenient tclreadline, tdom, pipethread, tablelist and tclcurl.
* Channels is one of the cleanest I/O implementation I've ever used with some cool features:
- Transformations allowing filters like deflate/zlib/gzip or TLS to be put on a channel (see `transchan` for the API).
- Reflected aka virtual channels, to make your own channels. Basically like glibc/BSD's unportable fopencookie/funopen or CL's gray streams.
- Centralize a lot of ioctl/fcntl mess and even more (like defining the EOF char) in `chan blocked/configure/pending`.
- Integration with the event loop via `chan event/postevent` allows for a nice callback oriented approach to sockets and pipes.
- Other third-party channel types include pty (expect), random, memory or fifo (memchan).
* Builtin event loop (see `after`, `vwait`, `socket -server` and `chan event`) for powerful and seamless concurrency/command scheduling. Much simpler than Python's very "AbstractBeanFactory" asyncio.
* An elegant thread extension consisting of an interpreter per thread and no raw access to other thread's memory. Comes with both simple (`thread::send/broadcast/transfer`) and performant (`tsv`) synchronization/communication facilities.
* Finally a sane, light and portable (even more with Tile) GUI toolkit: Tk.
* One of the fastest Unicode aware regex implementations, written by Henry Spencer himself. Has its own greater-than-POSIX-ERE syntax called ARE, not as complete as PCRE (lacking lookbehind constraints, most importantly), but still great for an hybrid NFA/DFA engine. Performance comparison with Perl: https://github.com/mariomka/regex-benchmark/pull/44.
* `uplevel` (eval a script in a different stack frame) and `tailcall` (replace the current procedure with another command) let you augment the language by implementing control structures and keywords yourself. Inferior to CL's synergy between unhygienic macros, "naked AST" style homoiconicity, symbols as first-class objects, gensym and quasi-quoting, but still quite powerful.
* Safe interpreters let you do very fun things like config files in Tcl with limited access to the machine and master interpreter.
* Recent versions (>= 8.5) really embraced FP with:
- Real lambdas (but not closures, these have to be emulated) through apply.
- Purer hash maps (dict) than ugly sticking-out-like-a-sore-thumb arrays.
- Lisp style prefix arithmetic (allowing for `* 3 [+ 1 2]` instead of `expr {3 * (1 + 2)}`) including sane behaviour for more than two (reduce) or zero (neutral element) arguments.
- Builtin map/filter (lmap) with 8.6. See https://wiki.tcl-lang.org/page/Functional+Programming for more.
* Multiple more-or-less powerful OO systems (now based on the builtin TclOO): [incr Tcl] for C++ style OO, XoTcl for a take on CLOS or Snit for something Tk oriented.
* Some massive issues on the top of my head: lacking a LSP/SLIME equivalent, the warts of the weird type system (no way to differentiate between atoms and single element lists or evenly sized lists and dicts), missing metaprogramming facilities like quasi-quoting, no official support for UDP and UNIX domain sockets, no GC for class instances (cf https://core.tcl-lang.org/tips/doc/trunk/tip/550.md), no FFI in core, subtly broken exec (cf https://core.tcl-lang.org/tips/doc/trunk/tip/424.md and https://core.tcl-lang.org/tips/doc/trunk/tip/259.md)
Here are some project I made with it, still worth using compared to CL which is my true love, simply because its stdlib is better suited for a lot of tasks:
https://git.sr.ht/~q3cpma/mangadex-tools
https://git.sr.ht/~q3cpma/rymscrap
https://git.sr.ht/~q3cpma/lemonbar-tcl
https://git.sr.ht/~q3cpma/tcl-misc