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.
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.
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.
> 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.
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.
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.
Unsurprisingly there are many frameworks/initiatives that end up falling by the wayside over the years, e.g. MacRuby was being lined up to supersede Objective-C for app development at one point.
I think WasmGC is very hard to make work with laziness.
A lazy value is always a closure on the heap.
If an expression might be unused, throw a closure which computes it on the heap
If the value is actually needed, invoke the closure. Optionally replace the closure with a black hole. A black hole is just a closure which pauses any thread which calls it, to be resumed once the first thread finishes with the expression
Once finished, replace with a closure which immediately returns the computation result. (Or often save the indirection because most concrete values also act as closures which immediately returns themselves using info table pointers trickery)
Anyway, iirc WasmGC wants very rigid types without dynamic type changes. Extra indirections could fix that, Oor maybe defunctionalizing thunks into a tagged union, but both sound expensive. Especially without being able to hook into the tracing step for indirection removal.
Also, Haskell supports finalizers so WasmGC would need that as well.
> Anyway, iirc WasmGC wants very rigid types without dynamic type changes.
You can have dynamic type changes in the current WasmGC MVP, but they are modeled as explicit downcasts from a supertype of some sort. There's not even any express support for tagged unions, structs and downcasting is all you get at the moment.
WasmGC is still a 1.0, there are many kind of GC semantics that it cannot handle, for example it still doesn't cover all use cases needed for languages like C# and Go, e.g. interior pointers.
I’m the creator of Clojure Land. I did base the original project list on the Clojure Toolbox and give full credit in the repo’s README.md.
The big difference between Clojure Land and the Clojure Toolbox is syncing with GitHub for things like description, stars, etc and search.
I also regularly follow the Clojurians Slack and /r/Clojure for project announcements. Of course PRs to help keep the project list up to date are always welcome.
To me the charming thing about Emacs is how introspective a program it is. This goes beyond all the documentation being built-in, and being able to redefine things on the fly. For instance, it's easy to define a keybinding that does "Take me to the source code of the command that's bound to the next keybinding I type". When you use that and land at a destination, it will probably be Elisp code, but in some cases will even be C code - it works either way.
That and how smooth the customization curve is, from tweaking settings, to recording keyboard macros, to writing small helper functions, to creating whole packages. Compare that to something like Eclipse or IntelliJ, where there's a huge gap between changing settings and creating plugins. It's a sweet spot between semi-configurable text editors and full-blown "living ball of mud" systems like Lisp and Smalltalk.
Yeah, before Emacs, it never occurred to me to even think of trying to control my browser from my editor.
I never thought that I can type just about any text, not in the input box of some app, but in my editor - with Emacs, if I need to type anything longer that three words - in Slack app, Zoom chat, browser window, etc., I'll do it in my editor, why have I never thought about this before?
Emacs has no business of taking screenshots, yet I use it to do just that - I'd insert a screenshot while taking notes, OCRing the text out of image when desired.
Before Emacs, I never thought of playing and controlling videos from my editor or driving my WM from it - I simply never thought how advantageous could that even be.
I can't really use anything else without feeling constrained specifically because [mostly] nothing else allows me to type some Lisp in just about any buffer, evaluate it in place and immediately affect not only my editor but any computational aspect on a local or remote machine.
In essence, Emacs is a mindset. Non-Emacs folk often don't see the "actual use cases" because their minds operate on a different plane. And for some, once they crack open that door of possibilities, there's really no turning back.
> Non-Emacs folk often don't see the "actual use cases" because their minds operate on a different plane.
youve just listed a bunch of scripts launched from emacs. with your logic, you can take the lisp interpreter out of emacs, stick it into say mspaint, and have an equally powerful program.
Yes, it may sound like that to someone unacquainted with it. But have you ever thought about the reasons why Emacs remains relevant and triumphant even half a century later?
Here's really fascinating stuff: I can start a fresh new instance of plain, vanilla, clean-slate instance of Emacs; then open a scratch buffer and piece-by-piece rebuild my entire configuration, consisting of a dozen thousand lines of customizations; install third-party packages that bring hundreds of thousands of their own code; I can do that by evaling every expression one-by-one without not only having to restart Emacs even once, but even not needing to save that code anywhere. How many applications can you name that are capable of pulling a trick like that?
Sure, that may sound impractical, let me give you another, real-life example: I needed to change how Google Translate [extension] works - I wanted it to translate year denominations (to learn exactly how they spelled in a foreign language). Did I have to dig through the Google API docs? Nope. Did I have to write my own custom extension? Nope. Did I even have to re-implement the function that sends the payload? Once again, nope. I just had to precisely advise a single function and convert digits to words before sending the payload, something like eleven lines of code. And it took me no longer than fifteen minutes. Good luck trying something like that in pretty much any other editor.
So, yeah, getting exposed to that kind of power does change your mindset.
> I can start a fresh new instance of plain, vanilla, clean-slate instance of Emacs; then open a scratch buffer and piece-by-piece rebuild my entire configuration, consisting of a dozen thousand lines of customizations; install third-party packages that bring hundreds of thousands of their own code;
we're here to edit text though, I thought? It sounds clever but it might be clever for clevers sake sometimes.
It seems you're missing the point - that example is 'reductio ad absurdum' - a showcase of the logical extreme of capabilities, not an illustration of concrete practicality.
You seem to be blinded by your sunk cost, social proof, tribal identity, status quo, and other biases, so you rather reject novel ideas than accept their practical superiority in certain scenarios.
Emacs, in every respect, is a pinnacle of text editing in its digital form. Half a century of evolution and refinement with fundamental architectural advantage - a Lisp runtime that happens to edit text.
It makes it possible to edit any text that lives within its running instance and beyond - just about anything it can reach - containers, kubernetes pods, browsers. I can edit the URL of any tab in my browser directly from my editor; remote computers - I can edit a commit message on an EC2 instance; heck, even spacecrafts a million miles away - if it can gain access. More than that - there's universal bidirectionality - I can push any text into Emacs - from my terminal, my browser, or any app. If I allow access to it, I can even push to Emacs from remote computers.
I'm, by the way, not an 'Emacs purist' - I use Neovim daily, and sometimes VSCode too. I have used various JetBrains products - I was a heavy user of IntelliJ for almost a decade. Yet, getting exposure to Emacs capabilities proved that I was wrong in my prejudice and I should've tried it sooner. Like I said: it's a mindset-changing endeavor - without a heartfelt attempt to use it, it's unlikely you'll ever get what I'm even talking about.
> It seems you're missing the point - that example is 'reductio ad absurdum' - a showcase of the logical extreme of capabilities, not an illustration of concrete practicality.
such as?
>I can edit the URL of any tab in my browser directly from my editor
Do you really have to be a jerk? Or you were dropped in your infancy and you just can't fucking help it? Go seek some professional help maybe, it really hurts to see someone being so miserable.
Yes I lost my cool for a moment, we have a history with that HNemer. He made it his full-time job to troll, to the point that it makes me want to stay away from engaging any conversations on this site.
You're not the pot calling the kettle black, but please don't respond in kind to people like that ... if you simply ignore him and those like him (I know, it's hard) then your engagement with reasonable people shouldn't be affected.
> Extending Visual Studio in more than the ways it has already provided....It means freedom.
if youre able to edit the source code of a program, youre probably a programmer. you already had the freedom. and that can be done with git and the offline source code. its not freedom its convenience if anything
Certain domains are a lot more wide open than others though. If you want to develop a command-line program that does something with files and possibly the network, then many many languages are suitable. If you want to develop a proper desktop GUI application (using mature design/layout tooling, naturally) then the field of suitable languages is cut down massively, and trying to shoehorn one in is indeed inadvisable.
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?
reply