https://futureofcoding.org/ logo
#share-your-work
Title
# share-your-work
d

Duncan Cragg

07/04/2023, 2:39 PM
Hiya - I've got a new article in my Object Network "Lab Notes" Substack: https://duncancragg.substack.com/p/a-3d-operating-system-without-apps It would be great if you find it a stimulating read and dropped in some comments on the page!
... or subscribed of course!
k

Konrad Hinsen

07/05/2023, 7:45 AM
You say that there a no apps in the real world. Not sure I agree: I see apps as virtual tools, but tools that have grown too large and constrain their users rather than empowering them. There's a story by Cory Doctorow, about toasters that will accept only "authorized bread" (https://www.defectivebydesign.org/blog/doctorows_novella_unauthorized_bread_explains_why_we_have_fight_drm_today_avoid_grim_future). That's what apps would be like in the real world.
i

irvin

07/06/2023, 4:11 PM
In your example do you see things like the calendar and the to-do list as being governed by separate programs/pieces of code and using physics simulation as a sort of implicit API through which things interact with each other? It kind of makes me think of this quote from the matrix But… look- see those birds? At some point a program was written to govern them. A program was written to watch over the trees, and the wind, the sunrise, and sunset. There are programs running all over the place. The ones doing their job, doing what they were meant to do, are invisible. You’d never even know they were here.
d

Duncan Cragg

07/06/2023, 7:48 PM
@Konrad Hinsen: That's a really good point, and I completely agree about "grown too large and constrain their users rather than empowering them", but it's way worse than that excellent toaster example: what I'm describing is a virtual world where, if you tried to remove the toast to eat it, it turns to cardboard! You can only eat it by placing your face up to the toaster's Consumption Panel. Taking it further, and back to the Canonical Tool - the hammer - and the Canonical Stuff - the nail. Now, not only does the nail only allow itself to be hammered in by its very specific hammer, but the hammer has to stay in the room, or all the nails turn to cardboard, and your furniture collapses. In this app-trap-tool world, only the specific tool gives you access to the "stuff" and animates the properties and behaviour of that stuff, in all contexts. Some stuff can sometimes actually be animated by multiple app-tools, but you still have the same dependency, the same trap replicated, and random stuff can't mix with random other stuff. Outside of their tool, stuff turns to useless "cardboard" - also know as inert "files" or "export dumps" in the app-based world of computers. In our physical reality we know that tools are made by tools and so are "stuff" while that happens, that non-tool stuff can be repurposed as tools, and so on. There's no significant difference in the real world, except sometimes in our minds, between "tool" and "stuff". We can hammer in a nail with a rock, then use a wheelbarrow to carry a load of rocks that the wheelbarrow-maker never even imagined. We can pull out the nail at any time in the future and use it as a tool to dig out some dirt from a fence panel. Everything is remashable in any way that works.
@irvin Thanks for the Matrix quote - yes that's a good description of what I mean by "internally animated". You can have animation code written in C or Python if you like, or something like spreadsheet formulae, or Realtalk. Objects interact not always or specifically through physics-based simulation, although that's a very likely medium, but simply through the "API" of mutual current-state awareness, which is basically how I believe reality works. It doesn't need to be 3D or physics state, but can be 2D current state too. So if you attach a to-do to a calendar in 3D, there's a physical proximity and possibly a physics interaction, which is kinda lower level, and involves structural links between them, in the scenegraph. But you can also have what I call "semantic links", which go up the abstraction levels. So the to-do may know what it means when attached to a calendar event - e.g., it now knows when its job is due to be finished, etc.