This comes across like someone's PhD project. It's unclear from reading the website what this is useful for and what it actually is.
But the more interesting bit comes from how you can extend the environment to make it fit the context of your problem. For example, a prominent way to extend is by creating contextual inspector views for different objects.
When taken as a whole, we end up with a new kind of a development experience that is centered around contextualizing the environment as part of development. It turns out that this is applicable to a wide range of problems.
For example, the talk video from the page shows examples from several domains: - it starts by browsing the file system of a React project and then querying the external dependencies from a package.json - then it goes into static analysis of React components and their dependencies - then it shows how to explore the data of a REST API and document its usage - then it goes to work with GraphQL and show how to combine it with imperative code to explore data; and even here, we go a step deeper and answer the question of how the tool worked (i.e., what query was sent to the server when we do not specify pagination completely) - then it shows how we can work with Python by extending the inspector with Python code - then it shows how we can also change the editing experience as well and make it contextual - then it shows how we can document a domain model through executable examples that when combined with contextual views become documentation - then it shows how to work with the knowledge base and even post live to a social media from it through a dedicated snippet - then it shows how we can explain a Docker setup and how the commands were derived from templates - then it shows again social media interactions but this time by browsing posts in inspectors and querying the feed live - and finally it shows how we can have a dedicated editor for configurations defined in JSON that know how to highlight, complete and navigate based on the schema information
Now, these are not features; they are just some ways you can use the environment for without the need for switching. The book from the environment shows even more such examples for inspiration. Each of these might look similar to some tool somewhere, but the possibility to have all of them in the same environment made out of the same pieces combined in many ways is the differentiator.
Does this help in any way?
My main reservation, at least initially, was that the website comes across too focused on the paradigm for its own sake. Hence my comment - it feels like a PhD project trying to project complexity and impressiveness. Personally I would have appreciated more focus on what it is, and why its useful, not an abstract framing of "moldable development". I hope that's not too harsh - just wanted to give my 2c honestly.
The problem is that for any given problem, there might be some solution out there that does something like it. Except that there is no solution anywhere in which you can do all of these. So, we are showing Moldable Development because that is the goal and that is the proposition of the technology. I believe that masking it as something else would not be particularly useful.
We understand that at this point in time, most people do not look for Moldable Development. Most people will consider it once others have taken it and create large value with it. So, right now, we are interested in finding those people because they will convince everyone else :).
If you want to learn more about Moldable Development, take a look at the book I am writing in the open with Simon Wardley: https://medium.com/feenk/rewilding-software-engineering-900c...
The goal was to explore the idea of contextualizing our tools for each development. It is built in Smalltalk (and Rust underneath) because Smalltalk already has the possibility of a live environment that can be changed from within. This allowed us to explore the space at much lower cost. Glamorous Toolkit is the result of that.
Thank you for the kind clarification. Indeed, it describes my intent quite well. Thank you for taking the time to describe how it is perceived from your point of view. I hope this is useful for the initial recipient as well.
We chose Smalltalk because we could not have discovered the space (what we now call Moldable Development) within the constraints we had.
p.s. I learnt in the meantime that it's possible to downvote somehow (I still do not know how). But in this case, I actually upvoted you.