What's the use case of TCL nowadays? I thought the language was fading out due to emergence of alternatives like Lua and Python, despite how much I love it.
I think almost every FPGA vendor development tool has integrated tcl support which is basically the standard for scripting in that industry. Vender lock-in exasperates the trend.
It's still lighter and easier to embed than Python. Lua has sort of displaced it for "script" files but not so much for "config" files, as artificial as that distinction is; also I'm not sure how much Lua has caught on as an interactive embedded prompt. And in any case a lot of existing systems feel no need to migrate.
And honestly it's still a pretty nice language, as much as I've mostly lost interest in untyped languages. I've been thinking about trying to implement it (or a cut-down version) on GraalVM.
So actually this is one thing I found when embedding Lua recently in a project was that it doesn't really have a REPL. There's projects to add one, but it is not as eval-loop friendly as a scheme or a Tcl.
Because of the inherent "everything is s String" mantra tcl/tk is to this day by far the best language to rapidly build GUI front ends for CLI applications (which generally spit out strings to stdout).
In our company I recently ported some of the MS Access databases to sqlite + tcl/tk as a side project which turned out to be a great decision. Much higher reliability, productivity and finally versioning with git.
I was impressed how quickly you can put together a GUI with tcl/tk. And they look really great on Windows and Mac. The default "Motiv" style look on Linux looks kind of dated though.
HUGE use in really niche spaces. FPGA development uses it because of really embedable/flexible syntax, and a lot of software integration testing uses it for things like Expect (whose Tcl implementation is still far and away the best).
TCL was the language used with F5's BigIP for writing custom rules on their load balancer. I' haven't used BigIP in years, so I'm not sure if they still do.
This was the last big thing I wrote in TCL and I still use it to this day:
TCL is a neat language, but these days if I need scripts, I'll usually turn to python or ruby, plus they have a lot of libraries and packages. Like others have said, it's used in a lot of stuff where you need to embed a scripting language for extensions, similar to Lua.
In a thread about a free software IDE for Tcl, which might mean a lot of exposure for what seems like a small project, you write what amounts to how you don't like the look of it and promote a proprietary alternative.
Dormant projects do not really benefit from exposure.
I also didn't say I don't like the look. Quite the opposite. It is a late 90s early 00s kind of look that I personally find appealing. I wouldn't call it "modern" however.
I thought they'd made it available free-of-charge now. (That's the only reason I mentioned it here.)
That said, the only times anyone has ever asked me to work on large enough projects involving Tcl that I care if I have an IDE, I've been integrating very expensive, very proprietary software. I don't enjoy that work, my fees for that are high, and no one's ever flinched at the cost of the IDE in that context.
I looked at both screenshots, and aside from the dark theme, it's not clear how the Komodo screenshot is different. They both show a bunch of windows that presumably allow you to navigate files and classes, and the code window offers syntax highlighting. Sure, the window style is different, and the fonts too; there's more color in the non-coding windows on the Komodo side. All right, design-wise the Komodo screenshot feels more modern.
However, my take on "modern" is that the authors of the TclSqueek were thinking more at function than form. I can't speak about that one with first hand experience, but I talked with Smalltalk developers, and they think the Smalltalk environment is still unmatched. If that is the target that TclSqueek tries to emulate, then it is "modern".
Fair enough. It screams pre OS X NextStep to me, which is probably very much related to that.
Chrome aside, the non-modern thing that jumps out at me is that you likely have a few more windows/dialogs/palettes/etc. you're working with in TclSqueak, where Komodo adopts a pattern of decorations on the side of a single window that cause additional panes to appear within that same window as you click them.
I don't especially like that specific turn we've taken over the past 10 years or so, but that pattern of revealing hidden bits within one big window sticks out quite a bit even beyond the chrome to me.
I'm of the opinion no one should be writing new IDEs anymore for languages and should instead be writing good language servers for the language server protocol (and it's debugging friends). The duplication of effort for each IDE + language pair is just too large.
This creates an issue where the LSP is the bottleneck between what the language can express and what functionality the IDE can provide.
For example there is absolutely no way anything based on LSP can provide the same level of integration as what Lazarus has for Free Pascal and its LCL framework.
(also LSP essentially working by running a server locally that has to parse and emit JSON messages and an editor that also has to connect to a local server and parse and emit JSON messages is not exactly ideal when you care about keeping things simple and performant)
Nearly everything in Tcl can be inspected at runtime: the source code for procedures (and their arguments), classes that have been defined, methods, etc. Tcl can be made to appear as if it was "image" based rather than file based. This project taps into that.
40 comments
[ 2.8 ms ] story [ 93.9 ms ] threadAnd honestly it's still a pretty nice language, as much as I've mostly lost interest in untyped languages. I've been thinking about trying to implement it (or a cut-down version) on GraalVM.
I encourage you to do this.
In our company I recently ported some of the MS Access databases to sqlite + tcl/tk as a side project which turned out to be a great decision. Much higher reliability, productivity and finally versioning with git. I was impressed how quickly you can put together a GUI with tcl/tk. And they look really great on Windows and Mac. The default "Motiv" style look on Linux looks kind of dated though.
It is unfortunate that it has not been embraced by the scientific community.
The only benefit of Python + (random) gui layer is that you write something in python and you need to also provide gui.
You need to write it with what python provides to stay unified.
But that is the only benefit.
Like TkInter, which uses tcl/tk?
This was the last big thing I wrote in TCL and I still use it to this day:
https://battlepenguin.com/tech/scripts/lnsponge/
TCL is a neat language, but these days if I need scripts, I'll usually turn to python or ruby, plus they have a lot of libraries and packages. Like others have said, it's used in a lot of stuff where you need to embed a scripting language for extensions, similar to Lua.
Then I scrolled down and saw the first bullet: "modern UI"
I don't do much with tcl, but if I wanted an IDE for it that felt modern, I'd probably look at Komodo first:
https://www.activestate.com/products/komodo-ide/
I don't feel that's right.
https://github.com/xdobry/tclsqueak/commits/master
Dormant projects do not really benefit from exposure.
I also didn't say I don't like the look. Quite the opposite. It is a late 90s early 00s kind of look that I personally find appealing. I wouldn't call it "modern" however.
Sorry you don't feel that's right, though.
https://github.com/Komodo/KomodoEdit
That said, the only times anyone has ever asked me to work on large enough projects involving Tcl that I care if I have an IDE, I've been integrating very expensive, very proprietary software. I don't enjoy that work, my fees for that are high, and no one's ever flinched at the cost of the IDE in that context.
However, my take on "modern" is that the authors of the TclSqueek were thinking more at function than form. I can't speak about that one with first hand experience, but I talked with Smalltalk developers, and they think the Smalltalk environment is still unmatched. If that is the target that TclSqueek tries to emulate, then it is "modern".
Chrome aside, the non-modern thing that jumps out at me is that you likely have a few more windows/dialogs/palettes/etc. you're working with in TclSqueak, where Komodo adopts a pattern of decorations on the side of a single window that cause additional panes to appear within that same window as you click them.
I don't especially like that specific turn we've taken over the past 10 years or so, but that pattern of revealing hidden bits within one big window sticks out quite a bit even beyond the chrome to me.
For example there is absolutely no way anything based on LSP can provide the same level of integration as what Lazarus has for Free Pascal and its LCL framework.
(also LSP essentially working by running a server locally that has to parse and emit JSON messages and an editor that also has to connect to a local server and parse and emit JSON messages is not exactly ideal when you care about keeping things simple and performant)