111–120 of 154 posts
Earlier quoted context omitted.
There are Lisps with similar semantics. It faded (further) out of popularity for a number of reasons, but it still has its niche.
Which Lisps were those? I'm kinda interested in this space.
Just like learning Lisp will make you rethink programming languages, and learning Erlang will make you understand the true power of concurrency: learning Smalltalk will make you understand what "object oriented" actually means. I haven't used Squeak since college but I'm glad it was part of the cirriculum. Btw, almost all of Javascript's good parts come from Smalltalk.
For me, Smalltalk's "wow" moment was the concept of a persistently running image, with the developer's job being to mould and manipulate it into the shape s/he wants.
or my language https://github.com/timbran-project/mica
Just like learning Lisp will make you rethink programming languages, and learning Erlang will make you understand the true power of concurrency: learning Smalltalk will make you understand what "object oriented" actually means. I haven't used Squeak since college but I'm glad it was part of the cirriculum. Btw, almost all of Javascript's good parts come from Smalltalk.
For me, Smalltalk's "wow" moment was the concept of a persistently running image, with the developer's job being to mould and manipulate it into the shape s/he wants.
Earlier quoted context omitted.
For me, Smalltalk's "wow" moment was the concept of a persistently running image, with the developer's job being to mould and manipulate it into the shape s/he wants.
NixOS is kind of like that, the image being the environment you end up with running the system. Difference being you tend to edit the source code of small programs passing/transforming data, package manifests and definitions in NixOS, instead of using the "Inspector" to find and browse live Objects of the image/system and figuring out what comes from where, then running things in the REPL to edit them into the right…
Just like learning Lisp will make you rethink programming languages, and learning Erlang will make you understand the true power of concurrency: learning Smalltalk will make you understand what "object oriented" actually means. I haven't used Squeak since college but I'm glad it was part of the cirriculum. Btw, almost all of Javascript's good parts come from Smalltalk.
For me, Smalltalk's "wow" moment was the concept of a persistently running image, with the developer's job being to mould and manipulate it into the shape s/he wants.
Earlier quoted context omitted.
For me, Smalltalk's "wow" moment was the concept of a persistently running image, with the developer's job being to mould and manipulate it into the shape s/he wants.
Ive always "dreamed" of having something like the ST image but backed by persistent virtual memory, not simply RAM. (Crudely) mmap the ST image to a 100GB file and just change pages. Let the OS flush the pages back and forth. Maybe full boat, heap sweeping GCs would be Bad as it pages the entirety of the heap in and out. But we have (had) lots of RAM these days. We have generational GCs that leave idle stuff alone. I…
The core pattern was that the Proxy, which was under Nil and above all other Objects regarding inheritance I think.
It re-implemented `doesNotUnterstand:` by: 1) First loading the actual object from the persistent storage and 2) sending the not understood message to the actual loaded object (which might be able to answer the message instead of calling `doesNotUnderstand:` for every message, like Proxy did.
There where if course optimisations and so on, but that was the gist of it.
What I really like about this system was that it was completely transparent to the sender of the message whether they were talking to a proxy, or the already-loaded object, all while being robust, easy to maintain and so ob. Dealing with collections was tricky though (how much to load at once? what about searching for a particular object?...), and would have been aswell for deeply nested object (which they successfully avoided though because as a SaaS-company, they could model the data exactly to their needs).
Earlier quoted context omitted.
Ive always "dreamed" of having something like the ST image but backed by persistent virtual memory, not simply RAM. (Crudely) mmap the ST image to a 100GB file and just change pages. Let the OS flush the pages back and forth. Maybe full boat, heap sweeping GCs would be Bad as it pages the entirety of the heap in and out. But we have (had) lots of RAM these days. We have generational GCs that leave idle stuff alone. I…
I'm also interested in this and made decent progress on a git-style content addressed image where everything is identified by hash and residency determines what's in memory. For example, there's a filesystem on the image that works this way and you can page over the "cold" non-resident bytes for very large files that you would not want to hold in memory. You don't persist the state of the full image continuously to t…
Just like learning Lisp will make you rethink programming languages, and learning Erlang will make you understand the true power of concurrency: learning Smalltalk will make you understand what "object oriented" actually means. I haven't used Squeak since college but I'm glad it was part of the cirriculum. Btw, almost all of Javascript's good parts come from Smalltalk.
Lisp, Forth, Erlang, Smalltalk, and Rebol, so easily forgotten. All languages that multiply your insight into the nature of computer programming. A bit sad that many just stop at the first of these, and many more don’t even venture past their Pythons and Javascripts.
Earlier quoted context omitted.
> almost all of Javascript's good parts come from Smalltalk Is this underselling the role of Self in JS’s prototype-based object system, or saying that a prototype-based object system is not one of the good parts?
Prototypical inheritance has caused so many, many vulnerabilities...
Earlier quoted context omitted.
For me, Smalltalk's "wow" moment was the concept of a persistently running image, with the developer's job being to mould and manipulate it into the shape s/he wants.
NixOS is kind of like that, the image being the environment you end up with running the system. Difference being you tend to edit the source code of small programs passing/transforming data, package manifests and definitions in NixOS, instead of using the "Inspector" to find and browse live Objects of the image/system and figuring out what comes from where, then running things in the REPL to edit them into the right…
NixOS by contrast takes the entire Linux userland and makes it an immutable, dead compiler artifact. So it is to debian like C or Rust are to Lisp.