Hiya - my latest article - "The Object Network for goldfish" - is out! https://open.substack.com/pub/duncancragg/p/the-object-network-for-goldfish?r=1sq2dz&utm_campaign=post&utm_medium=web I tried to simplify the message down to the bare minimum. Let me know if that works for you! You may have to be a goldfish to understand it, mind.

Sorry to sidetrack the thread, but since the target audience for this is goldfish 😄 • I start reading and hit this dialog from Substack (attached) • Most people probably just hit 'continue reading' and keep going, but I have JavaScript disabled by default so that link doesn't work. • I would just enable JavaScript for your site (unfortunately I can't enable just that Substack dialog on all Substacks) but I'm trialling Vivaldi (don't ask) and its flow for adding JavaScript exceptions sucks. • I wonder if there are any new stories about that Cricket World Cup semi-final India just won.. So this is the modern web for you. Lessons from me won't apply to 99% of your audience. But for a technical topic you probably have 50 niches like mine in your audience. My response tends to be own my own site for long form[1] so that no random fuck sociopath can interpose JavaScript on my webpages. But then yes you're stuck figuring out email distribution. On balance I still like POSSE. When people fall off my funnels I want it to be because of my mistakes, not noise from misaligned incentives. [1] Lest I seem to be taking moral high ground here, it took me forever to get rid of Disqus.

All brightly coloured fish are very welcome in this thread, Kartik. I don't do sport but, .. what was it you were asking?? There's a new version of that thing out, you know Oops! Forgot to post this reply, sorry, here it is

Re JS: I've only been doing it for a couple of years. Eventually things turned to shit enough that I got over even that cliff of an energy barrier.

Sandstorm.io had an interesting model of this with object capabilities. Basically an app could do no IO on its own and had to be granted permissions to individual objects (a single file, a connection to a server)

Capabilities are very nice indeed, but they don't quite solve this problem. To be precise, the problem in my mind is this: it's 1996 and we're starting to use computer networks in a big way. What can we do to keep the initial egalitarian distribution of data sinks from agglomerating into giant data black holes (that are by definition unaccountable)? It's not sufficient to fight the last battle, but here it feels necessary. And I don't think capabilities help in isolation with this problem. I actually have no technical ideas that would help here in the absence of a more thoughtful populace. Technical tools can actually be counter productive by encouraging complacency in people. I half think we should all just go back to traditional websites. Spread the word: just everybody go seek out websites where you know the operator well, they don't seek VC funding with its incentives to go chase tons of adoption, maybe everyone even has the keys to share and export data, etc. If you can't find one, start one. If you can't start one, wait. That feels like the strong competitor to compare any solution with here. Does any technical solution actually do better if we have this social context? Can it possibly help if we don't have this social context? Sometimes you have to choose short-term pain to preserve long-term agency. Doesn't sell well, but this is the truth.

@Kartik Agaram Some of what you talk about around Craggfish code vs goldfish code will be covered in the same bulletpoint manner in Part 2, but I've also covered it already in Turning the Blob inside out, where I basically answer the question "where does all the app functionality go?" The question of sucking data back out and trapping it via hostile code boils down to permissions and choice. Permissions - they can't do it without your permission. Choice - well it's up to you if you want to do that, I'm not stopping you. Thanks for the links, I'll look at them, apart from the Solid one, which isn't really related. Yes, you have online hosting for your data, which does bring in a little trust element, which I suppose is fine. Plus you have more control over it, which is good. I recall data is in standard types, which is also good. But there's still the whole "inert, zombie" data aspect - data is lifeless until animated by some app, probably a browser app, which is right back to the same problem of app inscrutability.

I don't fully understand your concepts, but it reminds me of https://en.wikipedia.org/wiki/Soup_(Apple), little databases that any app could read and write. https://en.wikipedia.org/wiki/Soup_(Apple)

@Mike Austin @Kartik Agaram - more thoughts on Solid and Soup. It's true that a decentralised database with standard data types - something like Solid/Soup - fixes the issue with apps that they often store stuff in proprietary formats and/or on their hidden databases. Which is a huge win for freeing data. So imagine a collection of to-dos and a collection of events. And then you have your to-do app and your calendar app, because even though our data is "free", it's still not accessible except through an app. But now you're juggling apps again, with their idiosyncracies and tendency to want to be THE app for each data type. But each app has access now to the other's data. So the calendar can reference to-dos and the to-do list can reference events. Indeed, Wikipedia tells me that in Soup: the "calendar could refer to names in the address book; a note in the notepad could be converted to an appointment". So we've got an odd situation, as you don't need two apps, really. Why not just make the calendar better and better at to-do lists, and notes? Now you get cross-type UX without app-flipping and having to re-learn each app. This can be extended across the full range of types that Tim BL has in his Pods, or Apple had in their Soups. One app can be used for all data types, giving a cross-type consistent UX experience, where building up data from mashing up different types is core to the experience and designed to be as smooth as possible. Indeed, if you've only got one app, why not just call it the OS? Which brings you to the Itemized OS idea of Obenauer, and my own OS with no apps. So Newton's OS could have just skipped the apps and done it this way. And Obenauer could look at building his OS on top of Solid!

I like it. Put it on your blog! To be clear, I understand this angle is not the entirety of what Onex/object.network is about. It's just the side facing the camera in your post. You're approaching the conversation from an interesting perspective.

Thanks! 🤗 Yes this is just a part of the whole, but it all hangs nicely together. Either look out for Part 2 or the existing articles do cover most of it. The next step after the above is where I move what was the apps' internal logic - the bit where you need an app to "animate" each type of the zombie inert data in the database - into the data objects themselves, so that they become "internally animated".

"Why not just make the calendar better and better at to-do lists, and notes" - I don't understand this part. You want a monolithic application that tries to be everything, badly? The todos and calendar UIs don't need to be apps, they can be components that apps use. Somewhere to store the data, and some UI to manipulate the data. Apps in this sense are just there to glue components together to make a larger, more specific UI. OpenDoc comes to mind. https://en.wikipedia.org/wiki/OpenDoc

@Mike Austin thanks for the challenge - I really enjoy getting all this kind of feedback to help me firm up the ideas! > You want a monolithic application that tries to be everything, badly? The todos and calendar UIs don't need to be apps, they can be components that apps use. Somewhere to store the data, and some UI to manipulate the data. Apps in this sense are just there to glue components together to make a larger, more specific UI. I want an OS that recognises very common types: little types like to-dos and events and contacts and paragraphs. Then there are two parts: the internal logic of those little types, and the way the OS renders and enables interaction with them. You can build "apps" out of assemblies of all that. Oh! We agree! Perhaps the implementation or architecture is where we don't agree. I'm suggesting doing this in a declarative way, not an imperative way. OpenDoc, CORBA, Module Federation, etc., are imperative solutions. A declarative solution is more like transclusion (iframes, sorta) and being driven by a data-dependency model (observe don't command) all the way from front to back - and sideways to other systems.

Hi @Duncan Cragg, Love your ideas and the exchange here. Something I'm working on feels like a nice fit to your ideas. I'll just describe it here and see what you or others have to say. I'm working on a new programming language. One with few and simple rules. One with little to no syntactical sugar (we all know by now that sugar is bad for us). It is based on the notion of Things (you could call them objects) having Behaviour. Things can have Pockets (you could call them slots) to store stuff in. What is interesting is that Things can receive or drop Behaviour dynamically (you could say it has NO class hierarchy). Using this dynamic Behaviour allows for having (adding) Behaviour in specific contexts. If you put a Thing in a calendar it might receive an 'OnDate' or 'AtMoment' Behaviour. This Behaviour could have a Pocket in which a category (or other text) is stored describing what that date or timestamp means to the Thing. Like it could be a deadline or a birthdate. (If the Thing already had 'OnDate' Behaviour, none would be added or the calendar would ask if it should use that behaviour or add a new one.) A Thing might be visible in the calendar on multiple dates. All with their own relevant information. And when you want a notification prior to some date or timestamp, you could add a 'Notifier' Behaviour to that Thing. This Behaviour would require some 'OnDate' or 'AtMoment' Behaviour is present (which the Notifier could check for or add). It would have a Pocket holding the duration before the date or timestamp before it would start the actual notification. And so forth. Every Thing can have a default Behaviour for displaying and interacting. A sort of generated User Interface (created using reflection mechanism). But specific displaying and interaction Behaviour can be added as well. Typically UIs could be described using some dimension as guideline. Allowing different UIs based on the dimensions (but also device) available. This does not only allow for mobile vs desktop UIs, but could also allow embedding Things in the UI of other Things. Like a Thing in a (typical matrix-like) week-view within a calendar could display only a few items like a title or so. When the same Thing is displayed in a day-view, it could show much more information. Or when it is shown on its own it could provide a full interface with access to all information. Typically the idea of interacting in the User Interface (for the desktop) is by simply clicking on Things, dragging/dropping Things (to make Things connect) and by having buttons represent actions on the Things. All editing (on text fields for example) is direct. No need to first go to an 'edit' mode. Changes are saved automagically. Undo is (should be) a primary feature. More elaborate UIs can be created, but chances are they will also limit the ability to interact with the rest of the environment and create an app (kind of thing) within a app-free environment. Hope this longish description makes sense. The language itself will look very much like Smalltalk (syntax wise). It also is based on the idea of message sends (Alan Kay's explanation). Like Actors, Things can implement their own way of handling messages they receive. The default being to find a method with the same 'selector' as the message being sent and then executing it. But queueing could be added as a Behaviour. Onto which prioritisation could be added as a Behaviour, etc. The laguage will be (again like Smalltalk) very late bound and without explicit type checking. If a message is not understood, a Thing will say so. And allowing Behaviour to override this (again like Smalltalk). The language would ideally be run in a live environment (again like Smalltalk). This would allow debugging and adding Behaviour (even more) dynamically. Within the OnexOS I could see this as a means of allowing you to manipulate every Thing directly. No need for doing a compile and deploy run. Of course with great power comes great responsibility. You could kill your OS in seconds. There are ways to prevent doing this accidentally, like you could have a 'door' or something you have to open first, before reaching the delicate or 'dangerous' stuff. The door gives a clear description of the risks you are taking. But please, let's not dumb people down or scare them away from trying things out. A good 'undo' feature is maybe the required solution for this. Once people learn to try things out and not be afraid to ruin things, creativity can flourish (like crazy ;-). Besides the evident Smalltalk, ideas and inspiration have come from Actors, DCI (Data Context Interaction), Expressive Systems and Worlds (to name just a few). Below are some links. I also added a link to a demo I gave (together with my business partner) which represents some of the ideas for a UI (at that time still in pilot stage). Aside: I definitely need to work on my presentation skills...ouch... So much more to say, but leaving it at this for now. [Expressive Systems] - [DCI] - https://dci.github.io [Worlds] - https://tinlizzie.org/VPRIPapers/tr2011001_final_worlds.pdf [Pilot implementation UI] - https://vimeo.com/719355883#t=515s

Wow, hope it's OK if I take a bit of time digesting all that! 😮 I'll get back on here soon ......

No worry, no hurry.

"soon" may be tomorrow as I have to get off the laptop right now ....... 😄

Ahhh…the missus (or kids) want your attention. Have a nice evening!

Right, hectic day yesterday but I've finally read your stuff up there in the thread, scanned your website, and watched (some of) the video! Apologies for going quiet a bit there... Did you see the thread on Smalltalk recently? I'll see if I can post a link here. Given how close the idea is to some of the ideas of Smalltalk and Naked Objects, you may consider perhaps - first having a website for it! then - giving us 3 bullet points for how it differs from each of those. Having said that, maybe many in the community don't really know much about Smalltalk and Naked Objects!

That helps! I did read the first part of the thread while it unfolded, but somehow missed the latter part. Read up on them. Seeing your perspective on imperative vs declarative and fully freeing the data, will not bring sparkles off joy to my explanation of another (imperative) language. That's fine. I'm interested how (dare I see what?) a language would look like that is declarative and allows to work on all different kinds of data. Do you have any language in mind (the mentioned examples of regex/sql/css don't seem sufficiently usable)? A declarative language can only work (I think/suppose) when there are very strict rules underpinning the model/world it is concerned with. What would this model/world look like and which rules are there? I'm thinking of objects with identity, being 'linkable', but that's very abstract. I'm mulling on the imperative vs declarative discussion. Interesting thought work...thx I think this is the link you searched for, but the substitute works fine as well: https://futureofcoding.slack.com/archives/CCL5VVBAN/p1698926074657699

How did you get that link?? I see that it screws the URL over when you load the page, so I may have found it, tested it, then grabbed it again from the URL bar, instead of using the original one. Anyway, detail, detail...

Ahhh...missed that one. Reading it now...almost...I should prep diner....aaarghhh...

EEeeeaaattt! 🥫 🌽 🍄 🌾 🌰 🍅 🍆 🍔

Interesting examples Duncan! I like them. Wondering how things might get combined, although I get the feeling you would like to stay away from such a situation. At some level you probably need to specify the Object/Link/Rule behaviour in a more imperative way. My ideas with respect to the new language (model) would certainly include that Pockets (slots) are always accessible. Thereby allowing data to remain free. Security, like access control, should be built in on another level. Might be less secure approach, but I'm favouring flexibility and having full 'control' (freedom?) over strict access. So with the free data access and dynamically adding behaviour, a user model could be created which matches your ideas. Maybe I'll give it a spin (one day, when I actually implemented the language from all the notes and design thingies I created over the past months/years ;-).

Thanks for taking the time and trouble to take a look at the slides. I hope they made some sense. I'm struggling with understanding: > Wondering how things might get combined, although I get the feeling you would like to stay away from such a situation. Can you elaborate on "combined" and the "situation" I would avoid?! > At some level you probably need to specify the Object/Link/Rule behaviour in a more imperative way. On the "level" that would need to be "imperative": yes internal default hard-coded behaviours are written in C! Is that what you meant?

Quick reply: exactly what I meant. And thus both seem necessary. I thought you wanted only declarative. But understand it now. I personally would not mind a more mixed solution. Where users can also use an imperative model.

Oh, no, users don't write imperative code - imperative C for coders, declarative Onex for normies!