So random to read this here today. I was a student there at the time and worked with those folks. Never thought I'd hear about Squeak again. Was an honor meeting Dan Ingalls!
It just received an award from the ACM SIGPLAN Dynamic Language Symposium, and it's a great paper.
One of my favorites, up there with the original "Self" papers.
The approach it describes to layering the Smalltalk VM on top of the JavaScript VM has worked out quite well thanks to the way JavaScript VMs have evolved.
SqueakJS: A Modern and Practical Smalltalk that Runs in Any Browser
Vanessa Freudenberg, Dan Ingalls, Tim Felgentreff, Tobias Pape, Robert Hirschfeld
This paper reports on SqueakJS, a fully compatible Squeak/Smalltalk implemented in pure JavaScript. In 2014, it demonstrated that with thoughtful implementation techniques, browsers and their JavaScript VMs can enable applications as dynamic and interactive as Smalltalk environments. Furthermore, the paper details how powerful programming language features such as object enumeration, application snapshotting, custom graphics interfaces, as well as basic file abstractions can be realized inside the browser environment.
Today, SqueakJS continues to be used in education, for web applications, and as environments to preserve important parts of Smalltalk’s history, and with it, computing history.
Laurence Tratt,
Program Chair DLS’14
Stefan Marr,
Steering Committee Chair
2024 Dynamic Languages Symposium, the premier forum for researchers and practitioners to share research and experience on all aspects on dynamic languages.
Here's the previous HN discussion from 2015 soon after it was published:
> One of my favorites, up there with the original "Self" papers.
Interesting. Why?
I mean, you just implement a bytecode interpreter in JS and run that.
> layering the Smalltalk VM on top of the JavaScript VM has worked out quite well
How has this worked out well?
The VM described is ~100 times slower than the already not so super-fast Squeak bytecode interpreter. The only reason this works at all is that machines today are ridiculously fast.
It pains me that we waste all this incredible performance on ridiculous amounts of layering.
2022: Separated from Laura, and moved to my own place in Downtown LA.
2020: Came out publicly as a transgender woman. Changing my name to Vanessa Ada Freudenberg.
2019: Something is afoot. Gotta figure it out soon. Trying some things, gender-wise.
2017: Married Laura! Had a lovely honeymoon in Paris. She makes me very happy :)
2015: Separated amicably from Rita, am now living alone with one of the kids
June 2004: You can call me Dr. Freudenberg now - I defended my PhD thesis with "magna cum laude" (technically I'm an EngD).
July 2003: We moved into our new-built home.
1999: Our twins Jakob and Spencer were born. We're doubling the number of kids every time. Probably should stop now.
1998: I married Rita! And since we chose my wife's last name as our family name, I'm no longer Bert Schönwälder. No umlauts anymore ... Bert Freudenberg is so much easier to spell. :)
1995: Our son Paul was born – double the fun!
1993: Moved in with Rita and her son Sebastian.
@dang, it looks like the comments just got reordered. The top one was posted 5 hours ago, and it fell to the bottom in the last few minutes.
I'm curious how that happened since you've just posted this message above.
EDIT: Ah I get it: the headline was updated by moderation, and the comment critiquing the headline was de-ranked. The post is still wrong though, the link should be pointing at https://x.com/dynlangsym/status/1856748088708210924, since the PDF from 2014 doesn't explain the 2024 headline.
Ok, I've changed the title to that of the paper now. Submitted title was "Vanessa Freudenberg's SqueakJS Paper Wins ACM Sigplan Most Notable Paper Award [pdf]".
I've also moved Don's original description to the top of the thread so people have the context about the award.
It won an award from the Dynamic Languages Symposium. A minor workshop that gets about 4-6 submissions per year. By the standards of modern academia this would be considered a tiny venue, like 10x smaller than any say at workshop at NeurIPS and quite a bit smaller than an ICFP workshop.
I actually tried to add DLS to the title of this discussion, but the character limit was one character too short, so I was forced to leave it out. Sorry, the intent was not to deceive you or commit academic fraud.
Have you actually read the paper and have anything interesting to say about it, or are you just complaining about the title of this discussion?
Of course you could paint the bikeshed that color, but it's too late now. If you really care that much and want to bother him, you could email hn@ycombinator.com and maybe dang will edit the title.
Do you have anything interesting to say about the contents of the paper itself, or did you just come here to complain about the discussion title too?
Pointing out a highly misleading article title and how it could be easily improved is not bike-shedding in the least.
As to the contents, I am not sure I have anything interesting to say about it, but I find the idea of layering one dynamic language on top of another dynamic language in this fashion unconvincing.
The benchmarks cited in the paper bear out my skepticism: "... between one and two orders of magnitude slower than the Squeak Interpreter in C". On chrome it was between 2 and 3 orders of magnitude. So around a hundred times slower than the Squeak byte code interpreter, which is already not exactly a speed demon.
One thing the paper does demonstrate is the incredible performance of today's hardware, well even the hardware of 10 years ago, which is the only thing that makes such an approach even remotely viable.
When I attended ESUG '19 in Cologne, there were several of these Smalltalk → JavaScript projects present (I think at least 3). The others worked using transpilation, but the purpose of all these systems was to run existing legacy Smalltalk systems without existing legacy VMs. So a lot of legacy. Very little innovation. I rarely saw good reasons for Smalltalk apart from "well, we just have this huge legacy codebase that we don't want to touch" (and a bit of "I am used to the IDE"). Made me a bit sad.
Yes, running a Squeak image unmodified in the browser by simply porting the VM is neat, as a curiosity. Kinda like booting Linux in the browser.
We already have too many layers as it is, and this way of just plopping one layer on top of another layer in order not to have to change things is exactly how we got there. (unless you are very explicitly doing code archeology as described in the paper)
This paper describes how Vanessa's groundbreaking Smalltalk VM implemented in JavaScript runs historic Smalltalk images, and elegantly and efficiently integrates Smalltalk's garbage collector with JavaScript's.
I've written about her work and this paper previously on Hacker News:
The incredible Smalltalk developer Vanessa Freudenberg -- who besides being Croquet's devops person, also developed Squeak Smalltalk, EToys, Croquet, and the SqueakJS VM written in JavaScript, and worked extensively with Alan Kay -- was just tweeting (yeah, it's ok to deadname Twitter!) about reviving Croquet from 20 years ago:
I've been having fun reviving the Croquet from 20 years ago using @SqueakJS . It's not perfect yet, but a lot of the old demos work (sans collaboration, so far). This is pretty close to the version Alan Kay used to give his Turing Award lecture in 2004:
This is a version of Croquet Jasmine running on the SqueakJS virtual machine. Here is an early demo of the system from 2003. Alan Kay used it for his Turing Award lecture in 2004. While working on that demo, David Smith posted some blog entries (1, 2, 3, 4, 5), with screenshots uploaded to his Flickr album.
This is work-in-progress. Contributions are very welcome.
— Vanessa Freudenberg, December 2023
Dan Ingalls @daningalls
Yay Vanessa! This is awesome. These are mileposts in our history that now live again!
Vanessa Freudenberg @codefrau 7:40 PM · May 17, 2022
My company @CroquetIO announced #MicroverseBuilder today.
Each microverse is "just" a static web page that you can deploy anywhere, but it is fully 3D multiplayer, and can be live-coded. Portals show and link to other developer's worlds.
This is our vision of the #DemocratizedMetaverse as opposed to the "Megaverses" owned by Big Tech.
It runs on #CroquetOS inside your browser, which provides the client-side real-time synchronized JS VMs that you already know from my other posts.
#MicroverseBuilder is in closed alpha right now because we don't have enough #devrel people yet (we're hiring!) but you can join our Discord in the mean time and the open beta is not far away.
We are also looking for summer interns! #internships
And of course #CroquetOS itself is already available for you to build multiplayer apps, as is our #WorldcoreEngine, the game engine underlying #MicroverseBuilder.
HN really needs a better automatic-deduplication engine. E.g. If the same link is posted again months later, mark the original post as new again with an upvote, and the caption (if changed) as a comment...
codefrau 6 months ago | prev [–]
Haha, thanks for the plug, Don!
I just fleshed out the README for my Croquet resurrection yesterday so others may have an easier time trying it. It maybe even contribute :)
Vanessa, it has always amazed me how you managed to square the circle and pull a rabbit out of a hat by the way you got garbage collection to work efficiently in SqueakJS, making Smalltalk and JavaScript cooperate without ending up with two competing garbage collectors battling it out. (Since you can't enumerate "pointers" with JavaScript references by just incrementing them.)
>The fact that SqueakJS represents Squeak objects as plain JavaScript objects and integrates with the JavaScript garbage collection (GC) allows existing JavaScript code to interact with Squeak objects. [...]
>• a hybrid garbage collection scheme to allow Squeak object enumeration without a dedicated object table, while delegating as much work as possible to the JavaScript GC,
Have you ever thought about implementing a Smalltalk VM in WebAssembly, and how you could use the new reference types for that?
I would like to speed up some parts of SqueakJS using web assembly. For example BitBlt would be a prime target. For the overall VM, however, I’ll leave that to others (I know Craig Latta has been making progress).
I just love coding and debugging in a dynamic high-level language. The only thing we could potentially gain from WASM is speed, but we would lose a lot in readability, flexibility, and to be honest, fun.
I’d much rather make the SqueakJS JIT produce code that the JavaScript JIT can optimize well. That would potentially give us more speed than even WASM.
DonHopkins 6 months ago | root | parent | next [–]
>Where this scheme gets interesting is when the execution progressed somewhat deep into a nested call chain and we then need to deal with contexts. It could be that execution is interrupted by a process switch, or that the code reads some fields of thisContext, or worse, writes into a field of thisContext. Other “interesting” occasions are garbage collections, or when we want to snapshot the image. Let's look at these in turn. This sounds similar to Self's "dynamic deoptimization" that it uses to forge virtual stack frames representing calls into inlined code, for the purposes of the debugger showing you the return stack that you would have were the functions not inlined.
I always thought that should be called "dynamic pessimization".
Debugging Optimized Code with Dynamic Deoptimization. Urs Hölzle, Craig Chambers, and David Ungar, SIGPLAN Notices 27(7), July, 1992.
That paper really blew my mind and cemented my respect for Self, in how they were able to deliver on such idealistic promises of simplicity and performance, and then oh by the way, you can also debug it too.
codefrau 6 months ago | root | parent | next [–]
Absolutely. And you know Lars Bak went from Self to Strongtalk to Sun’s Java Hotspot VM to Google’s V8 JavaScript engine. My plan is to do as little as necessary to leverage the enormous engineering achievements in modern JS runtimes.
Glad I asked! Fun holiday reading to curl up with a cat to read. Thanks!
I love Caffeine, and I use Craig's table every day! Not a look-up table, more like a big desk, which I bought from him when he left Amsterdam. ;)
---
Vanessa> Our guiding principle will be to keep our own optimizations to a minimum in order to have quick compiles, but structure the generated code in a way so that the host JIT can perform its own optimizations well.
Don> That's the beautiful thing about layering the SqueakJS VM on top of the JS VM: you've already paid for it, it works really well, so you might as well use it to its full extent!
Very different set of trade-offs than implementing Self in C++.
Vanessa> Precisely. My plan is to do as little as necessary to leverage the enormous engineering achievements in modern JS runtimes.
SqueakJS – A Squeak VM in JavaScript - https://news.ycombinator.com/item?id=29018465 - Oct 2021 (24 comments)
SqueakJS – A Squeak VM in JavaScript - https://news.ycombinator.com/item?id=8982251 - Feb 2015 (10 comments)
One of my favorites, up there with the original "Self" papers.
The approach it describes to layering the Smalltalk VM on top of the JavaScript VM has worked out quite well thanks to the way JavaScript VMs have evolved.
Here's the text of Vanessa's tweet:
https://x.com/dynlangsym/status/1856748088708210924
Dynamic Language Symposium @dynlangsym
This year's DLS Most Notable Paper award goes to:
SqueakJS: A Modern and Practical Smalltalk that Runs in Any Browser
by @codefrau, Dan Ingalls, @timfelgentreff, @krono, and Robert Hirschfeld.
Congratulations to the authors!
Read the paper here: https://freudenbergs.de/vanessa/publications/Freudenberg-201...
Association for Computing Machinery
Most Notable Paper Award
Dynamic Languages Symposium
SqueakJS: A Modern and Practical Smalltalk that Runs in Any Browser
Vanessa Freudenberg, Dan Ingalls, Tim Felgentreff, Tobias Pape, Robert Hirschfeld
This paper reports on SqueakJS, a fully compatible Squeak/Smalltalk implemented in pure JavaScript. In 2014, it demonstrated that with thoughtful implementation techniques, browsers and their JavaScript VMs can enable applications as dynamic and interactive as Smalltalk environments. Furthermore, the paper details how powerful programming language features such as object enumeration, application snapshotting, custom graphics interfaces, as well as basic file abstractions can be realized inside the browser environment.
Today, SqueakJS continues to be used in education, for web applications, and as environments to preserve important parts of Smalltalk’s history, and with it, computing history.
Laurence Tratt, Program Chair DLS’14
Stefan Marr, Steering Committee Chair
2024 Dynamic Languages Symposium, the premier forum for researchers and practitioners to share research and experience on all aspects on dynamic languages.
Here's the previous HN discussion from 2015 soon after it was published:
https://news.ycombinator.com/item?id=8982251
> One of my favorites, up there with the original "Self" papers.
Interesting. Why?
I mean, you just implement a bytecode interpreter in JS and run that.
> layering the Smalltalk VM on top of the JavaScript VM has worked out quite well
How has this worked out well?
The VM described is ~100 times slower than the already not so super-fast Squeak bytecode interpreter. The only reason this works at all is that machines today are ridiculously fast.
It pains me that we waste all this incredible performance on ridiculous amounts of layering.
I'm curious how that happened since you've just posted this message above.
EDIT: Ah I get it: the headline was updated by moderation, and the comment critiquing the headline was de-ranked. The post is still wrong though, the link should be pointing at https://x.com/dynlangsym/status/1856748088708210924, since the PDF from 2014 doesn't explain the 2024 headline.
I've also moved Don's original description to the top of the thread so people have the context about the award.
Sigplan doesn't even have a most notable paper award. https://www.sigplan.org/Awards/
It won an award from the Dynamic Languages Symposium. A minor workshop that gets about 4-6 submissions per year. By the standards of modern academia this would be considered a tiny venue, like 10x smaller than any say at workshop at NeurIPS and quite a bit smaller than an ICFP workshop.
Have you actually read the paper and have anything interesting to say about it, or are you just complaining about the title of this discussion?
Update: I should note that I have published several papers at DLS. It is a great venue(1), but it just is not ACM SIGPLAN.
(1) or was. There was no DLS at this year's SPLASH.
Do you have anything interesting to say about the contents of the paper itself, or did you just come here to complain about the discussion title too?
As to the contents, I am not sure I have anything interesting to say about it, but I find the idea of layering one dynamic language on top of another dynamic language in this fashion unconvincing.
The benchmarks cited in the paper bear out my skepticism: "... between one and two orders of magnitude slower than the Squeak Interpreter in C". On chrome it was between 2 and 3 orders of magnitude. So around a hundred times slower than the Squeak byte code interpreter, which is already not exactly a speed demon.
One thing the paper does demonstrate is the incredible performance of today's hardware, well even the hardware of 10 years ago, which is the only thing that makes such an approach even remotely viable.
When I attended ESUG '19 in Cologne, there were several of these Smalltalk → JavaScript projects present (I think at least 3). The others worked using transpilation, but the purpose of all these systems was to run existing legacy Smalltalk systems without existing legacy VMs. So a lot of legacy. Very little innovation. I rarely saw good reasons for Smalltalk apart from "well, we just have this huge legacy codebase that we don't want to touch" (and a bit of "I am used to the IDE"). Made me a bit sad.
Yes, running a Squeak image unmodified in the browser by simply porting the VM is neat, as a curiosity. Kinda like booting Linux in the browser.
https://bellard.org/jslinux/
But please don't do it.
We already have too many layers as it is, and this way of just plopping one layer on top of another layer in order not to have to change things is exactly how we got there. (unless you are very explicitly doing code archeology as described in the paper)
See: We are likely looking at over 50 million active lines of code to open a garage door…. https://spectrum.ieee.org/lean-software-development
I've written about her work and this paper previously on Hacker News:
https://news.ycombinator.com/item?id=40917424
DonHopkins 4 months ago | parent | context | favorite | on: Dynamic translation of Smalltalk to WebAssembly
Here's some stuff Vanessa and I discussed about Self and her SqueakJS paper:
DonHopkins 6 months ago | parent | context | favorite | on: Croquet: Live, network-transparent 3D gaming
Excellent article -- Liam Proven does it again! Speaking of a big Plate of Shrimp -- https://www.youtube.com/watch?v=rJE2gPQ_Yp8 ...
The incredible Smalltalk developer Vanessa Freudenberg -- who besides being Croquet's devops person, also developed Squeak Smalltalk, EToys, Croquet, and the SqueakJS VM written in JavaScript, and worked extensively with Alan Kay -- was just tweeting (yeah, it's ok to deadname Twitter!) about reviving Croquet from 20 years ago:
https://twitter.com/codefrau/status/1738778761104068754
Vanessa Freudenberg @codefrau
I've been having fun reviving the Croquet from 20 years ago using @SqueakJS . It's not perfect yet, but a lot of the old demos work (sans collaboration, so far). This is pretty close to the version Alan Kay used to give his Turing Award lecture in 2004:
https://github.com/codefrau/jasmine
Live version: https://codefrau.github.io/jasmine
This is a version of Croquet Jasmine running on the SqueakJS virtual machine. Here is an early demo of the system from 2003. Alan Kay used it for his Turing Award lecture in 2004. While working on that demo, David Smith posted some blog entries (1, 2, 3, 4, 5), with screenshots uploaded to his Flickr album.
This is work-in-progress. Contributions are very welcome.
— Vanessa Freudenberg, December 2023
Dan Ingalls @daningalls
Yay Vanessa! This is awesome. These are mileposts in our history that now live again!
https://twitter.com/codefrau/status/1526618670134308864
Vanessa Freudenberg @codefrau 7:40 PM · May 17, 2022
My company @CroquetIO announced #MicroverseBuilder today.
Each microverse is "just" a static web page that you can deploy anywhere, but it is fully 3D multiplayer, and can be live-coded. Portals show and link to other developer's worlds.
This is our vision of the #DemocratizedMetaverse as opposed to the "Megaverses" owned by Big Tech.
It runs on #CroquetOS inside your browser, which provides the client-side real-time synchronized JS VMs that you already know from my other posts.
#MicroverseBuilder is in closed alpha right now because we don't have enough #devrel people yet (we're hiring!) but you can join our Discord in the mean time and the open beta is not far away.
We are also looking for summer interns! #internships
https://www.youtube.com/watch?v=CvvuAbjh11U
And of course #CroquetOS itself is already available for you to build multiplayer apps, as is our #WorldcoreEngine, the game engine underlying #MicroverseBuilder.
Learn more at https://croquet.io/docs/ and let's get hacking :)
And as of today, #MicroverseBuilder is Open Source!
lproven 6 months ago | next [–]
Thanks Don! This is my original submission from back at the time:
https://news.ycombinator.com/item?id=35302162
HN really needs a better automatic-deduplication engine. E.g. If the same link is posted again months later, mark the original post as new again with an upvote, and the caption (if changed) as a comment...
codefrau 6 months ago | prev [–]
Haha, thanks for the plug, Don!
I just fleshed out the README for my Croquet resurrection yesterday so others may have an easier time trying it. It maybe even contribute :)
https://github.com/codefrau/jasmine
DonHopkins 6 months ago | parent [–]
Vanessa, it has always amazed me how you managed to square the circle and pull a rabbit out of a hat by the way you got garbage collection to work efficiently in SqueakJS, making Smalltalk and JavaScript cooperate without ending up with two competing garbage collectors battling it out. (Since you can't enumerate "pointers" with JavaScript references by just incrementing them.)
https://freudenbergs.de/vanessa/publications/Freudenberg-201...
>The fact that SqueakJS represents Squeak objects as plain JavaScript objects and integrates with the JavaScript garbage collection (GC) allows existing JavaScript code to interact with Squeak objects. [...]
>• a hybrid garbage collection scheme to allow Squeak object enumeration without a dedicated object table, while delegating as much work as possible to the JavaScript GC,
Have you ever thought about implementing a Smalltalk VM in WebAssembly, and how you could use the new reference types for that?
https://bytecodealliance.org/articles/reference-types-in-was...
codefrau 6 months ago | root | parent [–]
I would like to speed up some parts of SqueakJS using web assembly. For example BitBlt would be a prime target. For the overall VM, however, I’ll leave that to others (I know Craig Latta has been making progress).
I just love coding and debugging in a dynamic high-level language. The only thing we could potentially gain from WASM is speed, but we would lose a lot in readability, flexibility, and to be honest, fun.
I’d much rather make the SqueakJS JIT produce code that the JavaScript JIT can optimize well. That would potentially give us more speed than even WASM.
Peep my brain dumps and experiments at https://squeak.js.org/docs/jit.md.html
DonHopkins 6 months ago | root | parent | next [–]
>Where this scheme gets interesting is when the execution progressed somewhat deep into a nested call chain and we then need to deal with contexts. It could be that execution is interrupted by a process switch, or that the code reads some fields of thisContext, or worse, writes into a field of thisContext. Other “interesting” occasions are garbage collections, or when we want to snapshot the image. Let's look at these in turn. This sounds similar to Self's "dynamic deoptimization" that it uses to forge virtual stack frames representing calls into inlined code, for the purposes of the debugger showing you the return stack that you would have were the functions not inlined.
I always thought that should be called "dynamic pessimization".
Debugging Optimized Code with Dynamic Deoptimization. Urs Hölzle, Craig Chambers, and David Ungar, SIGPLAN Notices 27(7), July, 1992.
https://bibliography.selflanguage.org/dynamic-deoptimization...
That paper really blew my mind and cemented my respect for Self, in how they were able to deliver on such idealistic promises of simplicity and performance, and then oh by the way, you can also debug it too.
codefrau 6 months ago | root | parent | next [–]
Absolutely. And you know Lars Bak went from Self to Strongtalk to Sun’s Java Hotspot VM to Google’s V8 JavaScript engine. My plan is to do as little as necessary to leverage the enormous engineering achievements in modern JS runtimes.
DonHopkins 6 months ago | root | parent | prev [–]
Glad I asked! Fun holiday reading to curl up with a cat to read. Thanks!
I love Caffeine, and I use Craig's table every day! Not a look-up table, more like a big desk, which I bought from him when he left Amsterdam. ;)
---
Vanessa> Our guiding principle will be to keep our own optimizations to a minimum in order to have quick compiles, but structure the generated code in a way so that the host JIT can perform its own optimizations well.
Don> That's the beautiful thing about layering the SqueakJS VM on top of the JS VM: you've already paid for it, it works really well, so you might as well use it to its full extent!
Very different set of trade-offs than implementing Self in C++.
Vanessa> Precisely. My plan is to do as little as necessary to leverage the enormous engineering achievements in modern JS runtimes.