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")
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.
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.
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.
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.
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"
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
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:
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.
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.
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.
"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.
(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