New Substack post: https://frest.substack.com/p/composition-to-the-rescue

I tend have the opposite take: https://merveilles.town/@akkartik/113755999123116123 The hard problem is not composing software. We are in the world we're in because of everyone's attempts to compose software. No, the hard problem is defining boundaries on composition that allow any piece of software to quickly and efficiently decide whom not to compose with. And that's a big unsolved problem.

In my world, software will be built in such a way that you will have fine-grained control over every significant call. If your errant app was a Frest app, you would be able to just redirect that call to do something different, or nothing at all.

What is the fine-grained control that is lacking atop today's platforms? It seems to me that every single platform in the history of the world has said, "here you go, green fields, rock out, compose away!" And mess inevitably ensues. Because lots of different people come and do things that don't compose with each other. Even if you as the platform don't prevent them in any way.

I won’t necessarily make working out what is the problem any easier. But it does give you a fine-grained ability to intercept and change the dependencies of the software you’re using. Everything has an address, and you can drill into the set of calls that led to anything and change it for next time, copy it and make a “like that, except”, rewind and replay it if that makes sense. So you would be able to replace the dependency of your app on the call that checks for the wifi with one that does nothing, or one that caches the wifi status and only actually checks once every ten minutes, or whatever you like. I’ll be writing another blog post laying out how this works soon.

@Guyren Howe interesting stuff! > - Every piece of data has an address, but what you see at that address depends on who you are > - Everything you see always has a useful, relational, searchable UI > - Security isn't a bolt-on feature but emerges naturally from how things compose > - Functions are just relations waiting to be filled in > - Everything is a query, and every query can be changed I am actually building in a similar direction. It won't be relational at the core, but relations can be built. Excited to see what comes out of your work!

I like the manifesto overall, but this part makes me a little nervous:

Every piece of data has an address, but what you see at that address depends on who you are

If there's code running checks on my identity before returning the "data" at that address, I'm uncomfortable calling it "data". There's necessarily conditional code involved, which is as close to a hard distinction between "data" and "code" as you're likely to get. Meanwhile, the possible variants returned from that address don't themselves have separate addresses, so it's hard to say that "everything" has an address. I think I know what you're going for and generally don't hate it (I have vaguely similar ideas), so maybe this is just a nitpicky request to be more careful about terminology. I feel it's fine if you just say something like all state is in a database, that can present different views to different principals if needed. And within each principal's view, everything they can access has an address.

It’s a simple and pragmatic idea: pervasive application of Row Level Security. One of the main ideas is that any user of the system should be able to filter or change any input to any function that led to anything they have access to, and get a useful thing that way. So if you are looking at a dashboard showing the sales in California with various charts and tables, you’ll be able to inspect a call graph of what functions were called with what values, and depending on your permissions, you can override any of the functions or values. Anything from changing the font to changing the chart drawing function. Or pull out the data and do something completely different with it.

Absolutely! I was thinking about this just today. The way I envision it for cell is that if a

get

operation is a call, and that call contains an identifier, then there can be a conditional guarding a piece of data and getting into it. Data and code are very much mixed, because code can be made out of data. And whether you're making the call through http or it's just a memory access, it is all in the call. The mechanism is the same, kind of like Unix.

But you still have a separate way to address the

if

statement itself, right? IIRC your system (cell) makes it explicit whether you're looking at the data or executing the code. That's a critical distinction when trying to think about "everything as data". Or in the case of row-level security, at some point you need to be able to look at and edit the policy, which (probably/usually?) requires individually addressing the full set of things it could return. I guess that's less of an issue if you don't claim to have a unique address for each piece of data...

Good question! I actually see looking at the data as actual execution as well. But I need to implement it so that doesn't sound vague. My feeling is that if you have enough privileges, you can go and see the if and change it, if you don't, you get stuck with an error. The difference I see with Guyren's approach is that to me addresses are absolute and there's less variation between what you see and what someone else sees there. But then again, if you call a function to get your messages, depending on who you are you will get different messages, because your username is passed to the expansion of the call. So I'm not sure of that either 😅

Frest is all continuation passing. And functions are triggers on relations. So the different data you see than I see when you invoke the same request is ultimately inserted into a different place and is a different relation. It’s a different relation because the arguments to the query are not just those you immediately presented, but also those in the environment you have available to you. It’s all purely functional; you just don’t have the right arguments to be sent the things I can see. :-)

This may or may not be in the same system where the query under discussion is being executed.

This is the most exciting part, to me.

Indeed,