If you want to play with reading/recreating a very small Tcl interpreter, recently I put Picol (a 500 lines of C code Tcl interpreter) on Github. It was still on the web, but a bit more "hidden". I had a chance to re-read the code, and it is not in the category of code I regret writing :D Still relatively useful for newcomers, I hope.

https://github.com/antirez/picol

Thanks for that effort. Some time ago, I got Picol working on an Arduino-compatible microcontroller board with minimal effort. I was working towards making my own programmable calculator, and test-drove a number of simple interpreters, including yours and a couple others.

Project languished due to my attention span running out, but I still have my adaptations of those codes on my drive, in case I ever pick it up again.

The once-ubiquitous open-source package manager for macOS, MacPorts, is basically a Tcl app.

That is to say, its packages are Tcl.

I haven't used it in many years, as is has been largely replaced by Homebrew, which uses Ruby.

(I once maintained a MacOS port of a good-sized scientific analysis package. Hundreds of MacPorts packages, I have debugged.)

https://www.macports.org/

In the 1990s, an awful lot of Linux apps were Tk/Tcl. People complained then about them not being "native", but they were slimmer and better performing than the typical Java or Electron app of today.

It’s only because TK was so butt-ugly

I don't think homebrew has replaced MacPorts. I suspect that MacPorts has more ports.

MacPorts has far more packages than Homebrew and was implemented by the creator of the original FreeBSD ports system, who was also an employee on Apple’s UNIX team. MacPorts is the standard macOS package manager.

> MacPorts is the standard macOS package manager.

No, it's not. macOS does not have a standard package manager.

What do you mean by “standard”?

I like MacPorts, but most macOS using developers I’ve conversed with over the past 12+ years never heard of it, while all of them used Homebrew. Maybe it depends on what developer circles one inhabits.

I have only ever used macports, but my first and only MacBook was salvaged from bigcorp IT, and is a 2009 model so homebrew is too new for it.

I’ve dabbled in BSD before and I can definitely see the correspondence between Macports and freeBSD ports. I assume homebrew tries to be more similar to apt or yum.

Yes, one of several nice things about MacPorts is the continued support for older macs, macOS/OSX versions.

Just a play on “ed is the standard text editor”.

But, by all measures, MacPorts is more standard than Homebrew. Such as being implemented by an Apple employee who also created the official (source-based) package manager for the most popular BSD.

Homebrew definitely has a lot more market share though, much to my chagrin. The only other MacPorts users I’ve met in person are people I convinced to switch.

I like Tcl a lot, especially the Expect module. If you've ever wanted an Autohotkey for your terminal (I promise that phrase actually makes sense) it's well worth your time to look into either Expect itself or Python's `pexpect` module.

I love Expect.

Package owner: "These configuration choices are so important that a human must be present at the keyboard every time, without exception. Woe would befall us all were the will of the ancients ignored. So it was written, so it shall be done."

Me: "Yeah, nah."

Expect was born out of TCL, and its original syntax worked really well with TCL's.

Its popularity led it to being ported to other languages, Perl & Python being the big ones, but TCL Expect is the og

SQLite has the same origin story. (That's the reason for SQLite's confusing type system: it makes perfect sense as a Tcl type system.)

Expect is an automation framework. Automating tests is just one use for it.

Nice, a TCL post!

I use TCL often (forced to) since it's Cloverleaf Integration Engine's official scripting language and it works very well, but it is different from other languages in that its syntax is not modern, though, it's not difficult to learn if you really need to.

It's an older language that's fallen out of favor mostly for other scripting languages (Javascript, Python, etc) and understandably so. I'm by no means an TCL, but do consider myself an expert when using it with Cloverleaf.

Thanks!

Wait, didn't Tcl/TK 9 just launch?

https://www.tcl-lang.com/software/tcltk/9.0.html

Any word on a nice binary release of it?

it's worth noting for those unfamiliar, tcl/tk 8.0 came out in 1997. So this isn't a normal thing, this is a 27 years in the making kind of thing.

Yeah, I just wish there was a nice/supported/reasonably capable GUI designer.... (and I'd love to be directed to one, having been unsuccessful in searching for one).

There are quite a few half finished GUI designers for it but I suspect they all remain half finished because the people who start in on them realize that such a tool will not get Tcl/Tk onto the level of QT or GTK and fights against what makes Tcl/Tk such a great tool. It is not about slick and highly refined UIs, it is about quickly and easily making functional UIs. You learn the sense and quirks of pack and grid and for applications which those simple containers work well for, nothing will be as fast or as easy as Tcl/Tk despite the lack of a GUI designer. Tcl/Tk is not for big complex UIs, it can do them but generally you will be better served by other toolkits for those.

tkcon gets you reasonably close to a GUI designer, it is text mode but instantaneous, and quite simple to configure the widgets to allow you to configure them with your mouse if you really want to do that.

https://github.com/wjoye/tkcon

I haven't used TCL in a few decades and I don't miss it, but that is likely due to running it on storyserver. Worst web platform ever.

Tcl offers a unique combination of embeddability and power, often underappreciated outside specific domains. While its general-purpose usage might be less prominent, its dominance in Electronic Design Automation (EDA) is undeniable.

I skipped Tcl in favor of Perl. Is there any reason to reconsider nowadays?

Tcl is more-or-less required if you're involved with the physical design of silicon (most EDA tools only provide a Tcl interface). It's a good fit for that purpose. If you need a language which is easy to embed and you want non-programmers to be able to use it, Tcl is a good choice, though I've heard that Lua has supplanted Tcl for that purpose.

That's been my job for the last 30 years.

Our flow is thousands of lines of Tcl code around all the cadence and synopsys tools. Then we write more Tcl to create the power grid, create blockages, etc.

In the silicon industry it’s definitely tcl only. Zero Lua. But every tcl script I have seen is extremely simple, often just a bunch of commands to the EDA tool that reads like a list of bash commands.

Tcl scripting gets more interesting when you want to talk to a design running in an FPGA over JTAG. I have a toy CPU project which I've so far tested on Altera/Intel, Xilinx and Lattice FPGAs, and a debug interface where a C-based ncurses debugger connects over TCP/IP to a Tcl bridge which talks to the appropriate JTAG interface for the particular type of chip.

I'm also a big fan of the full-fat Tk-capable Tcl in Altera's SignalTap / Virtual JTAG - I used it recently to plot histograms on-demand for profiling RAM / Cache accesses.

I'd say python starts to make some strides, likely due to the AI hype train. But it's still mostly Tcl.

I dropped Perl for TCL decades ago, after I realized that I could read and understand my TCL code months after I’d written it, but my Perl code was totally opaque.

I first encountered Tcl when trying to use the hideous network simulator, ns2. Any language that lends itself to such code can't be good, I thought, and stayed clear of it ever since.

https://www.isi.edu/websites/nsnam/ns/

I like both Perl and TCL. If I need an executable for Windows, I choose TCL, because I can easily make one with freewrap.

Perl and Python have a myriad of similar tools that work well with projects with no dynamic imports.

I remember such wrappers for Perl and even for PHP.

TCL is embeddable (in another program). In fact that's how it started.

That means it's a good language to extend your program. I don't know how it compares to Lua, which seems to have replaced it in that space.

I like TCL a lot more for this use case, and I don’t care for Lua at all; but Lua might be a better match for embedding in an OO language.

Lua is simple to bolt on to your project.

Perl is a nightmare to interop! They should have won an award for that. It took effort.

Python is slightly cleaner than perl, but not much.

You mean, the interpreter is available as a library with bindings in many languages?

But then - isn't that the case for other scripting languages these days? Or are they too complex and with "strings attached"?

I can't speak for other scripting languages, but it's absurdly easy both to embed Tcl as an interpreter in a larger project, and to create a Tcl extension which implements your own commands.

One can leverage Lua in PHP, I think it's handy for user-supplied logic (eg: business rules)

Looks like this post I made can serve again: https://world-playground-deceit.net/blog/2024/10/why-tcl.htm...

But to be honest, while I feel like Perl has a lot of advantages (full perlre, full access to POSIX APIs, slightly better performance), I still can't look at it and keep my last meal down. Tcl having an event loop and Tk being native are pretty nice too.

You mention Tcl’s lack of language server support - just a shameless plug for my own project that’s working on fixing this: https://github.com/nmoroze/tclint/blob/main/docs/lsp.md

It’s not quite “complete” with respect to all the usual LSP features (just does linting and formatting for now), but it’s a starting point!

I don't use language servers myself personally but wanted to give you a kudos for attempting something.