It's fairly abstract, but I like it as described. Specifically:
1. As proposed it's working mostly at the OS level. That means it should largely work with all the languages and tools people are already used to. Lots of concepts like this expect everything to be recreated from scratch.
2. It doesn't fall into the devops approach of formally specifying a container and then building it. That makes sense in prod environments, but here it looks like you are encouraged to just do what you want to do and the system can track the results.
3. I guess file I/O is an okay abstraction? The example of writing to /people/robin/inbox makes me expect that it will be easy to add new filesystems (since a generalized messaging systems seems like overreach), so I imagine creating interesting little components exposed to the filesystem. That's friendlier than APIs. Also filesystems enforce a regular metadata system (paths) and encourage read/write APIs, both of which are great features for exploration.
I don't really get the DOM references. Trees are a pain in the ass. I prefer thinking of file paths as somewhat opaque strings instead of hierarchy.
Using namespacing for anything useful is also questionable to me, because it's so hard to know where the namespace is defined, where it is consumed, how you might override that, and what overriding a namespace actually means – if it means changing code then changing a namespace reference changes the referencing namespace, and it all starts exploding.
The really interesting question here is how REAL I/O works. Like, how do these sandboxes talk to the world? A sandbox on its own is kind of boring. How does it talk to a real screen, a real mouse, to the network, to a browser, to a database? And can we make these things easier and more playful? Glitch.com is cool, but if you want to use any of these more persistent or external services it still feels like becoming a sysadmin.
1. As proposed it's working mostly at the OS level. That means it should largely work with all the languages and tools people are already used to. Lots of concepts like this expect everything to be recreated from scratch.
2. It doesn't fall into the devops approach of formally specifying a container and then building it. That makes sense in prod environments, but here it looks like you are encouraged to just do what you want to do and the system can track the results.
3. I guess file I/O is an okay abstraction? The example of writing to /people/robin/inbox makes me expect that it will be easy to add new filesystems (since a generalized messaging systems seems like overreach), so I imagine creating interesting little components exposed to the filesystem. That's friendlier than APIs. Also filesystems enforce a regular metadata system (paths) and encourage read/write APIs, both of which are great features for exploration.
I don't really get the DOM references. Trees are a pain in the ass. I prefer thinking of file paths as somewhat opaque strings instead of hierarchy.
Using namespacing for anything useful is also questionable to me, because it's so hard to know where the namespace is defined, where it is consumed, how you might override that, and what overriding a namespace actually means – if it means changing code then changing a namespace reference changes the referencing namespace, and it all starts exploding.
The really interesting question here is how REAL I/O works. Like, how do these sandboxes talk to the world? A sandbox on its own is kind of boring. How does it talk to a real screen, a real mouse, to the network, to a browser, to a database? And can we make these things easier and more playful? Glitch.com is cool, but if you want to use any of these more persistent or external services it still feels like becoming a sysadmin.