Hacker News Reader

Comment by frou_dh | Hacker News Reader

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?

View on HN

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 understand what "tree-shaking" means, can you point to a reference to give me a better understanding?

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.

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.

> Calling it "tree shaking" is web development term AFAIK.

I think that's backwards. Lars Bak and the other V8 folks came from the Smalltalk world and brought the "tree shaking" term with them as far as I know.

Wikipedia claims that it originated in Lisp, and the oldest reference I can find is this from 1991: https://www.dreamsongs.com/Files/LispGoodNewsBadNews.pdf (section 1.6.3)

In any case, before the JavaScript usage, it seems that treeshaking applied to objects to be included in a runtime image. The JavaScript usage is actually more akin to the dead-code elimination and link-time symbol removal of compiled and linked languages.

Interesting. It's come full circle terminology wise.

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).

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.

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.

> none of the controls are native

Depends which Smalltalk implementation.

Digitalk and Dolphin and IBM Smalltalk … wrapped native widgets.

Reply on news.ycombinator.com