I've only played briefly with it some years ago on a Linux installation but one thing that i found neat was that unlike something Visual Basic or Delphi (which were clear inspirations - i think this screenshot[0] with the entire UI makes it a bit more obvious than the windows in the linked site) is that it is a "live" environment (pretty much like tclsh and wish) you are working with (kinda like a Smalltalk, though probably not to the same extent).

(though FWIW classic VB is a sort of in-between because you are editing the actual forms and state you'd see running - which is most likely why you can't edit a form while the program is running and the IDE even "hides" them - but there is an intentional distinction between "running" and "editing")

[0] https://a.fsdn.com/con/app/proj/vtcl/screenshots/49571.jpg

>kinda like a Smalltalk

This may be of interest if you find the idea of a live Tcl environment interesting: https://news.ycombinator.com/item?id=22852484

> FWIW classic VB is a sort of in-between because you are editing the actual forms and state you'd see running

VB could be a little weird in that respect. This screenshot of 1.0 has a clue about why:

https://winworldpc.com/screenshot/40c3942c-c281-2230-11c3-a4...

The timer control in the toolbar (left column, second from the bottom) is an example of a control you could drag over into the 'form editor', give a location, but was totally invisible at runtime. All it did was provide a hook for timer events.

This pattern turned into something common, at least in early VB. The extension mechanism for the language was defined in terms of VBX custom controls - which were intended to be visual controls that showed up on screen. The model worked well as long as that assumption held true, but VBX was also turned into an ad hoc mechanism for everything else.

The net of this was that you often had a form editor showing a bunch of totally-non-graphical VBX controls that would do things like send mail, interact with a PBX, whatever else.

Rolling back from this mess was a bit part of the impetus for the way OLE/COM 2.0 was designed, specifically OCX controls and IDispatch.

Delphi continued in that manner - You could have all kinds of visual controls, including FTP clients, that you'd visually add to a form etc. - but they were also possible to instantiate from code.

I didn't use it as much, but my recollection is of Delphi being a much more coherent product than VB ever was. This probably stems naturally from the way the two products came into being.

Delphi evolved from a compiler with full access to the underlying Windows API, with a GUI builder and framework layered on top. Drag a control into a form, and it was fairly easy to see the code behind it down to the layer of the Win32 API itself.

In contract, VB started out as a point and click builder for custom Program Manager like tools, and then had MS Basic attached. You could drag a control into a form, but then there was a very clear delineation between the code you could write as a VB developer and the hidden, opaque code provided by VB itself.

Yeah though FWIW Delphi was also a much more intimidating product to get into while VB was like a drawing program where you draw a GUI (there is even a color palette!) instead of a picture and then put some bit of logic - the IDE even tried to avoid intimidating you via your own code by only showing a single routine at a time.

Though Delphi's components were always meant to be for both visual and non-visual uses (TControl, from which other visual controls descent, is just a subclass of TComponent).

This was still often done in later VB. The Internet Transfer Control was often used by VB and VBA programmers to give their applications HTTP and FTP capability.

What VB should have done was have an optional "utility band" or the like on a screen on which to place the invisible widgets.

> Exports Tclets which run in Netscape/MSIE. You must have the Tcl Plugin to see the Tclets.

Not sure the Tcl Plugin would still run anywhere, which is a shame

I assume the plugin is just running Tcl/Tk inside a browser window.

I wonder how hard it would be to recreate the same idea using Emscripten drawing to a HTML canvas?

People have gotten Tcl to work on Emscripten [0]. I think the big problem is the Tk part. Tk has X11, Win32 and macOS backends, but emscripten supports SDL, for which there is no Tk backend.

[0] https://github.com/aidanhs/emtcl

The Projected Tk project aims to recreate Tk with a pluggable backend structure, with a web browser backend one goal.

https://chiselapp.com/user/gwlester/repository/PTK/home

There is an SDL backend for Tk but it's not part of the normal distribution:

http://androwish.org/home/home

I think Chrome dropped support recently too..

Would be a nice weekend hack to create a Tclet "plugin" for WASM. The Tcl interpreter itself is extremely easy to port to exotic platforms, only problem might be APIs that wrap underlying operating system APIs, those would need to be emulated on top of browser APIs.

We used this back in the day to make a touchscreen PoS application. It was great as you can switch from running state to dev state without any friction. We quickly went from nothing to production because of visualtcl.

A lot of EDA (Electronic Design Automation CAD tools for the semiconductor industry) tools use Tcl as the built in scripting language. Because of that many companies have built their CAD flows around Tcl so that it integrates with the tools from Cadence and Synopsys.

I'm trying to compile SQLite from source, which requires Tcl.

I'm getting many errors in what should be a "vanilla", hassle-free, off-the-shelf process. The 32-bit Tcl test suite fails with cryptic unresolved externals, whereas the 64-bit build only fails one test.

As far as I know, it's not a hard dependency. I believe if you just build from the autoconf download after deleting the tclsqlite.c file it works fine.

Back in the day Active State also had similar tooling support on their Tcl IDE.

https://www.activestate.com/products/tcl/

The products from Active State were my choice of love before Sublime Text got popular. They had a very good workflow in my opinion. Only downside was the performance of the IDE, but still way better then Ecplise.

I once used Tcl/Tk and am glad to see it’s still out there.

I’ve recently thought of using it again for fun.

I’m constantly amazed, but shouldn’t be, at how things like Tcl/Tk, that are used by various businesses to create applications, don’t take off into the mainstream.

I think about all of the effort today on the web using JavaScript. That’s using a language that could hardly do anything 25 years ago. But it wasn’t OS-specific, so it beat its competitor, VBScript, and later beat Applets and now Flash. I think the momentum that inspired V8 and development of great sandboxes, etc. was that JavaScript early on was fun for those that were creating their own webpages.

Tcl/Tk wasn’t fun, and neither were Java’s AWT nor Swing. So, maybe that’s why they didn’t stay around.

However, JS isn’t that fun for me either, these days. Constantly learning to do it “correctly” takes a lot of effort.

Personal opinion: Tcl was lots of fun and somewhat unique in being both a convenient scripting language and an easily embeddable language. But in the end Python and Lua became better replacements for those two specific areas (that's at least how it went in my case, I did lots of Tcl in the late 90's and early 2ks, but then switched to Python for "cross-platform-scripting").

There's still no proper replacement for Tk GUIs as far as I'm aware though, even Python uses it for building quick'n'dirty cross-platform UIs.

> but then switched to Python for "cross-platform-scripting").

For simple scripting I've switched to Powershell (formerly Windows PowerShell). It's OSS, you can use it from the command line and it's available on Windows/OS X/Linux.

https://github.com/PowerShell/PowerShell

Not sure why you are being downvoted, you aren't wrong.

How does it compare to Python?

Powershell can be pretty expressive.

It has a lot in common with Python, but the syntax is more C like when you're scripting, but can be used like a standard shell as well.

The learning curve is partially steep as it takes time to learn the advantages and complexity of piping objects around instead of text streams (like Linux does).

The major deal breaker for me is that file reads and writes which are glacially slow. Like waayyy slower than Python if you can believe it even if you basically call the .NET libraries directly instead of the cmdlets.

So it makes the most sense for Windows IT admin tasks.

The syntax is uglier, and it doesn't have anything like PyCharm. However, as a shell it's syntax lends itself to typing out on the command line. It does have this weird thing where you use lots of aliases to make things ergonomic on the command line, but tend to use the full name in the script. Example "ls" is "Get-Child-Item" and is usable on more than just directories.

What sets it apart IMHO is that it return records instead of just string so you can declare which fields you are interested in instead of trying to parse the string output with "cut"

Tcl is still fun :) We use it at work as an embedded language. It powers many features, and is a quite large part of our product.

It has absolutely lost some mindshare, but I still think it's a great choice.

same here. In the hardware we build (containing, amongst others, an ARM and a FPGA), I added tcl scripting of the kernel driver interface for the FPGA for testing, debugging, fun & profit ;) ..although that has no visual side.

GUI builder for desktop applications in 90s were really useful in increasing the productivity of programmers. It is sad to see how complex it is to build the UI of a web application in comparison. And there is no definite answer on the best way to do it neither.

Of course now you can expose your app to the whole world. But instead of thinking what it means at the application level you spend lot of brain cycles just setting up the styles and uncoupling presentation and logic.

I wonder if we'll ever see a middle ground take over where apps are developed in that 90's GUI builder style but instead of purely desktop applications, they're more akin to tiny internet applications like this idea from Rebol: http://www.rebol.com/reblets.html

Did you try that? Was it good?

I've never tried it, no. Just something I've read about in the past and it seems like something that could be easily done with Tcl and its "safe" interpreter mechanism.

Indeed! I've been trying to figure out if we MUST sacrifice such productivity and K.I.S.S. to get web or web-like features for rank and file CRUD intranet apps. Are the bottlenecks solvable? Related debate:

https://www.reddit.com/r/dotnet/comments/kn20yi/start_with_a...

Until Node (when it was more than 10 years old), JS essentially did not exist outside the web.

And other languages essentially didn’t exist inside the web.

So JS’s success is the web’s success, other explanations are not helpful or needed.

I wouldn’t characterize JS as fun either, especially not in comparison to Python which predates it.

Funny how that came back into vogue. Netscape web server had a JS runtime way back then. Node is way nicer to use though.

I also remember around the same time it was possible to run TCL in browser, like Java applets.

You could run lots of things with the right plug-in/activex component. And even VBScript on IE/Win. But Netscape Navigator was not yet dead, so the only reliable browser scripting language was JS.

> Netscape web server had a JS runtime way back then.

And "applogics", in JS, IIRC. Touched it a bit in the 2000s.

> And other languages essentially didn’t exist inside the web.

Having trouble following your argument. What were people doing with PHP if not "inside the web"?

The argument is that since Javascript was the only programming language running in the browser, it was bound to be successful with the explosion of the web ; other arguments trying to justify why it succeed are not relevant.

> Tcl/Tk wasn’t fun

That is exactly the opposite of my experience with Tcl. It is one of the most fun languages I've used. And it's flexibility is without peer excluding other Lisp-y languages. So many fun things you can do.

Agree. Just the other year I discovered {*}, oh how that simplified some things.

I remember using https://wiki.tcl-lang.org/page/tkBuilder long time ago.

Where can I learn Tk/Tcl today?

"The TCL Programming Language" is a recent (2017) book, paired with the language docs at https://www.tcl.tk/doc/. The language itself is remarkably simple.

A couple of good resources:

https://www.tutorialspoint.com/tcl-tk/index.htm

https://wiki.tcl-lang.org/page/Tcl+Tutorial+Lesson+0

How does using tcl and this compare with using Pascal and Lazarus for GUIs?

Very nice. As the creator of visual JavaScript I am glad to see something even better in the TCL world

Native Client (NaCl) comes to mind.

There's a Tcl blast from the past.