xTalk + xCard / UI as Abstraction Layer or Virtual Machine for maximum portability / longevity

[OpenXTalkPaul]

It's interesting to consider xTalk Script + a standard set of 'classic' UI Widgets Toolkit as an app abstraction layer or 'virtual machine' for maximum portability and longevity. By Virtual machine I don't mean the sort of complete platform virtualization like the great FOSS VirtualBox that can run Windows on a MacOS or Linux host, I'm talking about a VM the way Shockwave/Flash was a VM and Java 'JVMs' are a VMs. Flash and Java games written 25 years ago are still playable thanks to the availability of OpenJSDKs and a bunch of open Flash compatibility layer VMs, not just one or two of those games, but pretty much ALL of those works that targeted that VM App Engine, are now fairly "digital obsolescence" safe, because once you update or port the VM (call it an 'App Engine' if you like) then the ability to run ALL software written for that target engine comes with it.

Many 'vanilla' xTalk scripts that were written 35+ years ago continue to work fine or better than they did back when they were written. These scripts tend to be the Stacks that did NOTt use too many XCMD/XFCN. The basic syntax, the core of xTalk lang has been fairly stable for decades, with probably LC Ltd's LCB (if you consider that xTalk) and recent additions of some new array syntax (array constants declarations), there hasn't been all that many changes to the core language set of syntax since the 1990s, there's been lots of nice upgrades to the syntax, but its still basically the same language as it was in 1987, or maybe whatever year HC 2.x came out, or whenever someone added Array syntax (I had an multiple of 'Array' Xternals for HC).

As a sort of proof of concept take a look at the hyperCard Simulator, its NOT an emulation of System 7 with HyperCard running within a 68K Classic Mac VM, it's more like a HyperCard-only Virtual Machine. xTalk as a platform. HyperCard Stacks can be imported with basic HyperTalk functionality intact, stacks can then even be EXPORTED as 'standalone' HTML. It's a really a nice retro xTalk Engine as web app. Really I think that many of these could be so much more than retro homages to HyperCard, but that seems to be the main interest of some of the authors of these engines.

If you aren't familiar with HyperCard Simulator check it out here: https://hcsimulator.com click the RIGHT side zoom box in the pseudo System 7 Window and it will zoom out to editing tools/menu. It's a mini HyperCard IDE really, sans macOS.

I also think it would be great if we had the sort of VM like Lively or a Smalltalk VM, but once that was xTalk VM instead of SmallTalk VMs running on JS/WebASM. There's some historical connection between SmallTalk and the xTalk worlds. Those sorts of VMs abstract everything, basically everything that's built with them is another VM itself, a complete snapshot of memory when it was saved, everything you added now part of that 'VM' document, so adding some new UI widget to your development environment is just a matter of building it and saving the image.

Smalltalk VMs also prove this point of being digital obsolescence proof. You can still run SmallTalk images of environments that were running in 1978/9 when Steve Jobs and Co. were stealing their ideas to make the Mac and they will run more or less the same way they did at Xerox PARC, but it a browser: Try it here: https://smalltalkzoo.thechm.org/HOPL-St78.html

Lively Kernel is really cool too, the page I found that link on is entirely user customizable, a truly 'Live' Web Page: https://smalltalkzoo.thechm.org

[tperry2x]

Perhaps I was being too dismissive of this. I'm sure it's all very clever work, but in Firefox at least, it takes an age to load anything (with that multi-piston gif). I was on the verge of closing the window and giving up when it finally loaded.

Then seemingly the icons on the right seemed to get 'stuck' to my cursor and dump themselves into the text field on the left hand side of the page. The font was unreadable several times, and it was generally very unresponsive.

I'm sure it's all very clever stuff, and would have liked to try it. Perhaps I'll fire up Chrome (or something else based on webkit) and see if it behaves a little better.

For me (perhaps set in my ways, with a dislike for anything purely-cloud-hosted), the trade off of perhaps improved future compatibility does not match up with the reality of slow loading times, inconsistencies across different browsers and limited access that a web-app has to system resources as opposed to a desktop program.

As I say, perhaps I'll try this again at some point.

[Kdjanz]

May I suggest you try a variety of browsers? It loaded virtually instantly for me with the pistons firing away.

My setup is a Mac M1 Studio with 32 MG RAM and a 300 mbs cable connection using the Arc browser, so I know that I am in a privileged position in terms of hardware. It was also fast in Safari as well as Brave. Those are the browsers I use on a daily basis. Arc and Brave both use the Chrome engine but withOUT the Google info and security leaks and give me a contrast to the Webkit engine from Apple.

[tperry2x]

I will try a handful of browsers, but I'm sure most of it is due to my connection as that's terrible.