6 ms·

Live Objects All the Way Down: Removing the Barriers Between Apps and VMs

89 points by mpweiher 3y ago

transpute 3y ago
Recently, "Design Principles Behind Smalltalk (1981)", https://news.ycombinator.com/item?id=38821506 https://news.ycombinator.com/item?id=38821506
- igouy 3y ago
  Maybe there's something new.
  - transpute 3y ago
    Smalltalk and Javascript? https://github.com/codefrau/SqueakJS https://github.com/codefrau/SqueakJS
CyberDildonics 3y ago
This looks like it is a small talk implementation with a lot of fancy nonsense terms to make it sound like it is something new. I've never heard the term "Live Metacircular Runtimes (LMRs)" but they seem to think they are improving on "classic metacircular approaches"
- thomasjudge 3y ago
  https://www.google.com/search?q=Metacircular https://www.google.com/search?q=Metacircular
- danparsonson 3y ago
  I did indeed tilt my head to one side like a confused dog when I read that - this helped: https://en.m.wikipedia.org/wiki/Meta-circular_evaluator https://en.m.wikipedia.org/wiki/Meta-circular_evaluator
- hayley-patton 3y ago
  It's a Smalltalk implementation written in Smalltalk, which is designed to survive its internals modified at runtime, which is the "live" part. The paper exhibits conventionally tricky bits to modify like the garbage collector and compiler, and describes some performance regressions they found which they fixed using the liveliness of the system.
skybrian 3y ago
These are the traditional advantages of Smalltalk-like systems, and yes, this system is based on Smalltalk. There's a 2014 paper about Bee Smalltalk [1]. There's a Github repo [2]. There are no real docs and minimal comments in source control. Section 5.3.3 talks about some drawbacks, and there are more in "8. Conclusions" and "9. Future Work." > Today, Bee is far from finished, yet we know all required functionalities can be implemented. Furthermore, the resulting code is fully object oriented and can take advantage of all the benefits that a high-level environment brings. The main remaining question to be answered is what is the maximum performance to expect from the system. We believe that the answer to that question will be highly positive, and that we will be able to unravel the mystery very soon. ... > Current implementation of Bee is more than 10x slower than the hosted environment [...] So, interesting work in progress, maybe check back later? [1] http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_Design%20and%20implementation%20of%20Bee%20Smalltalk%20Runtime.pdf http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_Design%20... [2] https://github.com/aucerna/bee-dmr https://github.com/aucerna/bee-dmr
- igouy 3y ago
  > a 2014 paper about Bee Smalltalk Here's the pdf for this 2023 paper: https://arxiv.org/pdf/2312.16973v1.pdf https://arxiv.org/pdf/2312.16973v1.pdf
jauntywundrkind 3y ago
WebComponents are also nicely alive. Wish we saw some solidarity from other programming in an alive world/language of the gods camps.
mjburgess 3y ago
This seems similar to the technique popularised by Jai (jblow) and adopted by Zig -- making the compiler programmable in the host language, at compile-time. Here it seems this is happening at run-time by using an interpreted language. Nevertheless the reasoning they give is similar to why you'd want compile-time to be programmable, that the distinction between compiler and program is somewhat artificial and generally severely hobbles the programmer from being able to introspect their program (etc.). Given how Jai/Zig/etc. work, it now seems crazy that compiler authors have gone to extreme lengths to provide really-bad compile-time languages (called "type systems") that do 5% of what's useful with incomprehensible syntax, rather than just make the compiler itself programmable. This technique makes much of programming language design seem to be fumbling around in the dark.
- Ygg2 3y ago
  > really-bad compile-time languages (called "type systems") that do 5% of what's useful with incomprehensible syntax, rather than just make the compiler itself programmable. Because some things aren't knowable at compile time. E.g. what is the value I enter at runtime, and all values derived from it, but also state of environment, and so on. Pretending they are the same is a weak point of Zig. By making `const` a property determined by the compiler, you can accidentally introduce breaking changes, just by changing function contents. https://typesanitizer.com/blog/zig-generics.html https://typesanitizer.com/blog/zig-generics.html
  - mjburgess 3y ago
    I wasn't talking just about Zig's implementation of comptime, I was talking about collapsing the distinction between compiler and program -- if done well then the problems mentioned in that article need not occur. I think the key feature here is making compilation a program that you write wherein you can fully introspect your program. Worries here about IDE support fadeaway, as the full state of the compiler is available -- if some annotations on code are required to guide IDEs, so be it. I wasnt saying that type systems should be replaced with compile-time programs, only that they are compile time programs, and often really bad ones. (My claim: Programmers shouldnt only have the type system to program the compiler.) Better that the type system be extremely simple and let the programer transform their program as they wish.
s17tnet 3y ago
Pharo has this [0]. [0] https://pharo.org/features https://pharo.org/features
- igouy 3y ago
  Perhaps OpenSmalltalkVM only has some of this
mike_hearn 3y ago
That's pretty interesting. It's not as aggressive as Bee sounds, but the Espresso JVM is somewhat similar in concept. It's a full blown JVM written in Java with all the mod cons, which can either be compiled ahead of time down to memory-efficient native code giving something similar to a JVM written in C++, or run itself as a Java application on top of another JVM. In the latter mode it obviously doesn't achieve top-tier performance, but the advantage is you can easily hack on it using all the regular Java tools, including hotswapping using the debugger. When run like this, the bytecode interpreter, runtime system and JIT compiler are all regular Java that can be debugged, edited, explored in the IDE, recompiled quickly and so on. Only the GC is provided by the host system. If you compile it to native code, the GC is also written in Java (with some special conventions to allow for convenient direct memory access). What's most interesting is that Espresso isn't a direct translation of what a classical C++ VM would look like. It's built on the Truffle framework, so the code is extremely high level compared to traditional VM code. Details like how exactly transitions between the interpreter/compiled code happen, how you communicate pointer maps to the GC and so on are all abstracted away. You don't even have to invoke the JIT compiler manually, that's done for you too. The only code Espresso really needs is that which defines the semantics of the Java bytecode language and associated tools like the JDWP debugger protocol. https://github.com/oracle/graal/tree/master/espresso https://github.com/oracle/graal/tree/master/espresso This design makes it easy to experiment with new VM features that would be too difficult or expensive to implement otherwise. For example it implements full hotswap capability that lets you arbitrarily redefine code and data on the fly. Espresso can also fully self-host recursively without limit, meaning you can achieve something like what's described in the paper by running Espresso on top of Espresso.

89 points by mpweiher 3y ago

Recently, "Design Principles Behind Smalltalk (1981)", https://news.ycombinator.com/item?id=38821506 https://news.ycombinator.com/item?id=38821506

igouy 3y ago
Maybe there's something new.
- transpute 3y ago
  Smalltalk and Javascript? https://github.com/codefrau/SqueakJS https://github.com/codefrau/SqueakJS

CyberDildonics 3y ago

This looks like it is a small talk implementation with a lot of fancy nonsense terms to make it sound like it is something new. I've never heard the term "Live Metacircular Runtimes (LMRs)" but they seem to think they are improving on "classic metacircular approaches"

thomasjudge 3y ago
https://www.google.com/search?q=Metacircular https://www.google.com/search?q=Metacircular
danparsonson 3y ago
I did indeed tilt my head to one side like a confused dog when I read that - this helped: https://en.m.wikipedia.org/wiki/Meta-circular_evaluator https://en.m.wikipedia.org/wiki/Meta-circular_evaluator
hayley-patton 3y ago
It's a Smalltalk implementation written in Smalltalk, which is designed to survive its internals modified at runtime, which is the "live" part. The paper exhibits conventionally tricky bits to modify like the garbage collector and compiler, and describes some performance regressions they found which they fixed using the liveliness of the system.

skybrian 3y ago

These are the traditional advantages of Smalltalk-like systems, and yes, this system is based on Smalltalk. There's a 2014 paper about Bee Smalltalk [1]. There's a Github repo [2]. There are no real docs and minimal comments in source control. Section 5.3.3 talks about some drawbacks, and there are more in "8. Conclusions" and "9. Future Work." > Today, Bee is far from finished, yet we know all required functionalities can be implemented. Furthermore, the resulting code is fully object oriented and can take advantage of all the benefits that a high-level environment brings. The main remaining question to be answered is what is the maximum performance to expect from the system. We believe that the answer to that question will be highly positive, and that we will be able to unravel the mystery very soon. ... > Current implementation of Bee is more than 10x slower than the hosted environment [...] So, interesting work in progress, maybe check back later? [1] http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_Design%20and%20implementation%20of%20Bee%20Smalltalk%20Runtime.pdf http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_Design%20... [2] https://github.com/aucerna/bee-dmr https://github.com/aucerna/bee-dmr

igouy 3y ago
> a 2014 paper about Bee Smalltalk Here's the pdf for this 2023 paper: https://arxiv.org/pdf/2312.16973v1.pdf https://arxiv.org/pdf/2312.16973v1.pdf

jauntywundrkind 3y ago

WebComponents are also nicely alive. Wish we saw some solidarity from other programming in an alive world/language of the gods camps.

mjburgess 3y ago

This seems similar to the technique popularised by Jai (jblow) and adopted by Zig -- making the compiler programmable in the host language, at compile-time. Here it seems this is happening at run-time by using an interpreted language. Nevertheless the reasoning they give is similar to why you'd want compile-time to be programmable, that the distinction between compiler and program is somewhat artificial and generally severely hobbles the programmer from being able to introspect their program (etc.). Given how Jai/Zig/etc. work, it now seems crazy that compiler authors have gone to extreme lengths to provide really-bad compile-time languages (called "type systems") that do 5% of what's useful with incomprehensible syntax, rather than just make the compiler itself programmable. This technique makes much of programming language design seem to be fumbling around in the dark.

Ygg2 3y ago
> really-bad compile-time languages (called "type systems") that do 5% of what's useful with incomprehensible syntax, rather than just make the compiler itself programmable. Because some things aren't knowable at compile time. E.g. what is the value I enter at runtime, and all values derived from it, but also state of environment, and so on. Pretending they are the same is a weak point of Zig. By making `const` a property determined by the compiler, you can accidentally introduce breaking changes, just by changing function contents. https://typesanitizer.com/blog/zig-generics.html https://typesanitizer.com/blog/zig-generics.html
- mjburgess 3y ago
  I wasn't talking just about Zig's implementation of comptime, I was talking about collapsing the distinction between compiler and program -- if done well then the problems mentioned in that article need not occur. I think the key feature here is making compilation a program that you write wherein you can fully introspect your program. Worries here about IDE support fadeaway, as the full state of the compiler is available -- if some annotations on code are required to guide IDEs, so be it. I wasnt saying that type systems should be replaced with compile-time programs, only that they are compile time programs, and often really bad ones. (My claim: Programmers shouldnt only have the type system to program the compiler.) Better that the type system be extremely simple and let the programer transform their program as they wish.

s17tnet 3y ago

Pharo has this [0]. [0] https://pharo.org/features https://pharo.org/features

igouy 3y ago
Perhaps OpenSmalltalkVM only has some of this

mike_hearn 3y ago

That's pretty interesting. It's not as aggressive as Bee sounds, but the Espresso JVM is somewhat similar in concept. It's a full blown JVM written in Java with all the mod cons, which can either be compiled ahead of time down to memory-efficient native code giving something similar to a JVM written in C++, or run itself as a Java application on top of another JVM. In the latter mode it obviously doesn't achieve top-tier performance, but the advantage is you can easily hack on it using all the regular Java tools, including hotswapping using the debugger. When run like this, the bytecode interpreter, runtime system and JIT compiler are all regular Java that can be debugged, edited, explored in the IDE, recompiled quickly and so on. Only the GC is provided by the host system. If you compile it to native code, the GC is also written in Java (with some special conventions to allow for convenient direct memory access). What's most interesting is that Espresso isn't a direct translation of what a classical C++ VM would look like. It's built on the Truffle framework, so the code is extremely high level compared to traditional VM code. Details like how exactly transitions between the interpreter/compiled code happen, how you communicate pointer maps to the GC and so on are all abstracted away. You don't even have to invoke the JIT compiler manually, that's done for you too. The only code Espresso really needs is that which defines the semantics of the Java bytecode language and associated tools like the JDWP debugger protocol. https://github.com/oracle/graal/tree/master/espresso https://github.com/oracle/graal/tree/master/espresso This design makes it easy to experiment with new VM features that would be too difficult or expensive to implement otherwise. For example it implements full hotswap capability that lets you arbitrarily redefine code and data on the fly. Espresso can also fully self-host recursively without limit, meaning you can achieve something like what's described in the paper by running Espresso on top of Espresso.