TclSqueak – IDE for Tcl | Hacker News Reader

TclSqueak – IDE for Tcl

xdobry.de

78 pointsdmux40 comments

Open articleView on HN

I looked at the screenshot and thought "that's a nice, warm, fuzzy reminder of the late 90s state of the art."

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/

The IDE you linked to seems to be proprietary software.

I'm aware that it's proprietary. I thought it was also available gratis for individual developers.

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.

I don't feel that's right.

It's a small project that hasn't seen a commit since 2015:

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.

Komodo Edit, though, is free software.

https://github.com/Komodo/KomodoEdit

This is not cheap.

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.

It might not be cheap, but is it a good value for you? How many hours of your time would it have to save before it paid for itself?

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.

For what they were trying to do in 2015 (last release) it probably was.

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)

As far as I can tell, LSP can't even distinguish between a read and a write — it's not as useful as cscope 30 years ago.

This looks like a delightful environment. I'm going to put it on my list of things to try out.

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.

My accounting system is written in Tk/TCL. Works well.

what is it?

In science, NAMD, one of the most popular molecular dynamics simulation packages, and VMD, a molecular visualization tool are scripted in TCL.

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 might exasperate the users, but it exacerbates 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.

> implement it (or a cut-down version) on GraalVM

I encourage you to do this.

MacPorts is all 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.

If you need to create a performant gui app for something very fast, it is no match.

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.

> You need to write it with what python provides to stay unified.

Like TkInter, which uses tcl/tk?

Does the OS shipped with Cisco networking equipment still have a tcl interpreter?

It works just fine for web-backend development.

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:

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.

Last commit was 5 years ago...

It must have reached perfection.

In what way the "inspired by Smalltalk programming environments" makes it different than other development environments?

My guess is the UI. It looks very much like the class browser you'd find in a Smalltalk environment.

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.

I suggest writing extensions for vscode to provide tcl language server and debug server.

VScode seems like the MVP of IDEs to add support to. I'd go for community IDEA

Reply on news.ycombinator.com