My personal project can be found here: https://github.com/d-cook/Objects But is perhaps better described here (at the specific entry linked to in this URL): https://www.cemetech.net/forum/viewtopic.php?p=270092#270092

Interesting stuff. I've been following the SomethingNew collaboration as well. The blurb on Objects resonates well with me.

It's been hard to keep up with the flood of connections that came out from SomethingNew, but I've just rediscovered this space (thanks to Ellen Chisa of Dark (go check it out)), and it seems to be the most prominent & active community so far, so I'm hoping to be more involved here. I might just keep SomwthingNew as a catalog. Of the catalogs I've come across, I've found Ivan Reese's visual programming codex quite interesting and useful for discovering new things (it may be how I found Dark)

You seem to be describing a Smalltalk system :). You can already play with one at https://pharo.org. On top of that we built https://gtoolkit.com to enable the end user to put arbitrary interfaces on any object in the system. This creates a complete new experience through which you can both manipulate and understand the different parts through custom views.

(Note: I just made my final edit to previous)

The model of an Smalltalk system is not textual code. It's objects, and the compiled code is captured as objects as well. You are correct in that a key aspect of Smalltalk is to be bootstrapped and deeply reflective. Pharo is a Smalltalk, but its model is different from the original Smalltalk. For example, the AST is the key element. It can be annotated directly. The textual representation is an input format, but it is not an essential one from the machinery point of view. Glamorous Toolkit is a development environment that extends the base language with a visual and interaction language to allow you to construct custom visual representations while you are using the interface.

(continuing from previous) The semantics of the built-in interpreter / structural code are straight-forward: Since everything in the tool (and anything that could be in the tool) consists of the same structural elements, the only possible actions that the code can take, is all the operations that can be performed on those structural elements. At the most fundamental level that's the basic CRUD operations (set, get, has? / exists?, delete), and basic arithmetic and logical operations. Tada! ... Ok, so maybe it's not entirely straightforward, since there are limitless ways I could have chosen to represent such operations. But I will say that after exploring different approaches and trying hard to derive the simplest model, I essentially arrived (unintentionally, but seemingly inescapably) at the standard LISP representation. Put simply: * Anything other than a list ("array") evaluates to itself. * A list is evaluated by evaluating each item in it, with the first item being the operation to perform, and the remaining items being the arguments for that operation. * The interpreter knows NOTHING about which operations can be performed, and instead looks them up by name from some "context". * The interpreter can be invoked with different "contexts", which allows for context-specific code / DSLs Furthermore, the same set of operations can be invoked either by code or by user interaction. I've since started a new project, "Interact", which is essentially the same thing, but is starting with the UI and working downwards, whereas my "objects" project is working from the ground up. In my next reply, I'll say a bit about intentions for this tool

First, please do not apologize for making mistakes. We are all here to learn, and making mistakes is a natural part of that process. And in this case, please also consider that when someone does not understand an explanation, the main problem might lie with the explanation. The work of Alexander had quite profound impact on my thinking. Smalltalk is the closest high-level programming model to the living structure idea (the other one would be assembler): you can only change a Smalltalk system from within the system. This paves the way to fine grained piecemeal evolution and it offers the environment for unfolding wholeness. However, as opposed to the real world, where the physical shape is tied with the physical thing, in the digital world that constraint does not exist and we can take advantage of that. A related concept that I find fascinating is that of habitability, coined by Richard Gabriel in Patterns of Software (https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf): given that we spend most of our time inside a software system, it should follow that the software system should be habitable. Much like with the quality without a name concept of Alexander, habitability is not measurable. We need to feel it, and we recognize it when we find it. The way we feel about things is linked with the way we perceive, and the way we perceive is related to the shape of things. That is why I find the shape to be essential, in particular when it comes with software. From the outside, Glamorous Toolkit is a tool. However, we see it as a language with which you can mold that shape continuously, in an ever living structure.

Hi @Dan Cook, Thanks for the detailed response - the ideas are quite interesting and similar to things I've been thinking about. Sounds like you're working towards a VM environment that works with a structural substrate that is lower level than any specific programing language but higher level than byte arrays. This substrate can represent any (tree like?) structure, but the meaning of any depends on the context it is evaluated in. Also the structures could be visualized many different ways and visualizations could be shared between structures of many different kinds? Yes the ideas do have an overlap with the Smalltalk systems - they are VMs with persistent objects, as @Tudor Girba pointed out. Yet there are differences - it seems you are proposing the nature of the substrate is list/tree like, not classes/methods/objects? Also something like modeling a distributed app and then auto-partitioning it doesn't exist afaik. Yes, it could be built on Smalltalk but currently in ST the world you work with is still your local VM and nothing else. We'd need a network of VMs that can talk to each other easily and ship the software substrate around. Ideally this network would be presented as one unified world (MPORG style). Once you log in to this world, you have quick access to all the elements that exist and you could even 'view source' on any part of the tool itself to quickly jump to visualization (text or non-text) for the underlying structure that represents it. You could then modify it in place and publish it. Provenance on these elements would be automatically maintained. I don't think ST is quite there yet. For instance, how do you enumerate all the classes that exist? How do you create a new object? You can't just browse to a class and click a 'new instance' button - it takes a little reading, learning and writing code to do these things. Tudor said "the main problem might lie with the explanation" - this is true. But also do we need explanation? What does Pharo look like when you launch it? Does it even look like a collection of objects, or classes? Ideally the richer UIs would automatically be generated based on the structure they are trying to visualize, or some annotation (yes gtoolkit is getting closer.. 😄 ). Still, I think the biggest boost will come from this 'network of VMs' - we really want one shared world where we can easily share our ideas and artifacts. Consider how clunky it is to share a new class/object I create in ST compared to how easy it is to share a web-app that I publish. There are a lot of unexplored ideas here.

Thanks @shalabh, that was very helpful for understanding this thread.