Comment by frou_dh
6 hours ago
Since Smalltalk is effectively an OS unto itself, when we hear about the days of commercial applications being written in Smalltalk, how did deployment to end-users work?
Were the users running, say, Windows and then the Smalltalk "OS" would be running on top of that, but in a sort of "kiosk mode" where its full OS-ness was suppressed and it was dedicated to showing a single interface?
I worked on a Smalltalk system which ran on Visual Smalltalk Enterprise, and in that system the image opened its windows as native Windows GDI windows, which made the application quite seamless in the OS (except this was in 2016-2018 and VSE was last updated in ‘99, so the look and feel was a bit dated :D).
I used a "modern" app written in Cincom Smalltalk this year (still maintain and sold a high price), and you don't see the underlying system. Like you don't see the source code when opening any other app, in fact. The app resets the state at startup, so no lingering eternal session.
It's funny because in the past I got the chance to test izware Mirai, which is written in Lisp — when the app got into a problematic state (which was often on my machine) you were sent to the REPL where you could inspect the memory and so on. It was alien to me at the time. Today I dream of having that.
> (still maintain and sold a high price)
I was surprised a couple years back they still maintain Mantis, a 4GL I used on a mainframe (it was kind of Rails for the 3270 terminal). Even the documentation is hideously expensive. I asked if they had a “hobby license” I could use to run under Hercules. They seemed genuinely perplexed that someone would imagine they would allow me to use their software without sacrificing my firstborn.
Easy, you make use of tree-shaking, which is actually older concept than minifying JavaScript, and add glue it together with an executable header that boots the image.
I don't feel like this really answers OP's question, which is more about the user experience than the technical approach.
When, as a dev, I use Smalltalk, it opens up what's effectively a virtual machine on my desktop. The whole Smalltalk GUI runs inside its own frame, none of the controls are native, etc. And it's a development environment - I have access to a class browser, a debugger, a REPL, and so on. I can drill down and read/modify the source code of everything. Which is great as a dev, but may be intimidating for an end user.
Is that what the end user experience is like as well? I think that's what OP is asking. I've never used a Smalltalk application as an end user to my knowledge, so I can't say myself.
The user experience, in commercial Smalltalks, like Cincom Smalltalk, is just like any other compiled application.
The application packager removes everything that is related to Smalltalk as developer environment, and possibly other classes that are also not used by the application, so you get a slimmed down image.
Then you have the VM boot code, as native executable, that is responsible for starting the image execution.
Thanks to the way executable files work in most platforms, the packing tool merges that boot loader and the slimmed down image into a single executable.
When the executable starts, the loader locates the image inside the executable, loads it, and transfers execution to the runtime.
Java and .NET also have similar techniques available, see jlink, or Single-file deployment respectively.
> none of the controls are native
Depends which Smalltalk implementation.
Digitalk and Dolphin and IBM Smalltalk … wrapped native widgets.
No, you can tell the image to not boot the 'world', only the application you've been building. The details probably vary a lot between versions of the language, but you wouldn't be forced to put system browsers and all that in the face of your user.
I don't understand what "tree-shaking" means, can you point to a reference to give me a better understanding?
You might know it as "dead code stripping": You remove all the things from the image that aren't used in your shipping app.
Calling it "tree shaking" is web development term AFAIK.
1 reply →
Tree shaking in this context is not unlike a compiler: it looks at all the code and determines if it will ever run in the image, eliminating any unnecessary code and delivering the minimal image needed. The code is in a “tree” format like an AST, and you’re shaking the tree to test what can be removed.
I used a more recent term known to Web developers.
It means going through the image and remove most code that isn't directly needed by the application, or only exists to support developer workflows.
Usually needs a bit help for fine tuning, regarding what code to keep, and what to delete.
You also find this on Java (jlink, ProGuard, D8/R8 on Android), and .NET (trimming, .NET Native manifests).