๐ New Jersey Cards: Worse Cards are Better
Simple textual format to keep practice notes.
๐ Capture & practice content in Markdown-ish
๐ผ Extensions to display guitar chords and music scores with ASCII-art
๐ Runs on anything that can serve static files
๐ฅ New Jersey Cards
Hiya - my latest article - "The Object Network for goldfish" - is out!
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.
๐ The Object Network for goldfish
An OS with no apps frees our data from the "app trap"
My customary warning for techies: I use the word "object" to mean "chunk of data" because English is apparently short of suitable words that mean that kind of thing.
Sorry to sidetrack the thread, but since the target audience for this is goldfish ๐
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
Yes Substack is super annoying, when I wget --mirror my site I have to view the result without JS on
And yes I hate those stupid pop-ups. But it comes down to email and general ease for me. Which is bad, I know
I'm a lazy bugger, as my stepfather would say.
Did I tell you about Pete? He made little boats
By the way, I think you're a very odd fish if you don't have JS turned on. That's mental.
What's it like? I haven't done that for decades.
I'm looking at POSSE but can't for the life of me remember why.
What was your name again?
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.
Writing that comment did keep me from forgetting to open the link on my computer rather than my phone. So here's a substantive reaction to the post: where does the code for your OS with no apps come from? Do you write it all yourself? Do you expect your goldfish to fill in any gaps themselves?
If you provide any way for new code to enter your OS, how do you keep this third-party code from taking people's calendar and todo list data out of your OS? Because if you don't, then they'd take the data out and provide a better experience on their server, and then people would ask you why your OS doesn't provide a web browser, and then you'd give them a web browser, and then they'd live within the web browser where each tab traps their data.
This isn't an insurmountable problem, but it is an unsolved problem. There's some discussion about possible solutions:
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)
And everything was passed in in a sort.ofninversiom of control
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 en.wikipedia.org/wiki/Soup_(Apple), little databases that any app could read and write. 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".
In the Solid model, you'd have Pods running this internal logic so things online can be alive and interact over the net without an application running on a browser, etc., to activate them.
"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. en.wikipedia.org/wiki/OpenDoc
Some other old tech/new tech that comes to mind: en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture. medium.com/@samho1996/microfrontend-with-module-federation-in-react-98b72b347238. "Module Federation is a system that allows you to use parts of an application in another application without having to import the entire application", so that you don't necessarily need to write "libraries" or "applications". The module can be both.
There was some interesting tech back when, but it was too complicated, and/or people couldn't agree on standards and it didn't get anywhere.
@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.
it was too complicated, and/or people couldn't agree on standards
The business drivers and imperatives (ha! funny how it's the same word!) wouldn't allow a declarative, app-free solution. Data is the new oil and all that. Which is why the original declarative Web of HTML and later CSS had to be inverted back to a JS-dominated imperative model
Future of Coding โข Episode 68
Philip Wadler โข Propositions as Types
๐ถ futureofcoding.org/episodes/068
The subject of this episodeโs paper โ Propositions as Types by Philip Wadler โ is one of those grand ideas that makes you want to go stargazing. To stare out into space and just disassociate from your body and become one with the heavens. Everything โ life, space, time, existence โ all of it is a joke! A cosmic ribbing delivered by the laws of the universe or some higher power or, perhaps, higher order. Humanity waited two thousand years, from the time of the ancient Greeks through until the 1930s, for a means to answer questions of calculability, when three suddenly arrived all at once:
Then it was discovered that these three models of computation were, in fact, perfectly equivalent. That any statement made in one could be made in the others. A striking coincidence, sure, but not without precedent. But then it was quietly determined (in 1934, again in 1969, and finally published in 1980) that computation itself is in a direct correspondence with logic. That every proposition in a given logic corresponds with a type in a given programming language, every proof corresponds with a program, and the simplification of the proof corresponds with the evaluation of the program.
The implications boggle the mind. How could this be so? Well, how could it be any other way? Why did it take so long to discover? What other discoveries like this are perched on the precipice of revelation?
Philip Wadler is here to walk us through this bit of history, suggest answers to some of these questions, and point us in a direction to search for more.
And we are here, dear listener, to level with you that a lot of this stuff is miserably hard to approach, presented with the symbols and language of formal logic that is so often inscrutable to outsiders. By walking you through Wadlerโs paper (and the much more approachable Strange Loop talk), and tying it in with the cultural context of modern functional programming, we hope youโll gain an appreciation for this remarkable, divine pun that sits beneath all of computation.
I have been blasphemed! I did not need to be censored! Ivan Reese is lying to you with his edits. Do not believe him. Hear with your own ears:
๐ certain_words.m4a
Look at how he manipulates us all! Do not be fooled into action by his duplicitous, underhanded provocations. See clearly that he has played me like a puppet, and performs for you even now. Pull the wool from your eyes, he is more than the creator of sufficiently evil compilers, he isโฆ a neurolinguistic programmer!
