The first major release in 27 years. 64-bit internal structures, so data can be huge. Full unicode with all the funky new emojis. Zip filesystems, etc., etc.
There's lots of new stuff, and some old cruft has been dumped, so some programs may need a few updates, but there's still a high level of compatibility. The page above links to release notes with details of what's in and what's out.
The Zip filesystem stuff is wonderful change to see: it takes a number of techniques that were common in the community (if you had the right tools and knew how to use them) for building standalone applications, and makes them part of the basic toolkit in a standard way. It's a truly excellent change, and I'm glad to see it.
It may be easier to reason about when thinking of the way $(mount -o loop) works with .iso files -- a file that is a container for other files that one can mount as if it were a filesystem
I was expecting pathlib in Python <https://docs.python.org/3/library/pathlib.html> to have one since a lot of Python distributions ship the standard library in .zip files but evidently not. Python gonna Python in that way
Firefox actually used to ship with that same "jar:" protocol handler, too, and I made good use of it for reading the javadoc html which was shipped inside zip files and was indescribably easier than trying to manage all the .html files in a Java 8 SDK distribution. They made heavy use of this because a lot of their internals were in .xpi formats (which is also a .zip file) but they recently dropped it because Firefox gonna Firefox^W double down on some random shit other than making a sane browser
The definition of "standalone application" is a bit stronger - what's always been possible with "Tclkits" has been to embed the application code in an interpreter binary and distribute that, and the new core zipfs supports that as well.
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 then remove the empty directory. "rmdir dir/"
if i do want to use rm -r, it is with a long path. eg in order remove stuff in the current directory i may distinctly add a path: rm -r ../currentdir/*" instead of "rm -r *"
related, i also usually run "rm -i", but most importantly, i disable any alias that makes "rm -i" the default, because in order to override the -i you need to use -f, but "rm -i -f" i NOT the same thing as "rm". rm has three levels of safety: "rm -i; rm; rm -f". if "rm -i" is the default the "rm" level gets disabled, because "rm -i -f" is the same as "rm -f"
Change your do block to `printf %q\ rm -f "$i" ; echo` and it won't lie about spaces. In case HN has "trimmed" my post in some way, as it often does, that's: percent q backslash space space. Works in bash/zsh, but not dash, probably not whatever your sh is. Can make a function of it trivially, but you have to handle the $# -eq 0 case, return whatever printf returns, etc.
When deleting, if it is more than a few specifically named files I will use a "find ... -delete" invocation.
I like it for two reasons. Find feels like it has more solidly defined patterns and recursion than shell globing and by leaving off the "-delete" it give me a chance to inspect the results before committing to my actions.
Very cool of you to post this. Too many people won't post stories like this, but I've done very similar multiple times. I think it definitely helps reinforce proper habits, and is the best way to cut your teeth on technology. It's also great for anyone new to read something like this, and be able to avoid something so devastating, and maybe make lesser mistakes, but still learn from both!
when you get to be as old as i am, these are the war stories you share with your kids and grandkids around the campfire ;-)
like the one from my colleague who once fat fingered fsck into mkfs and i lost my personal homepage because of it. what makes me uncomfortable about that story is that it was not my fault. if it were it would have been easier to tell. but at the time i was quite frustrated and my colleague felt that despite me trying to not get angry at him. i still feel really bad about my reaction then, adding to his predicament, since he had to live with the guilt about losing our website and everyone's personal home directory. it's bad when a mistake causes you to loose something personal, but so much worse when you loose someone elses stuff.
talking about mistakes is how we learn from them. the important part is not to get embarrassed about them. however that requires an environment where we are not blaming each other when something goes wrong.
i could have made that mistake myself. and i applied this lesson to my own learning as if i had.
blessed be the pessimist, for he hath made backups...
> if "rm -i" is the default the "rm" level gets disabled, because "rm -i -f" is the same as "rm -f"
You can use "\rm" to invoke the non-aliased version of the command. I made "rm -i" the default using an alias and occasionally use "\rm" to get the decreased safety level you described. I think it is more convenient that way.
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.
I've long fantasized about a tool I call "expect" that safeguards against crazy stuff like that.
It has a syntax of your expectations, functionally existing as a set of boundaries, and you can hook it to always run as a wrapper for some set of commands. It essentially stages the wrapped command and if none of the boundaries are violated it goes through. Otherwise it yells at you and you need to manually override it.
For instance, pretend I'm ok with mv being able to clobber except in some special directory, let's call it .bitcoin or whatever. (chattr can also solve this, it's just an example). The tool can be implemented relying on things like bpf or preload
Originally I wanted it as a SQL directive ... a way to safeguard a query against doing like `update table set field=value expect rows=1` where you meant to put in the where clause but instead blew away an entire column. I think this would be especially useful surfacing it in frameworks and ORMs some of which make these accidents a bit too easy.
When it comes to SQL, I will often write a SELECT with very explicit search (WHERE) criteria for this very reason. Then copying that statement, commenting the original, and pasting to change into an UPDATE or DELETE statement seems to be a technique that works well for me. The SELECT tells me exactly what I'm going to UPDATE or DELETE, and once I have that, changing the syntax is very minimal. In the case of an ORM, you might have to write a tool that only listens on LOCALHOST to run these statements first.
I always write the where first. It's kinda like thinking in RPN or postfix. I put the parts in out of order in a way that prioritizes the minimization of error.
But this is stupid. These are computers, we can make whatever we want. Executing a delete or update should, if one desires, not have to be database knifeplay.
I know what you mean, I do the same. I agree, but at the same time, it's difficult to start building in protections for the user. Where do you start and where do you stop? I have been forced to do the extreme to protect the user, and then you are asked why things are so difficult to use. I think to make something for someone that concentrates in the technology, as well as a beginner, means you've got to give up so much power (or create a secondary syntax/interface for both audiences). It would be nice to be able to set modes, but then it's going to be database specific unless it has proven itself to be useful across engines. Like most standardization, then you play syntax games between vendors. It would be nice to at least be able to write an UPDATE or DELETE statement with a leading character or keyword to display affected rows.
I understand, but with how much of a change to the language? Such a change would take an enormous amount of time to make it into the ANSI/ISO SQL standard, and what database would start to implement it first, and which would hold out as long as possible?
I don't disagree that it's impossible, but how do you get the syntax standardized at this point? Do you get various dialects, or an agreement between vendors? Look how slowly the standard moves, when do we get this where it's usable in most popular RDBMS?
I have upvoted you for each comment you've made, but I feel like it's not that simple. Even just getting a single vendor to implement it is a huge undertaking. I know that you and I see the value in it, but I don't feel like we're the first to see that. There's a reason behind not implementing this feature, and it's the complexity that lies behind such a feature, like most things. This seems like one of those recursive and interactive features that don't fit into SQL. Does it present the rows that will be updated or deleted, and then ask if you wish to perform the operation? That doesn't work like anything SQL based, and I feel that's why we don't have it. I appreciate the back and forth on this, and am curious as to how you think it should be handled, if there's a way to fit in the way SQL works.
If the expectation is not met then it rolls back and fails. I implemented a slipshod version of it years ago for a previous employer (it got the job done with a lousier syntax)
For sql specifically, “limit 2” is my default way to write “expect 1”; if it affects two rows, I know that I have screwed up, whereas “limit 1” can be wrong without my noticing.
because then i become to rely on stuff being in the trash and i'd be less careful when deleting, which means i have to double check when i clean the trash. that's extra work.
. and since the trash is one single folder for the whole desktop, that means the trash is full of stuff from all over the place, making a review extra hard.
in most cases i know something needs to be gone, so i'd rather delete it on the spot.
besides that, the primary reason for deleting stuff is to gain space. moving things to trash doesn't help with that.
what i sometimes do though, when mass deleting, is to move stuff to be deleted into a new folder (usually called "del" or "delete"). then verify the contents of the folder before removing it.
what would be more useful is a kind of trash implementation that does not take space, in that it keeps files around but reports them as unused space that can be overwritten when space is needed. kind of like undelete is possible on some filesystems. so that gone is gone because i can't control when deleted space gets used up, but in a panic situation i can revert the most recent deletes.
I've heard that one of the Unix founding fathers had a directory with 125 files that all had single-byte names: one for each ASCII symbol except slash, dot and null. He would then test any new utility against this directory and chew the careless programmer out if it couldn't correctly handle every one of these names.
In the long run, special cases like that often turn out to be more trouble than they are worth. If an ordinary file happened to start with '~' it would not be handled correctly. So you either accept or ignore that potential problem, or you have to write extra code to work around it. It's safer to not have such special cases at all.
The original design decision was to behave like a shell, where ~ means your own home dir and ~fred means fred's home dir. With the benefit of experience, this is now seen to be unwise and a different decision has been made.
Just recently I used '~' in the remote target path in the scp command, and, somewhat unexpectedly, it created the directory with that name and put the files there.
In 99% of cases, yes - this is a pain in the backside. Long ago I adopted something from the plan9 way of doing things (when I was heavily using acme).
Just symlink /h to /home. So ~user becomes /h/user, in places where ~ is not expanded for you.
Language snobs and 1990s OO snobs really love to hate on tcl - yeah everything is a string or a command, and the OO extensions were kind of kludgy - but there's a design ethos to the ecosystem that is really special. Ditch tkinter, which is basically writing python to write tcl, and try doing a GUI in straight tcl/tk. Try the sqlite interface. Write a modest C extension or wrap a library. So much of it just works.
I found an article by antirez about TCL [1] which had an interesting perspective. IIRC Redis uses TCL for its test scripts. It was linked from the documentation of https://folk.computer, which uses TCL as its scripting language. And... For that purpose I'm not sure I even hate it.
Naturally AOT also counts, you will find plenty of comments from me regarding CPython versus Common Lisp performance.
However in regards to dynamic languages, unless they support and make use of type annotations with an optimizer compiler, JIT will always perform better than AOT, due to what is possible to do in those languages.
That is why AOT toolchains in Java and .NET world are actually JITs in disguise, because while the languages look static, they inherited much of Smalltalk and Objective-C dynamism that inspired Java semantics, only the syntax was done in a way to be attractive to C++ folks.
And you're not kidding about everything being a command - this here is some "what the fuck is wrong with you people": https://wiki.tcl-lang.org/page/comment
Including the truly stunning collection of:
- one must terminate the command with ; before one can comment
- one cannot have mismatched braces so don't try to comment out bogus code
- one cannot have a backslash in a comment but hey it's a feature not a bug because this is how they launch wish:
#!/bin/sh
# the next line restarts using wish \
exec wish8.0 "$0" "$@"
since the backslash is ignored by the shell but parsed by wish
> New Notifiers: The central event handling engine in Tcl is now constructed on top of the system calls epoll or kqueue when they are available. The select based implementation also remains for platforms where they are not.
This is huge! A big portion of why concurrency in Tcl was so dated and why the language was considered so non-performant was because it relied on `select` despite `epoll` and `kqueue` being available for at least a decade.
Tcl is one of my favorite languages because of how easy it is to get started with and how easy metaprogramming is.
I'm going to give a shout out to NaviServer [0], prior called AOLServer [1]. This web server has been battle-tested and is bullet proof. When something has been used power AOL back in the day, what can you say.
OpenACS [2] is the main project of, which has existed since 1997 and that alone is highly powerful in what it can do with. Especially when coupled with TCL. It's still maintained and now supports TCL9 too!
Javascript, TCL and NaviServer (and which has it's own modules such as DNS Server, LDAP, Mail really makes an powerful tool.
If you're looking to get in to TCL and Web Development, you can really create fun with the two combined. I highly recommend that if you wish to dabble with something on the side for easy learning and plentiful features. Go take a look.
Brings back great memories and (more or less) where I learned both Tcl & SQL... Back in the mid-90's this is the stack and software I was playing with, though admittedly I was using the ArsDigita Community System proper rather than OpenACS (and back when ArsDigita was a thing).
Funny thing is I remember taking some free classes sponsored and taught by ArsDigita in an office they had in Pasadena, CA (or was it Glendale....???) they weren't too deep or long, but nice introductory stuff.
I can't overstate my love for Tcl, yet I had only a little chance to use it when writing XiRCON IRC scripts back in the late 90's. Such an elegant language: simple, easy to learn, flexible. I call it Lisp for humans. I wish it were more popular. So glad to see that it's still alive and kicking.
I also wrote TCL scripts for a IRC client in the 90s, and it was awesome. For that purpose the language was awesome. On the other hand, my other language at that time was x86 assembly so I didnt require much to be awed I guess!
For those that are new to Tcl, there's an alternate universe where Tcl is the browser language instead of Javascript:
"Interesting footnote: the founding of Netscape occurred at the same time I was deciding where to go in industry when I left Berkeley in 1994. Jim Clarke and Marc Andreessen approached me about the possibility of my joining Netscape as a founder, but I eventually decided against it (they hadn't yet decided to do Web stuff when I talked with them). This is one of the biggest "what if" moments of my career. If I had gone to Netscape, I think there's a good chance that Tcl would have become the browser language instead of JavaScript and the world would be a different place! However, in retrospect I'm not sure that Tcl would actually be a better language for the Web than JavaScript, so maybe the right thing happened."
Perhaps. I think one of the main reasons JS caught on is that it had no significant baggage and the designers could take it in any direction it needed to go. Every language used by more than a few people, no matter how good it is, has some baggage. As a result, in that alternate universe, the browser scripting language landscape might have been a lot more fragmented.
The work on the safe subset of Tcl for the web can be exploited today to run untrusted scripts in an easily managed sandbox. If you want you can strip away enough commands for the language to be non-Turing complete.
I'm pretty sure some fellow students came into our computer room before that, "look now there even is a TK plugin for Mosaic!". it was not in "look it's like gopher but with a mouse!" days, but not that much later.
however you of course had to _do_ something to use it, while JavaScript came out of the box (once it was there).
I doubt the world would have stuck with TCL if that had happened. JavaScript was good enough for people to put up with. TCL definitely isn't. More likely we would have ended up with TCL + something else, with TCL deprecated.
So I started playing with TCL for the first time this weekend after seeing this post, and here are my thoughts. I think the language is fun and much different than I’m used to, but my biggest challenge so far is just getting packages installed. There seems to be no current, modern, maintained package manager or central repository, and to do basic stuff like stand up a web server requires compiling from C source. Kinda brutal. TclHttpd failed to compile with TCL 8.6 installed because I guess there was some change in APIs. I didn’t bother spending time figuring out how to patch the C code to make it work because that’s getting in for more than I bargained for.
It’s too bad there’s not a simple way to get up and running with packages because for me so far that had been the biggest barrier to entry / deterrent. Also, I wanted to create a ES256 JWT but there’s no good way to do that apparently, due to the dated ecosystem, whereas in other languages this sort of this is just a package install away. I found a third-party solution in the form of Chilkat software but it costs $300 to license.
So overall while I think TCL is fun, I can see why people don’t choose it when they want to be productive fast and not have to fuss around with deeply manual things that are commonplace and quick in other languages.
This is an _amazing_ book, and one which I am currently working through --- I was reading one chapter, thinking as deeply as I could on it, then re-writing my current project using the lessons from it.
Currently on Chapter 11 (Design it Twice), so will probably just finish, then work on a top--bottom re-write (switching from a current model which has a minimal Python core for variables only, and the balance is in OpenSCAD to a new implementation where everything possible is in Python, allowing usage from there via OpenPythonSCAD: https://pythonscad.org/ )
The 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.
I think of Tcl as Lisp for C programmers; by which I mean, Tcl give you the metaprogramming capabilities you get with Lisp in a language that looks more like C, plays well with C, is much more straightforward than your typical shell language, and has a cross-platform GUI. A skilled Tcl programmer can do magic.
I spent ten years, from 2005 to 2015, programming almost entirely in Tcl/Tk and I loved it. Since then I mostly use it for casual scripts rather than for writing apps; but it's still my #1 choice when I need to do some scripting to automate something at the OS level.
I should add...Tk is the easiest GUI toolkit I've ever used (and I've used a bunch of them). It's got all the basic stuff you need, either built-in or readily available. But it comes from the classic desktop GUI world, you have to work at it to make it look nice, and it's a pain to do webpage-like layouts with it.
I wouldn't do an end-user GUI in Tk at this point; but for in-house tools that need a GUI and don't need to be on the web it's hard to beat.
For strictly developer tools, or for those used to older OS desktops or simplistic widgets, it's really hard to beat Tk. It's been around so long that if you've dealt with it before, it might feel dated, but it's also easy to figure out exactly what it does. I got my start using Tkinter with the O'Reilly Programming Python book (the more expanded book from Learning Python), using Python 2.x (probably 2.4 based on the 2008 or so timeframe I bought it). While at that point I had used C#.Net with their GUI builder, as well as Java's AWT and Swing, and Tkinter felt so much more natural when writing a GUI through code.
BigIP iRules in F5 network appliances (and A10 appliances)[0], orchestration in Argonne National Labs super computer[1], Tealeaf[2], Python Tkinter[3] …
I use it day to day because it’s got a great balance of Lispyness and simple scriptyness, and a great C interface. It’s got a fine REPL, and can be built up (by writing in C) with extensions that are 100% first-class canonical Tcl, in good part (wholly?) because Tcl is such a simple language[4], and homoiconic[5]. A joy to develop in and use.
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 rid of TCL, the better.
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 almost no thought given to edge cases. There was no culture of code review so nobody scrutinized your code to find out whether you were using Tcl in the right way or not. I'll grant, though very lightly, that Tcl has more accessible metaprogramming facilities than Python which makes it easier to misuse than Python. Similar to how Ruby in the hands of a undereducated/bad Ruby programmer is also quite gross.
But I had the same issues using Perl in the EDA industry. The conclusion I came to was that code standards were just abysmal in EDA because code was largely seen as a cost-center activity rather than a profit-center activity as the real output was the ETL or the device and not the code that went into it.
I re-learned Tcl when I was older and when my time in EDA was a faint memory and I found the language a joy. It was remarkably easy to get started in and really easy to build an application out of. This experience further made me reflect on how bad the code culture in EDA was.
So I'm curious what specifically you'd see the EDA industry move to and how you think it would fix the problems EDA currently has with Tcl. Python, is the successor I imagine? That said my actual time in EDA was very short so I welcome the opinion of an actual insider.
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.
> 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.
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.
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.
Most likely for the same reason you found. Once you know it, it's very easy to use, and it's available in most distributions (if not all). So both familiarity with Tcl, while having that ability to build out quick and stable GUI tests, including the lack of churn in the GUI framework. For myself, having to readapt to a GUI framework when I'm just trying to get something visual up and running to make life slightly easier, makes something like Tk much more beneficial for just getting work done. A bit ugly, but anyone technically inclined will figure it out quickly, without constantly having to change up libraries. I only speak for myself and put my 2 cents in, I don't speak for anyone else, but for general tooling targeted at developers it seems perfect.
Both Richard Hipp and Salvatore Sanfillipo came out of the Tcl community. SQLite was originally just a Tcl extension (and may I say, SQLite's Tcl binding is a dream to use). In a nutshell, they were already using Tcl because they found it useful.
I used it a few times, mainly because of Freewrap. With very little code I was able to write a Windows app with GUI that I could distribute easily as an executable:
- A backup app for an online sales application (inputs items and spits out a file);
- An app to fix files in a buggy POS for a large retail chain (this might have been used in thousands of machines, I can't recall the details now);
- A small app to copy Forms/Reports to the server, fire compilation, and push the new file to git;
- A wrapper for gs to help a media department easily join many PDFs into one file.
Some time ago i was playing with a Raspberry Pi and wanted to write some code in there. The Gtk3-powered Geany was WAY too slow (like, type and wait for the letter to appear slow). I recompiled it to use Gtk2, it was much faster but also it was buggy (the code display was getting messed up).
Nedit (based on Motif) on the other hand was both very fast (faster than the Gtk2 Geany) and bug-free - it worked perfectly. But i wanted Geany because of the file browser sidebar.
So i wrote a small Tcl/Tk script to display a list of files using a filter in a directory and call Nedit to edit them when you doubleclicked. Also added a few buttons to call make, make clean, open a terminal, make a new file, etc and worked perfectly.
A few years since then i made a few improvements and modifications to this script and use it on my main PC whenever i want to work on C source code - though i use Krita instead of Nedit here (Krita has its own file browser sidebar but i find the way it works annoying - and doesn't have all the extra stuff i've added over time to the script).
The neat bit is that it reads a Tcl file from the home directory for "global" configuration (e.g. which editor to use, how to run terminal commands, etc) and then a Tcl file from the current directory for project-specific stuff, all of which having access to the main script's own procs for things like calling terminal commands, showing a few dialogs, etc.
I've uploaded the latest version of the script to my website a few days ago[0]. I've been mainly using it with Linux but a couple of years ago i also used it a bit with Windows using MSYS2 (with Notepad++ for the editor) and worked fine.
Is Electron really considered a competitor to Tk based GUIs?
In my (limited) experience, Tcl/Tk is great for basic stuff but I don't think you could do even a small part of what you can do with an html + css + javascript GUI.
It used to be the other way around. It’s been a while since I did much UI work, but the web always felt incredibly frustrating for layout compared to Tk. (I think CSS finally has something approaching Tk’s grid layout manager?) There are fewer frameworks for Tk, but I think it has most things you’d need. Maybe some of the finer control over fonts etc is lacking.
Most of what I'd call the UI - all the toolbars and pseudo-floating-windows - is basic bread-and-butter Tk stuff. The 3D context and CAD kernel would be the tricky bits. There are extensions floating around to work with OpenGL (or whatever), but I don't see doing the heavy CAD-kernel lifting in Tcl - that would likely have to be in C, or whatever. (Just as it presumably is for Onshape.)
You are correct. Having written such a thing, you do all your basic UI in Tcl/Tk and have a custom widget doing all OpenGL/whatever rendering. The rest of the code treats it as a canvas-like widget.
I agree with you but a lot of the demand for GUI tools is small tools. Think something like Postman: it's really just a code editor widget to put in some request metadata and a table view storing requests. This is the kind of tool that something like Tcl would be great at and really doesn't need the sophistication of HTML+CSS+JS.
Quite common in space industry. It is the script language used in many (all?) SCOS-2000 based mission control systems. Yes, is is actually used to control satellites and spacecrafts.
I often use the tool that is closest to another tool I am using. The closeness may be due to a common heritage, both technical and cultural. A common thread between the two is often high quality, maturity, cross-fertilization, long-term commitment, etc.
Now when it comes to Tcl, I use it for the above reasons because it is so convenient for writing scripts to use SQLite. In other words, it is my go-to wrapper for many SQLite applications. This is mainly related to (rapid) prototyping use cases.
> The SQLite library is designed to be very easy to use from a Tcl or Tcl/Tk script. SQLite began as a Tcl extension and the primary test suite for SQLite is written in TCL. SQLite can be used with any programming language, but its connections to TCL run deep.
If there's any better relational database API, in any language, than SQLite's Tcl interface, I've not seen it yet. (And the reasons SQLite's Tcl interface is so good would either be hard to replicate without Tcl, hard to replicate without SQLite, or both.)
It has expect[1], a nice tool to automate terminal applications.
Two examples:
- Adding convenience features to the Cisco IOS CLI (e.g., ^D to exit).
- Implementing the back end of a native WPF Windows GUI application that downloads spooled print jobs from a third-party system that only provides remote spooler access through a full-screen interactive terminal application running over ssh. This application also makes use of another nice Tcl feature, its trivially-implemented remote protocol[2].
>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.
For a long time it was the only way to get a decent IRC bot going, because eggdrop[0] was a Tcl wrapper around a small C core, but the only place I've seen it in the wild other than IRC bots was in the Xilinx toolchain and once when I was in undergrad some TA was using it to get telemetry from Tektronix oscilloscopes in the robotics lab.
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.
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.
Lua is quite a bit larger than Tcl. In addition, no two Lua installations can ever agree on which modules they require (which makes the actual Lua binary even bigger).
Larger? On my system libtcl8.6.so is 1.7 megabytes and liblua5.1.so is 192 kilobytes. It's not even close. Lua uses libraries / modules based on where you tell the interpreter they are located, so that's on you.
Tk was pretty usable for tcl/tk use cases on Mac by later 7.x releases, say 1996 or so. Still hard to get a really native UX on Windows or Mac though. HyperCard was already on its way out. 30 years ago is maybe closer than you think?
That's what it was created for, believe it or not. And it's been used there since the early '90s; there were very few other embeddable scripting languages at the time, so it caught on quickly.
Back in the late 90's we used it on our startup, several of companies at the time were trying the luck on Tcl based application servers, AOLServer being the most well known.
There was Vignette, and we at Intervento had our Safelayer product, loosely based on AOLServer.
Apache and IIS plugins for hosting Tcl interpreter, running on Aix, HP-UX, Solaris, Red-Hat Linux, Windows 2000/NT, with support for Oracle, Informix, DB2, Sybase SQL Server, Microsoft SQL Server, Access (only for test purposes).
Development environment was based on Emacs, eventually there was one written in Visual Basic specifically for the product, with project templates and other kinds of goodies.
However we eventually hit the limits of using Tcl, and having to rewrite parts of the platform in C.
As it was, being a gold MSFT partner gave us access to .NET before it was announced to the world, and a plan to rewrite our product into C# took place.
With the learnings of these experiences, and customisations done at client sites, the founders eventually moved on and created one of the best products for no code development still going strong nowadays, OutSystems.
AOLServer (now Naviserver again) is still the base for the largest open-source project management system: ]project-open[ (https://www.project-open.com/)
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.
- 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.
* 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.
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:
You can't define new data structures as such in pure Tcl, as you don't have pointers. And as for cycles, you can't modify an object to add a reference to itself, since the copy-on-write will just create a new object.
Eggdrop IRC bots. Even 25 years since I first created one, Eggdrop is still the best and most reliable + flexible IRC bot platform, and comes with native support for Tcl.
I use it to write long running little scripts. It's better than shell, and imo more useful out of the box than Lua. They are basically for I/O (often using sqlite which it has great integration with, or using expect which is also great) so I don't care about performance, but I like that it requires much less memory compared to say Python for that kind of little things (there is also jimtcl which is also neat in this regard).
Same. I learned Tcl recently for /usr/bin/expect. I wasn't happy to be forced into using yet another esoteric language, but Tcl itself is strangely fun: it's like a more expressive and functional Lua.
Ha, I was in the same position. It's fantastic at scripting serial consoles.
Oddly enough, Lua is also near and dear to my heart. It's a great language to embed to allow non C or C++ folks the ability to extend software or to do so dynamically.
The only reason to use it today is because you're forced to by the EDA industry. Otherwise there are far far better options.
That also means this release is basically irrelevant for the next 10 years because that's about how long it takes the EDA vendors to update their bundled TCL versions.
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.)
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.
A theming engine went in something like 15 years ago now; the default theme looks rather dated, but there are plenty of others. See https://wiki.tcl-lang.org/page/List+of+ttk+Themes (though the screenshots of core themes are from 8.5/8.6 - default in particular has changed a bit in Tk 9).
The "catch" is that the theming engine has its own new widgets, and so to be themed an application has to use the new API. Code from 1995 (or 2005) still produces GUIs from 1995.
Yeah, they added that a long time ago, but it's not at all the same as built-in support. My experience was trying out fragile third-party projects with little or no documentation. The whole point of using Tcl/Tk for writing a GUI was the convenience.
Things may have changed over time. I no longer pay attention. Maybe I'll give it another try.
The theming engine is absolutely "built-in", as are a handful of themes; in particular aqua and the winnative/xpnative/vistanative family (which integrate with the Mac/Windows windowing system such that the application will look "native" by default on those systems).
> which integrate with the Mac/Windows windowing system such that the application will look "native" by default on those systems
That's my point. You can make an app that looks okay on those OSes, but all of the built-in options for Linux look ridiculous, and then you're back to the third-party stuff.
I don't think clam looks "ridiculous", but I suppose we're in to subjective stuff now. :)
In principle this isn't really any different from GTK or Qt theming (where it's up to users to go forth and find themes they like, and set the default as desired), but in those cases you tend to get themes packaged up by distributions and GUI configuration support from desktop environments, and neither seems likely to happen for Tk.
Reminds me of using Tkinter with Python, while learning Python. There are other GUIs available, but finding examples of working code with a newer GUI is going to be more troublesome (but not impossible). I think it's just that the documentation has been centered around Tk(inter) for so long, most people just choose it as a default. I know Python has gotten better about GUI support (probably from the popularity in machine learning/AI usage), but with Tcl being less popular, you need to do some due diligence to find up to date documentation on modern GUI usage.
Sourceforge still works, and is (now) reliable. The awful DevShare malware stuff that Sourceforge started (under new ownership) in 2012 was stopped (under different new ownership) in 2016.
The site is ugly and difficult to navigate. Go there and enter TCL in the search box and see how many clicks you have to do to actually find the project. Then when you click the download button a timer has to run out before the download will start.
Maybe it technically works, but it's a terrible UX.
Wow Tcl is still a thing? Takes me back to university days — and even 20 years ago it was considered a bit of a poor man’s UX. I’m off to read the article and see if it’s any better these days…
Love reading this. I spent a few years in the late 90s using Tcl/Tk to build cross-platform installers for Embedded tools/libraries, along with Expect for a bunch of our testing. One of those pragmatic toolsets for getting sh*t done.
In the realm of Electronic Design Automation (EDA), TCL is ubiquitous. Virtually every EDA tool offers a TCL interface or API, making it the predominant language for tool configuration. I've always wondered why TCL hasn't gained traction in other domains. It possesses the elegance of Lisp while maintaining practicality.
Great to see all the love for TCL here :) Too bad it's not more popular really but even I struggle to find cases where I'd prefer it. Usually it come down to bash for simple stuff and python everything else.
It would be nice if the releases were cryptographically signed. I've never used Tcl/Tk before but I just downloaded the 9.0 release and I'll give it a go.
I know of Tcl but I don’t know anything about its structure. The number one thing I ask of a language is consistency: the minimal amount of magic and most of the language implemented in itself. Ruby almost got there and then, for me, slipped up on class << self.
The Tcl language is made up of commands; a command has a name and takes an argument list, with which it can do literally anything. The standard commands are written in C; Tcl `procs` are commands that are written in Tcl. The control structures, like `if` and `foreach` and `while` is just a Tcl command. The `proc` command that defines a proc is just a Tcl command.
I think of it as Lisp for C programmers.
So: is the language implemented mostly in itself? No, it's mostly implemented in C. Is there a minimal amount of magic? No; the amount of magic you can do is effectively unlimited.
> Is there a minimal amount of magic? No; the amount of magic you can do is effectively unlimited.
I might be mistaken, but I think the OP was asking if there is surprising magic (I.e. special cases/considerations) built into the language, in which case I’d say, “No, Tcl is not “magical”, but surprisingly simple and regular.” That said, indeed it’s powerful in its application of its primitives, but you do still need to mind some things (don’t pretend* you can quote better than the quoting engine, don’t pretend* you can do lists better than the list processor, …). Not magical though - very understandable.
*rules are meant to be broken, blah, blah, but the “gotchas” are new practitioners falling into this, or advanced cases, falling into this…
As someone that is stubbornly trying to design a Smalltalk-Forth hybrid syntax, where everything is words, nay, messages in a declarative/concatenative pipeline, without success, reading this makes me inappropriately giddy.
Thanks for this explanation. It was very helpful. In terms of magic I meant it simply as how big is the set of unchangeable axioms, as opposed to how many things are derived in the language itself from a more minimal set of magical axioms. With Lisp being the language with the least magic lisp for C programmers was insightful!
Tcl's magic is mainly from uplevel and upvar as they allow you to do crazy stuff with the callstack to enable all kinds of metaprogramming. It's not a lot of magic, but it's very powerful.
Some people like Tcl and use it, some people don't. The Tcl Wiki sees a regular stream of updates - https://wiki.tcl-lang.org/recent . Personally I'm working on a Usenet/Web gateway which does web serving, NNTP, caching in Redis, user db in sqlite, all implemented in Tcl - https://cmacleod.me.uk/ng .
The first major release in 27 years. 64-bit internal structures, so data can be huge. Full unicode with all the funky new emojis. Zip filesystems, etc., etc.
There's lots of new stuff, and some old cruft has been dumped, so some programs may need a few updates, but there's still a high level of compatibility. The page above links to release notes with details of what's in and what's out.
The Zip filesystem stuff is wonderful change to see: it takes a number of techniques that were common in the community (if you had the right tools and knew how to use them) for building standalone applications, and makes them part of the basic toolkit in a standard way. It's a truly excellent change, and I'm glad to see it.
Can you explain what zip filesystem is?
A handler for treating .zip (and .jar and .tar ...) files as if they were a volume mounted at /home/user/foo.zip - e.g. https://github.com/openjdk/jdk/blob/jdk-21-ga/src/java.base/...
It may be easier to reason about when thinking of the way $(mount -o loop) works with .iso files -- a file that is a container for other files that one can mount as if it were a filesystem
I was expecting pathlib in Python <https://docs.python.org/3/library/pathlib.html> to have one since a lot of Python distributions ship the standard library in .zip files but evidently not. Python gonna Python in that way
Firefox actually used to ship with that same "jar:" protocol handler, too, and I made good use of it for reading the javadoc html which was shipped inside zip files and was indescribably easier than trying to manage all the .html files in a Java 8 SDK distribution. They made heavy use of this because a lot of their internals were in .xpi formats (which is also a .zip file) but they recently dropped it because Firefox gonna Firefox^W double down on some random shit other than making a sane browser
Emacs implements something like this too! It’s pretty useful to be able to just enter a tarball and work with the files in it.
It looks like https://github.com/cybernoid/archivemount provides a similar experience in the shell, although one would have to mount the file first.
Python has something kinda like VFS support just as a very special case for importing stuff and reading associated data files, see Anchor ("mount point") and Traversable ("virtual Path") in https://docs.python.org/3.12/library/importlib.resources.abc... - the actual implementation is done in finders et al (https://docs.python.org/3.12/library/importlib.html#module-i...)
they should do the same but for git repositories too
not .tar
I'm not a TCL user, but from the description of wduquette is sounds similar to Python's zipapp
https://docs.python.org/3/library/zipapp.html
The definition of "standalone application" is a bit stronger - what's always been possible with "Tclkits" has been to embed the application code in an interpreter binary and distribute that, and the new core zipfs supports that as well.
Yes, exactly. You can package up your entire scripted application, plus all resources, into a single executable, and distribute that single file.
Why did they remove tilde '~' as a convenient shortcut for the Home directory?
Tcl Improvement Proposal (TIP) 602[0].
[0] https://core.tcl-lang.org/tips/doc/trunk/tip/602.md
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 then remove the empty directory. "rmdir dir/"
if i do want to use rm -r, it is with a long path. eg in order remove stuff in the current directory i may distinctly add a path: rm -r ../currentdir/*" instead of "rm -r *"
related, i also usually run "rm -i", but most importantly, i disable any alias that makes "rm -i" the default, because in order to override the -i you need to use -f, but "rm -i -f" i NOT the same thing as "rm". rm has three levels of safety: "rm -i; rm; rm -f". if "rm -i" is the default the "rm" level gets disabled, because "rm -i -f" is the same as "rm -f"
My main safety habit is to avoid slashless paths.
Bad:
Okay: Then again, I commonly use dangerous things like `mv somefile{,.away}` that are easy to get wrong, so maybe don't trust my advice too much.Fair! Upvoted.
I guess I'm not likely to type that into the shell, or if I do, I then tab-complete to expand it.
I could definitely see myself using that in a shell script, though. I tend to do validity checks there:
but that's kind of irrelevant, since if I need it to exist then I won't be removing it. Plus, I could totally see myself doingIn bash, `set -u` or `"${TSTDIR:?Error: TSTSDIR is required.}/etc"` protects from such errors.
My safety technique is to echo the commands before I do the actual commands as a sanity check, e.g.
for i in $(find something); do echo "rm -f $i"; done
(bash example as my TCL is rusty)
Change your do block to `printf %q\ rm -f "$i" ; echo` and it won't lie about spaces. In case HN has "trimmed" my post in some way, as it often does, that's: percent q backslash space space. Works in bash/zsh, but not dash, probably not whatever your sh is. Can make a function of it trivially, but you have to handle the $# -eq 0 case, return whatever printf returns, etc.
When deleting, if it is more than a few specifically named files I will use a "find ... -delete" invocation.
I like it for two reasons. Find feels like it has more solidly defined patterns and recursion than shell globing and by leaving off the "-delete" it give me a chance to inspect the results before committing to my actions.
Without testing, I wonder if find follows symlinks. I’m pretty sure rm doesn’t.
Edit: Just checked and find doesn’t by default.
Very cool of you to post this. Too many people won't post stories like this, but I've done very similar multiple times. I think it definitely helps reinforce proper habits, and is the best way to cut your teeth on technology. It's also great for anyone new to read something like this, and be able to avoid something so devastating, and maybe make lesser mistakes, but still learn from both!
when you get to be as old as i am, these are the war stories you share with your kids and grandkids around the campfire ;-)
like the one from my colleague who once fat fingered fsck into mkfs and i lost my personal homepage because of it. what makes me uncomfortable about that story is that it was not my fault. if it were it would have been easier to tell. but at the time i was quite frustrated and my colleague felt that despite me trying to not get angry at him. i still feel really bad about my reaction then, adding to his predicament, since he had to live with the guilt about losing our website and everyone's personal home directory. it's bad when a mistake causes you to loose something personal, but so much worse when you loose someone elses stuff.
talking about mistakes is how we learn from them. the important part is not to get embarrassed about them. however that requires an environment where we are not blaming each other when something goes wrong.
i could have made that mistake myself. and i applied this lesson to my own learning as if i had.
blessed be the pessimist, for he hath made backups...
> if "rm -i" is the default the "rm" level gets disabled, because "rm -i -f" is the same as "rm -f"
You can use "\rm" to invoke the non-aliased version of the command. I made "rm -i" the default using an alias and occasionally use "\rm" to get the decreased safety level you described. I think it is more convenient that way.
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.
I've long fantasized about a tool I call "expect" that safeguards against crazy stuff like that.
It has a syntax of your expectations, functionally existing as a set of boundaries, and you can hook it to always run as a wrapper for some set of commands. It essentially stages the wrapped command and if none of the boundaries are violated it goes through. Otherwise it yells at you and you need to manually override it.
For instance, pretend I'm ok with mv being able to clobber except in some special directory, let's call it .bitcoin or whatever. (chattr can also solve this, it's just an example). The tool can be implemented relying on things like bpf or preload
Originally I wanted it as a SQL directive ... a way to safeguard a query against doing like `update table set field=value expect rows=1` where you meant to put in the where clause but instead blew away an entire column. I think this would be especially useful surfacing it in frameworks and ORMs some of which make these accidents a bit too easy.
When it comes to SQL, I will often write a SELECT with very explicit search (WHERE) criteria for this very reason. Then copying that statement, commenting the original, and pasting to change into an UPDATE or DELETE statement seems to be a technique that works well for me. The SELECT tells me exactly what I'm going to UPDATE or DELETE, and once I have that, changing the syntax is very minimal. In the case of an ORM, you might have to write a tool that only listens on LOCALHOST to run these statements first.
I always write the where first. It's kinda like thinking in RPN or postfix. I put the parts in out of order in a way that prioritizes the minimization of error.
But this is stupid. These are computers, we can make whatever we want. Executing a delete or update should, if one desires, not have to be database knifeplay.
I know what you mean, I do the same. I agree, but at the same time, it's difficult to start building in protections for the user. Where do you start and where do you stop? I have been forced to do the extreme to protect the user, and then you are asked why things are so difficult to use. I think to make something for someone that concentrates in the technology, as well as a beginner, means you've got to give up so much power (or create a secondary syntax/interface for both audiences). It would be nice to be able to set modes, but then it's going to be database specific unless it has proven itself to be useful across engines. Like most standardization, then you play syntax games between vendors. It would be nice to at least be able to write an UPDATE or DELETE statement with a leading character or keyword to display affected rows.
It's completely Optional safeguards. Add long as it's optional, I advocate for having as many of those as people can imagine
I understand, but with how much of a change to the language? Such a change would take an enormous amount of time to make it into the ANSI/ISO SQL standard, and what database would start to implement it first, and which would hold out as long as possible?
I don't disagree that it's impossible, but how do you get the syntax standardized at this point? Do you get various dialects, or an agreement between vendors? Look how slowly the standard moves, when do we get this where it's usable in most popular RDBMS?
The venn diagram of query support between SQL vendors is much closer to a flower than you think.
Just implement it for one and if it works, the others will add it
I have upvoted you for each comment you've made, but I feel like it's not that simple. Even just getting a single vendor to implement it is a huge undertaking. I know that you and I see the value in it, but I don't feel like we're the first to see that. There's a reason behind not implementing this feature, and it's the complexity that lies behind such a feature, like most things. This seems like one of those recursive and interactive features that don't fit into SQL. Does it present the rows that will be updated or deleted, and then ask if you wish to perform the operation? That doesn't work like anything SQL based, and I feel that's why we don't have it. I appreciate the back and forth on this, and am curious as to how you think it should be handled, if there's a way to fit in the way SQL works.
If the expectation is not met then it rolls back and fails. I implemented a slipshod version of it years ago for a previous employer (it got the job done with a lousier syntax)
Here's a list of 1,000 postgres extensions, it's not a big deal: https://gist.github.com/joelonsql/e5aa27f8cc9bd22b8999b7de8a...
Things are way more modular than they used to be.
I can probably do it again and just try to get attention for it.
From the hip, maybe something like "UPDATE DRYRUN ...". It'd report how many rows would be updated.
Or... "DRYRUN UPDATE ...", which is more like "EXPLAIN UPDATE..."
Thoughts?
For sql specifically, “limit 2” is my default way to write “expect 1”; if it affects two rows, I know that I have screwed up, whereas “limit 1” can be wrong without my noticing.
That's not a terrible solution although expect sounds like a simple safety mechanism for feeble-minded people like me who do simple queries.
I actually know postgres people. I should probably ask them
just to clarify, this has nothing to do with the "expect" that is the other major application of tcl other than tk?
None.
I was just reminded of a good idea I never implemented
Oh yeah, re: SQL expect - I always wish joins had a "cardinality assertion", like a regex *?+ (or ! for exactly one)
You could also create a file named "-i" in your home dir.
Why not learn to enjoy life knowing you get a second chance instead ?:
https://github.com/rushsteve1/trash-d
because then i become to rely on stuff being in the trash and i'd be less careful when deleting, which means i have to double check when i clean the trash. that's extra work. . and since the trash is one single folder for the whole desktop, that means the trash is full of stuff from all over the place, making a review extra hard. in most cases i know something needs to be gone, so i'd rather delete it on the spot.
besides that, the primary reason for deleting stuff is to gain space. moving things to trash doesn't help with that.
what i sometimes do though, when mass deleting, is to move stuff to be deleted into a new folder (usually called "del" or "delete"). then verify the contents of the folder before removing it.
what would be more useful is a kind of trash implementation that does not take space, in that it keeps files around but reports them as unused space that can be overwritten when space is needed. kind of like undelete is possible on some filesystems. so that gone is gone because i can't control when deleted space gets used up, but in a panic situation i can revert the most recent deletes.
I once created a file named *. Sweats were sweated that day.
I've heard that one of the Unix founding fathers had a directory with 125 files that all had single-byte names: one for each ASCII symbol except slash, dot and null. He would then test any new utility against this directory and chew the careless programmer out if it couldn't correctly handle every one of these names.
In the long run, special cases like that often turn out to be more trouble than they are worth. If an ordinary file happened to start with '~' it would not be handled correctly. So you either accept or ignore that potential problem, or you have to write extra code to work around it. It's safer to not have such special cases at all.
Should be starts with ~/
No, ~abc will be interpreted as the home directory of user abc in Tcl 8.*
Then you fix this mistake, not remove ~ completely
It's not a mistake
If it's not a mistake then why they took it off?
The original design decision was to behave like a shell, where ~ means your own home dir and ~fred means fred's home dir. With the benefit of experience, this is now seen to be unwise and a different decision has been made.
Just recently I used '~' in the remote target path in the scp command, and, somewhat unexpectedly, it created the directory with that name and put the files there.
In 99% of cases, yes - this is a pain in the backside. Long ago I adopted something from the plan9 way of doing things (when I was heavily using acme).
Just symlink /h to /home. So ~user becomes /h/user, in places where ~ is not expanded for you.
Language snobs and 1990s OO snobs really love to hate on tcl - yeah everything is a string or a command, and the OO extensions were kind of kludgy - but there's a design ethos to the ecosystem that is really special. Ditch tkinter, which is basically writing python to write tcl, and try doing a GUI in straight tcl/tk. Try the sqlite interface. Write a modest C extension or wrap a library. So much of it just works.
I found an article by antirez about TCL [1] which had an interesting perspective. IIRC Redis uses TCL for its test scripts. It was linked from the documentation of https://folk.computer, which uses TCL as its scripting language. And... For that purpose I'm not sure I even hate it.
[1] http://antirez.com/articoli/tclmisunderstood.html
It made our startup possible, and the experience and learnings we got out of it, were in the genesis of OutSystems.
One of those learnings, was that I never wanted to again use a dynamic language without any kind of JIT compiler for full blown web servers.
The language is great, rewriting Tcl libraries into C on regular basis due to performance issues not so much.
> I never wanted to again use a dynamic language without any kind of JIT compiler
What about a dynamic language with an AOT compiler? E.g. SBCL implements Common Lisp by compiling everything ahead of time.
Naturally AOT also counts, you will find plenty of comments from me regarding CPython versus Common Lisp performance.
However in regards to dynamic languages, unless they support and make use of type annotations with an optimizer compiler, JIT will always perform better than AOT, due to what is possible to do in those languages.
That is why AOT toolchains in Java and .NET world are actually JITs in disguise, because while the languages look static, they inherited much of Smalltalk and Objective-C dynamism that inspired Java semantics, only the syntax was done in a way to be attractive to C++ folks.
What do you use now? Node.js? Groovy?
Mostly Java, C#, Typescript and C++ when native libraries are called for.
> yeah everything is a string or a command
And you're not kidding about everything being a command - this here is some "what the fuck is wrong with you people": https://wiki.tcl-lang.org/page/comment
Including the truly stunning collection of:
- one must terminate the command with ; before one can comment
- one cannot have mismatched braces so don't try to comment out bogus code
- one cannot have a backslash in a comment but hey it's a feature not a bug because this is how they launch wish:
since the backslash is ignored by the shell but parsed by wishI got to work with a lot of tcl while working on TPC benchmarks for Citus
https://github.com/TPC-Council/HammerDB/blob/master/src/post...
tcl makes as an alright shell script language
> New Notifiers: The central event handling engine in Tcl is now constructed on top of the system calls epoll or kqueue when they are available. The select based implementation also remains for platforms where they are not.
This is huge! A big portion of why concurrency in Tcl was so dated and why the language was considered so non-performant was because it relied on `select` despite `epoll` and `kqueue` being available for at least a decade.
Tcl is one of my favorite languages because of how easy it is to get started with and how easy metaprogramming is.
mostly people consider tcl non-performant because fundamental operations are about twice as slow as cpython, which is no speed demon: https://news.ycombinator.com/item?id=41637953
another reason is that we don't know how to write fast tcl, as i inadvertently demonstrated in that thread
I'm going to give a shout out to NaviServer [0], prior called AOLServer [1]. This web server has been battle-tested and is bullet proof. When something has been used power AOL back in the day, what can you say.
OpenACS [2] is the main project of, which has existed since 1997 and that alone is highly powerful in what it can do with. Especially when coupled with TCL. It's still maintained and now supports TCL9 too!
Javascript, TCL and NaviServer (and which has it's own modules such as DNS Server, LDAP, Mail really makes an powerful tool.
If you're looking to get in to TCL and Web Development, you can really create fun with the two combined. I highly recommend that if you wish to dabble with something on the side for easy learning and plentiful features. Go take a look.
[0] https://wiki.tcl-lang.org/page/NaviServer
https://github.com/naviserver-project/naviserver
[1] https://news.ycombinator.com/item?id=35648805
https://www.linuxjournal.com/article/6164
[2] https://openacs.org/about/history
https://openacs.org/
Brings back great memories and (more or less) where I learned both Tcl & SQL... Back in the mid-90's this is the stack and software I was playing with, though admittedly I was using the ArsDigita Community System proper rather than OpenACS (and back when ArsDigita was a thing).
Funny thing is I remember taking some free classes sponsored and taught by ArsDigita in an office they had in Pasadena, CA (or was it Glendale....???) they weren't too deep or long, but nice introductory stuff.
I can't overstate my love for Tcl, yet I had only a little chance to use it when writing XiRCON IRC scripts back in the late 90's. Such an elegant language: simple, easy to learn, flexible. I call it Lisp for humans. I wish it were more popular. So glad to see that it's still alive and kicking.
Agreed, my only exposure to Tcl was writing IRC scripts for bots and I have nothing but fond memories of the experience.
Same. Such a simple life writing text-only event handlers.
I also wrote TCL scripts for a IRC client in the 90s, and it was awesome. For that purpose the language was awesome. On the other hand, my other language at that time was x86 assembly so I didnt require much to be awed I guess!
>I call it Lisp for humans.
Except for upvar.
CMake similarly is sick in the head: https://cmake.org/cmake/help/v3.30/command/set.html#normal (heh, I enjoy that the documentation anchor is "normal" for SET(FOO BAR PARENT_SCOPE)
What's upvar? :-)
Nothing much, what about you?
For those that are new to Tcl, there's an alternate universe where Tcl is the browser language instead of Javascript:
"Interesting footnote: the founding of Netscape occurred at the same time I was deciding where to go in industry when I left Berkeley in 1994. Jim Clarke and Marc Andreessen approached me about the possibility of my joining Netscape as a founder, but I eventually decided against it (they hadn't yet decided to do Web stuff when I talked with them). This is one of the biggest "what if" moments of my career. If I had gone to Netscape, I think there's a good chance that Tcl would have become the browser language instead of JavaScript and the world would be a different place! However, in retrospect I'm not sure that Tcl would actually be a better language for the Web than JavaScript, so maybe the right thing happened."
Source: https://pldb.io/blog/JohnOusterhout.html
Perhaps. I think one of the main reasons JS caught on is that it had no significant baggage and the designers could take it in any direction it needed to go. Every language used by more than a few people, no matter how good it is, has some baggage. As a result, in that alternate universe, the browser scripting language landscape might have been a lot more fragmented.
> it had no significant baggage and the designers could take it in any direction it needed to go
This is a fantastic insight and put very well. Thank you.
New platforms unlock rare opportunities for new languages that have no baggage and can focus on fully exploiting the new platform.
The work on the safe subset of Tcl for the web can be exploited today to run untrusted scripts in an easily managed sandbox. If you want you can strip away enough commands for the language to be non-Turing complete.
funny enough, tcl browser plugins were around from at least 1996
https://sunsite.icm.edu.pl/pub/programming/tcl/plugin/
I'm pretty sure some fellow students came into our computer room before that, "look now there even is a TK plugin for Mosaic!". it was not in "look it's like gopher but with a mouse!" days, but not that much later.
however you of course had to _do_ something to use it, while JavaScript came out of the box (once it was there).
I doubt the world would have stuck with TCL if that had happened. JavaScript was good enough for people to put up with. TCL definitely isn't. More likely we would have ended up with TCL + something else, with TCL deprecated.
> maybe the right thing happened
Absolutely. I would have hated to see things like
all over the place. (As a command language, this is not so bad.)So I started playing with TCL for the first time this weekend after seeing this post, and here are my thoughts. I think the language is fun and much different than I’m used to, but my biggest challenge so far is just getting packages installed. There seems to be no current, modern, maintained package manager or central repository, and to do basic stuff like stand up a web server requires compiling from C source. Kinda brutal. TclHttpd failed to compile with TCL 8.6 installed because I guess there was some change in APIs. I didn’t bother spending time figuring out how to patch the C code to make it work because that’s getting in for more than I bargained for.
It’s too bad there’s not a simple way to get up and running with packages because for me so far that had been the biggest barrier to entry / deterrent. Also, I wanted to create a ES256 JWT but there’s no good way to do that apparently, due to the dated ecosystem, whereas in other languages this sort of this is just a package install away. I found a third-party solution in the form of Chilkat software but it costs $300 to license.
So overall while I think TCL is fun, I can see why people don’t choose it when they want to be productive fast and not have to fuss around with deeply manual things that are commonplace and quick in other languages.
Fun facts, the author of Tcl and tk is Prof. John Ousterhout, and his Software Design book is in its 2nd edition:
A Philosophy of Software Design:
https://web.stanford.edu/~ouster/cgi-bin/book.php
This is an _amazing_ book, and one which I am currently working through --- I was reading one chapter, thinking as deeply as I could on it, then re-writing my current project using the lessons from it.
Currently on Chapter 11 (Design it Twice), so will probably just finish, then work on a top--bottom re-write (switching from a current model which has a minimal Python core for variables only, and the balance is in OpenSCAD to a new implementation where everything possible is in Python, allowing usage from there via OpenPythonSCAD: https://pythonscad.org/ )
The 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.
I think of Tcl as Lisp for C programmers; by which I mean, Tcl give you the metaprogramming capabilities you get with Lisp in a language that looks more like C, plays well with C, is much more straightforward than your typical shell language, and has a cross-platform GUI. A skilled Tcl programmer can do magic.
I spent ten years, from 2005 to 2015, programming almost entirely in Tcl/Tk and I loved it. Since then I mostly use it for casual scripts rather than for writing apps; but it's still my #1 choice when I need to do some scripting to automate something at the OS level.
I should add...Tk is the easiest GUI toolkit I've ever used (and I've used a bunch of them). It's got all the basic stuff you need, either built-in or readily available. But it comes from the classic desktop GUI world, you have to work at it to make it look nice, and it's a pain to do webpage-like layouts with it.
I wouldn't do an end-user GUI in Tk at this point; but for in-house tools that need a GUI and don't need to be on the web it's hard to beat.
For strictly developer tools, or for those used to older OS desktops or simplistic widgets, it's really hard to beat Tk. It's been around so long that if you've dealt with it before, it might feel dated, but it's also easy to figure out exactly what it does. I got my start using Tkinter with the O'Reilly Programming Python book (the more expanded book from Learning Python), using Python 2.x (probably 2.4 based on the 2008 or so timeframe I bought it). While at that point I had used C#.Net with their GUI builder, as well as Java's AWT and Swing, and Tkinter felt so much more natural when writing a GUI through code.
Standard fare:
BigIP iRules in F5 network appliances (and A10 appliances)[0], orchestration in Argonne National Labs super computer[1], Tealeaf[2], Python Tkinter[3] …
I use it day to day because it’s got a great balance of Lispyness and simple scriptyness, and a great C interface. It’s got a fine REPL, and can be built up (by writing in C) with extensions that are 100% first-class canonical Tcl, in good part (wholly?) because Tcl is such a simple language[4], and homoiconic[5]. A joy to develop in and use.
[0] https://community.f5.com/kb/technicalarticles/irules-concept...
[1] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf
[2] https://www.acoustic.com/pdf/Acoustic-Experience-Analytics-%...
[3] https://docs.python.org/3/library/tkinter.html
[4] https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm
[5] https://stackoverflow.com/questions/6492704/what-exactly-doe...
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 rid of TCL, the better.
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 almost no thought given to edge cases. There was no culture of code review so nobody scrutinized your code to find out whether you were using Tcl in the right way or not. I'll grant, though very lightly, that Tcl has more accessible metaprogramming facilities than Python which makes it easier to misuse than Python. Similar to how Ruby in the hands of a undereducated/bad Ruby programmer is also quite gross.
But I had the same issues using Perl in the EDA industry. The conclusion I came to was that code standards were just abysmal in EDA because code was largely seen as a cost-center activity rather than a profit-center activity as the real output was the ETL or the device and not the code that went into it.
I re-learned Tcl when I was older and when my time in EDA was a faint memory and I found the language a joy. It was remarkably easy to get started in and really easy to build an application out of. This experience further made me reflect on how bad the code culture in EDA was.
So I'm curious what specifically you'd see the EDA industry move to and how you think it would fix the problems EDA currently has with Tcl. Python, is the successor I imagine? That said my actual time in EDA was very short so I welcome the opinion of an actual insider.
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.
> 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.
> 30 years of TCL here. It really is the worst.
If it's personal preference, than fine. But that doesn't make it a horrible language for all. I enjoy TCL and Perl and I'm 35.
I don't touch Python because I don't enjoy it. And I coded with it when it was in early 2.0x in 2003. I'd rather learn Java.
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.
Most likely for the same reason you found. Once you know it, it's very easy to use, and it's available in most distributions (if not all). So both familiarity with Tcl, while having that ability to build out quick and stable GUI tests, including the lack of churn in the GUI framework. For myself, having to readapt to a GUI framework when I'm just trying to get something visual up and running to make life slightly easier, makes something like Tk much more beneficial for just getting work done. A bit ugly, but anyone technically inclined will figure it out quickly, without constantly having to change up libraries. I only speak for myself and put my 2 cents in, I don't speak for anyone else, but for general tooling targeted at developers it seems perfect.
Both Richard Hipp and Salvatore Sanfillipo came out of the Tcl community. SQLite was originally just a Tcl extension (and may I say, SQLite's Tcl binding is a dream to use). In a nutshell, they were already using Tcl because they found it useful.
The Redis protocol reads a lot like Tcl code.
I think he also wrote an implementation of a tcl-like language called Jim.
No, that was by Steve Bennett.
Sorry no, antirez (Salvatore Sanfilippo) was the original author, Steve Bennett took over maintenance later - https://jim.tcl.tk/index.html/doc/www/www/about/ .
My bad; I'd forgotten about Salvatore's role. Steve Bennett is the one I saw present about it at the Tcl Conference some years back.
I used it a few times, mainly because of Freewrap. With very little code I was able to write a Windows app with GUI that I could distribute easily as an executable:
All these have a page or maybe two of code.Some time ago i was playing with a Raspberry Pi and wanted to write some code in there. The Gtk3-powered Geany was WAY too slow (like, type and wait for the letter to appear slow). I recompiled it to use Gtk2, it was much faster but also it was buggy (the code display was getting messed up).
Nedit (based on Motif) on the other hand was both very fast (faster than the Gtk2 Geany) and bug-free - it worked perfectly. But i wanted Geany because of the file browser sidebar.
So i wrote a small Tcl/Tk script to display a list of files using a filter in a directory and call Nedit to edit them when you doubleclicked. Also added a few buttons to call make, make clean, open a terminal, make a new file, etc and worked perfectly.
A few years since then i made a few improvements and modifications to this script and use it on my main PC whenever i want to work on C source code - though i use Krita instead of Nedit here (Krita has its own file browser sidebar but i find the way it works annoying - and doesn't have all the extra stuff i've added over time to the script).
The neat bit is that it reads a Tcl file from the home directory for "global" configuration (e.g. which editor to use, how to run terminal commands, etc) and then a Tcl file from the current directory for project-specific stuff, all of which having access to the main script's own procs for things like calling terminal commands, showing a few dialogs, etc.
I've uploaded the latest version of the script to my website a few days ago[0]. I've been mainly using it with Linux but a couple of years ago i also used it a bit with Windows using MSYS2 (with Notepad++ for the editor) and worked fine.
There is a screenshot on the site.
[0] http://runtimeterror.com/tools/projfiles/
Tk based GUIs work across pretty much all desktop platforms and are much less resource intensive than electron and friends.
Absolutely. It's even been remarkable stable--programs written 20 or 30 years ago work without any kind of modification.
Is Electron really considered a competitor to Tk based GUIs?
In my (limited) experience, Tcl/Tk is great for basic stuff but I don't think you could do even a small part of what you can do with an html + css + javascript GUI.
1. Tk can do a lot more than you think
2. I have seen very basic GUIs in electron just for the cross-platform nature of it.
It used to be the other way around. It’s been a while since I did much UI work, but the web always felt incredibly frustrating for layout compared to Tk. (I think CSS finally has something approaching Tk’s grid layout manager?) There are fewer frameworks for Tk, but I think it has most things you’d need. Maybe some of the finer control over fonts etc is lacking.
> most things you’d need
Say you wanted to write a CAD app like https://www.onshape.com. There’s no way you could do it Tcl/Tk, is there?
Most of what I'd call the UI - all the toolbars and pseudo-floating-windows - is basic bread-and-butter Tk stuff. The 3D context and CAD kernel would be the tricky bits. There are extensions floating around to work with OpenGL (or whatever), but I don't see doing the heavy CAD-kernel lifting in Tcl - that would likely have to be in C, or whatever. (Just as it presumably is for Onshape.)
You are correct. Having written such a thing, you do all your basic UI in Tcl/Tk and have a custom widget doing all OpenGL/whatever rendering. The rest of the code treats it as a canvas-like widget.
It's 2D only and Mac OS-specific, but there is:
https://github.com/revarbat/TkCAD
That's impressive!
I agree with you but a lot of the demand for GUI tools is small tools. Think something like Postman: it's really just a code editor widget to put in some request metadata and a table view storing requests. This is the kind of tool that something like Tcl would be great at and really doesn't need the sophistication of HTML+CSS+JS.
Quite common in space industry. It is the script language used in many (all?) SCOS-2000 based mission control systems. Yes, is is actually used to control satellites and spacecrafts.
I often use the tool that is closest to another tool I am using. The closeness may be due to a common heritage, both technical and cultural. A common thread between the two is often high quality, maturity, cross-fertilization, long-term commitment, etc.
Now when it comes to Tcl, I use it for the above reasons because it is so convenient for writing scripts to use SQLite. In other words, it is my go-to wrapper for many SQLite applications. This is mainly related to (rapid) prototyping use cases.
From https://sqlite.org/tclsqlite.html :
> The SQLite library is designed to be very easy to use from a Tcl or Tcl/Tk script. SQLite began as a Tcl extension and the primary test suite for SQLite is written in TCL. SQLite can be used with any programming language, but its connections to TCL run deep.
If there's any better relational database API, in any language, than SQLite's Tcl interface, I've not seen it yet. (And the reasons SQLite's Tcl interface is so good would either be hard to replicate without Tcl, hard to replicate without SQLite, or both.)
It has expect[1], a nice tool to automate terminal applications.
Two examples:
- Adding convenience features to the Cisco IOS CLI (e.g., ^D to exit).
- Implementing the back end of a native WPF Windows GUI application that downloads spooled print jobs from a third-party system that only provides remote spooler access through a full-screen interactive terminal application running over ssh. This application also makes use of another nice Tcl feature, its trivially-implemented remote protocol[2].
[1] https://core.tcl-lang.org/expect/index
[2] http://corex.tcl-lang.org/tcllib/doc/tcllib-1-18/embedded/ww...
When I had contact with TCL for a networking class in the 90's I already knew Python and didn't like that "everthing is a string" pathos.
For me the greatest TCL contribution was Ousterhout's dichotomy: https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy or by the author himself: https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pd...
>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.
For a long time it was the only way to get a decent IRC bot going, because eggdrop[0] was a Tcl wrapper around a small C core, but the only place I've seen it in the wild other than IRC bots was in the Xilinx toolchain and once when I was in undergrad some TA was using it to get telemetry from Tektronix oscilloscopes in the robotics lab.
[0] https://www.eggheads.org/
Last use I remember seeing for it was in scripting Intel FPGAs
https://www.intel.com/content/www/us/en/docs/programmable/68...
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.
> It is really hard to describe just how much better Tk was than anything else in the time frame.
This[0] vs (from memory w/o a computer atm…):
[0] https://users.cs.cf.ac.uk/Dave.Marshall/X_lecture/node5.html...======
-command instead of -action, but otherwise perfect! :)
I also used the wrong path for /usr/bin/env ;)
> 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.
Lua?
It's used in (and used for?) a lot of embedding:
* https://en.wikipedia.org/wiki/Lua_(programming_language)
Tcl was 1988. Lua was 1993.
Lua is quite a bit larger than Tcl. In addition, no two Lua installations can ever agree on which modules they require (which makes the actual Lua binary even bigger).
Larger? On my system libtcl8.6.so is 1.7 megabytes and liblua5.1.so is 192 kilobytes. It's not even close. Lua uses libraries / modules based on where you tell the interpreter they are located, so that's on you.
Set package.path and package.cpath correctly.
You are comparing 2024 versions.
Go find the original tarball versions from 1990 (maybe you have to go to Usenet sources!). Tcl was small.
Ah, you used "is" and not "was" in your original post.
I wonder if TCL 2.1 will compile with modern gcc?
That would probably be painful. It's old-style C.
Better to start with Jim Tcl or Picol.
Even something like Tiny Tcl would be a better start (I think it fit in 64K).
HyperCard existed.
Big missed opportunity for Tcl was the lack of a solid version of Tk for classic Mac (30 years ago). Would have made early Python less essential.
Tk was pretty usable for tcl/tk use cases on Mac by later 7.x releases, say 1996 or so. Still hard to get a really native UX on Windows or Mac though. HyperCard was already on its way out. 30 years ago is maybe closer than you think?
That's what it was created for, believe it or not. And it's been used there since the early '90s; there were very few other embeddable scripting languages at the time, so it caught on quickly.
Back in the late 90's we used it on our startup, several of companies at the time were trying the luck on Tcl based application servers, AOLServer being the most well known.
There was Vignette, and we at Intervento had our Safelayer product, loosely based on AOLServer.
Apache and IIS plugins for hosting Tcl interpreter, running on Aix, HP-UX, Solaris, Red-Hat Linux, Windows 2000/NT, with support for Oracle, Informix, DB2, Sybase SQL Server, Microsoft SQL Server, Access (only for test purposes).
Development environment was based on Emacs, eventually there was one written in Visual Basic specifically for the product, with project templates and other kinds of goodies.
However we eventually hit the limits of using Tcl, and having to rewrite parts of the platform in C.
As it was, being a gold MSFT partner gave us access to .NET before it was announced to the world, and a plan to rewrite our product into C# took place.
With the learnings of these experiences, and customisations done at client sites, the founders eventually moved on and created one of the best products for no code development still going strong nowadays, OutSystems.
Never used Tcl again since those days.
AOLServer (now Naviserver again) is still the base for the largest open-source project management system: ]project-open[ (https://www.project-open.com/)
Interesting, didn't expect it to still be around.
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:
This is a great list.
> * Safe interpreters let you do very fun things like config files in Tcl with limited access to the machine and master interpreter.
I keep looking for similar functionality in Python (the scripting language of choice for many, nowadays) but I am always disappointed.
The python-esque sandboxed language is Starlark: https://github.com/google/starlark-go#documentation
Lua is another language that lets you do this!
>refcounting does the job since no cycles are possible by design
So double-linked list is impossible to define?
Rosetta Code has examples of DBLs in Tcl and Tcl::OO.
You can't define new data structures as such in pure Tcl, as you don't have pointers. And as for cycles, you can't modify an object to add a reference to itself, since the copy-on-write will just create a new object.
Sold. I know what I'm doing this weekend.
For the few interested people, took the time to make a final version in Markdown with lots of links and some improvements/proofreading: https://gist.github.com/q3cpma/a0ceb6a7c6a7317c49704630d69b7...
Hey, you missed out coroutines :-)
Indeed the backing implementation /generalization, stackless non-recursive engine (NRE)[0], developed by Miguel Sofer (RIP).
[0] https://wiki.tcl-lang.org/page/NRE
I did, and I also missed coroinject/coroprobe being new in 9.0 (from the full release notes). Seems like a delightful new way to blow minds.
Eggdrop IRC bots. Even 25 years since I first created one, Eggdrop is still the best and most reliable + flexible IRC bot platform, and comes with native support for Tcl.
I use it to write long running little scripts. It's better than shell, and imo more useful out of the box than Lua. They are basically for I/O (often using sqlite which it has great integration with, or using expect which is also great) so I don't care about performance, but I like that it requires much less memory compared to say Python for that kind of little things (there is also jimtcl which is also neat in this regard).
I use it for "expect" because it just works.
Same. I learned Tcl recently for /usr/bin/expect. I wasn't happy to be forced into using yet another esoteric language, but Tcl itself is strangely fun: it's like a more expressive and functional Lua.
Ha, I was in the same position. It's fantastic at scripting serial consoles.
Oddly enough, Lua is also near and dear to my heart. It's a great language to embed to allow non C or C++ folks the ability to extend software or to do so dynamically.
Curious as well. The only time I've seen it used in the wild is Redis' test suite. https://github.com/redis/redis/tree/unstable/tests/integrati...
The only reason to use it today is because you're forced to by the EDA industry. Otherwise there are far far better options.
That also means this release is basically irrelevant for the next 10 years because that's about how long it takes the EDA vendors to update their bundled TCL versions.
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.
I "get" TCL - it's a neat hack. Arguably even an elegant hack. I can see how it would be fun to play with, in the same way that BASIC was.
But most of my work isn't playing and I don't want it to be built on hacks.
> Anybody using it for something else and can speak to why you’d use it today?
It was often used as an embedded language (e.g., in F5 load balancers), especially in the pre-Lua days.
I used it a few weeks ago to fetch and display access timing histograms in an FPGA project.
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.
A theming engine went in something like 15 years ago now; the default theme looks rather dated, but there are plenty of others. See https://wiki.tcl-lang.org/page/List+of+ttk+Themes (though the screenshots of core themes are from 8.5/8.6 - default in particular has changed a bit in Tk 9).
The "catch" is that the theming engine has its own new widgets, and so to be themed an application has to use the new API. Code from 1995 (or 2005) still produces GUIs from 1995.
Those are TK? They look good!
Yeah, they added that a long time ago, but it's not at all the same as built-in support. My experience was trying out fragile third-party projects with little or no documentation. The whole point of using Tcl/Tk for writing a GUI was the convenience.
Things may have changed over time. I no longer pay attention. Maybe I'll give it another try.
The theming engine is absolutely "built-in", as are a handful of themes; in particular aqua and the winnative/xpnative/vistanative family (which integrate with the Mac/Windows windowing system such that the application will look "native" by default on those systems).
> which integrate with the Mac/Windows windowing system such that the application will look "native" by default on those systems
That's my point. You can make an app that looks okay on those OSes, but all of the built-in options for Linux look ridiculous, and then you're back to the third-party stuff.
I don't think clam looks "ridiculous", but I suppose we're in to subjective stuff now. :)
In principle this isn't really any different from GTK or Qt theming (where it's up to users to go forth and find themes they like, and set the default as desired), but in those cases you tend to get themes packaged up by distributions and GUI configuration support from desktop environments, and neither seems likely to happen for Tk.
Reminds me of using Tkinter with Python, while learning Python. There are other GUIs available, but finding examples of working code with a newer GUI is going to be more troublesome (but not impossible). I think it's just that the documentation has been centered around Tk(inter) for so long, most people just choose it as a default. I know Python has gotten better about GUI support (probably from the popularity in machine learning/AI usage), but with Tcl being less popular, you need to do some due diligence to find up to date documentation on modern GUI usage.
I recently asked HN if Tcl is still relevant in 2024 https://news.ycombinator.com/item?id=41108667
Nice to see a new release coming out not too long after such a question :)
Why are they still on SourceForge? To me, SourceForge feels like one of those scammy download sites that installs spyware.
Sourceforge still works, and is (now) reliable. The awful DevShare malware stuff that Sourceforge started (under new ownership) in 2012 was stopped (under different new ownership) in 2016.
The site is ugly and difficult to navigate. Go there and enter TCL in the search box and see how many clicks you have to do to actually find the project. Then when you click the download button a timer has to run out before the download will start.
Maybe it technically works, but it's a terrible UX.
"Ugly and difficult to navigate" and "terrible UX" are a completely different thing than "scammy download sites that installs spyware".
Why did you omit the "feels like one of those" from the text you quote?
They mirror to Github.
https://github.com/tcltk/tcl
Wow Tcl is still a thing? Takes me back to university days — and even 20 years ago it was considered a bit of a poor man’s UX. I’m off to read the article and see if it’s any better these days…
Love reading this. I spent a few years in the late 90s using Tcl/Tk to build cross-platform installers for Embedded tools/libraries, along with Expect for a bunch of our testing. One of those pragmatic toolsets for getting sh*t done.
In the realm of Electronic Design Automation (EDA), TCL is ubiquitous. Virtually every EDA tool offers a TCL interface or API, making it the predominant language for tool configuration. I've always wondered why TCL hasn't gained traction in other domains. It possesses the elegance of Lisp while maintaining practicality.
Great to see all the love for TCL here :) Too bad it's not more popular really but even I struggle to find cases where I'd prefer it. Usually it come down to bash for simple stuff and python everything else.
I’ve recently discovered Tcl and absolutely love it! It’s such a fun language.
The starpacks/starkits for packaging apps together are really nice.
For anyone interested there’s a fork of the Tcl Dev Kit at: https://github.com/bandoti/tdk
This allows one to package applications with shared libraries and all bundled together.
Not those scenarios, but I think it still has potential to take place of embedded scripting languages like Lua, if it can keep up of course.
It would be nice if the releases were cryptographically signed. I've never used Tcl/Tk before but I just downloaded the 9.0 release and I'll give it a go.
Outstanding! I know a lot of work has gone into this release. Kudos to the TCT.
I know of Tcl but I don’t know anything about its structure. The number one thing I ask of a language is consistency: the minimal amount of magic and most of the language implemented in itself. Ruby almost got there and then, for me, slipped up on class << self.
How does Tcl fare under these criteria?
The Tcl language is made up of commands; a command has a name and takes an argument list, with which it can do literally anything. The standard commands are written in C; Tcl `procs` are commands that are written in Tcl. The control structures, like `if` and `foreach` and `while` is just a Tcl command. The `proc` command that defines a proc is just a Tcl command.
I think of it as Lisp for C programmers.
So: is the language implemented mostly in itself? No, it's mostly implemented in C. Is there a minimal amount of magic? No; the amount of magic you can do is effectively unlimited.
> Is there a minimal amount of magic? No; the amount of magic you can do is effectively unlimited.
I might be mistaken, but I think the OP was asking if there is surprising magic (I.e. special cases/considerations) built into the language, in which case I’d say, “No, Tcl is not “magical”, but surprisingly simple and regular.” That said, indeed it’s powerful in its application of its primitives, but you do still need to mind some things (don’t pretend* you can quote better than the quoting engine, don’t pretend* you can do lists better than the list processor, …). Not magical though - very understandable.
*rules are meant to be broken, blah, blah, but the “gotchas” are new practitioners falling into this, or advanced cases, falling into this…
In that sense, yes, very little magic...enabling vast conjurations. :-)
> The Tcl language is made up of commands
As someone that is stubbornly trying to design a Smalltalk-Forth hybrid syntax, where everything is words, nay, messages in a declarative/concatenative pipeline, without success, reading this makes me inappropriately giddy.
I need to learn Tcl.
It's also absurdly easy to integrate into C or C++ projects, or to write an extension in C or C++ which can be loaded to implement new commands.
Thanks for this explanation. It was very helpful. In terms of magic I meant it simply as how big is the set of unchangeable axioms, as opposed to how many things are derived in the language itself from a more minimal set of magical axioms. With Lisp being the language with the least magic lisp for C programmers was insightful!
Ah! Here's the set of axioms: the Tcl Dodekalogue. https://wiki.tcl-lang.org/page/Dodekalogue?R=0&O=Dodecalogue...
Brilliant. That wiki is quite something. Getting a real sense of the core of the language is within easy reach.
Tcl's magic is mainly from uplevel and upvar as they allow you to do crazy stuff with the callstack to enable all kinds of metaprogramming. It's not a lot of magic, but it's very powerful.
It's a lot of magic. New control structures mean dsls are as easy as thinking about them
Tcl is incredibly consistent, because it's homoiconic.
Tcl/tk Wayland support when?
I’m looking forward to installing this and having a play. Looks great
Tcl remains to be the king scripting language in chip design ecosystem
Also useful if you want to do microprocessor debugging.
OpenOCD is scriptable/configurable using a small variant of TCL called JimTcl.
https://openocd.org
https://jim.tcl.tk/index.html/doc/www/www/index.html
Are there any good tcl web frameworks ?
~~A very famous(? infamous?) one: https://github.com/aolserver/aolserver#readme~~
sorry, https://news.ycombinator.com/item?id=41663259 does a much better job answering than my link
Awesome! Can’t wait to play with this some more tomorrow. TCL looks like a fun language for my hobby projects.
Rivet (https://tcl.apache.org/rivet/) may also be of interest.
Indeed thank you
Nice. `gitk` could be better.
It’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 .
That tcl wiki is actually a fossil instance iirc - the VCS the Richard hipp evangelizes.
Anyone know if any new projects are using Tcl? Surprised they went with this
Some people like Tcl and use it, some people don't. The Tcl Wiki sees a regular stream of updates - https://wiki.tcl-lang.org/recent . Personally I'm working on a Usenet/Web gateway which does web serving, NNTP, caching in Redis, user db in sqlite, all implemented in Tcl - https://cmacleod.me.uk/ng .
Courtesy of kicking the tires on your app, I discovered: https://github.com/apnadkarni/tcl9-migrate#migration-tool-fo... (via https://cmacleod.me.uk/ng/comp.lang.tcl/67166 )
and "EuroTcl 2024 - presentation videos and slides now online" https://openacs.org/conf2024/info/schedule (via https://cmacleod.me.uk/ng/comp.lang.tcl/67134 )
is tcl relevant beyond maintenance of existing legacy projects?
[flagged]