Visual Tcl
vtcl.sourceforge.net
vtcl.sourceforge.net
(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
This may be of interest if you find the idea of a live Tcl environment interesting: https://news.ycombinator.com/item?id=22852484
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 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.
Not sure the Tcl Plugin would still run anywhere, which is a shame
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.
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.
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.
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.
Having trouble following your argument. What were people doing with PHP if not "inside the web"?
I also remember around the same time it was possible to run TCL in browser, like Java applets.
And "applogics", in JS, IIRC. Touched it a bit in the 2000s.
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.
https://www.reddit.com/r/dotnet/comments/kn20yi/start_with_a...
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.
It has absolutely lost some mindshare, but I still think it's a great choice.
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.
How does it compare to Python?
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.
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"
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.