Journal entry for January 17, 2024

Reflecting on where I’m going

The past half year I’ve mostly worked on understanding Reflex and coding little FRP libraries. I’m much happier with my understanding of the nuances now and I’ve published a little FRP library and an accompanying blog post. This library should be able to serve as a platform to explore FRP related work.

I feel like now is the time to continue with actual novel work and pick up my ideas again. I’m finding it hard to pick though. I don’t have much internal motivation to work on generic “purely distributed programming” but at the same time that is where I have the most concrete material. Having some external motivation would definitely help here. Potentially writing down small bits of it as I go as blog posts too.

My other ideas are mostly around what right now I can only summarize as “purely functional Smalltalk meets Unison and Hazel”. I don’t know if I can do something concretely with that in Haskell without writing a language from scratch, because I think I’d need something like DrRacket to make progress with this in an existing system.

Thought: comments need need to stay synchronized with the actual code

You should be able to write comments which refer to identifiers in your code. Maybe they could even refer to actual code fragments/expressions. When these identifiers or expressions change or are removed, your editor should warn you.

How Distributed FRP improves over processes-and-messages programming

When I submitted my (incomplete and understandably rejected) DFRP paper one of the reviewers commented that I should make clear what advantages DFRP has over the regular way of doing distributed programming.

Some that I can think of:

No need to ever explicitly send information

This eliminates problems like deadlocks in which a process is blocked waiting for a message which will never come. There are not necessarily any processes, so they can’t be blocked, but you could still write programs which assume something is going to happen and that that fact is going to be known at some point, even though either the thing doesn’t happen or knowledge about it is never transferred. So it’s still possible to write incorrect programs, but maybe a lower level notion of accidental deadlock is eliminated. The choreographic programming research says this is one of the main advantages of their paradigm. I know about this due to the HasChor library and paper from ICFP, which implements choreographic programming in Haskell. I found the paper easy to read and enjoyable to understand.

Composability

Or: the main advantage of DFRP is that of all denotative/purely functional programming. With this you can split up distributed programs in a way which is not possible without introducing concurrency bugs in other languages. The only problem is I’m having a hard time thinking of concrete examples while at the same time being convinced that this is a huge cause of lack of code reuse and easy to use abstractions in distributed programming (typical me).

Maybe something that comes up in Paxos is a feasible example. When you read the algorithm, it says you want to get a quorum of “promises”, which is one concern. Then later the description says oh, and you also want to continue with “the highest accepted proposal you got back”, and this is another concern. Normally you’d go back and change your quorum code to include that, because if you write launch a separate process to collect those the results might not be correct? (Launching processes is the only way to achieve composability in message-based distributed programming AFAIK.)

Composing programs also forces you to write coordination code between components.

Higher-level abstractions like batching of received messages are very natural

You can very easily write a “aggregated commutative semigroup” function or have it as a primitive in your library. With this comes ease of optimizations etc. I guess the main argument here is that automating these kinds of things in regular programming doesn’t come as naturally?

The model is compatible with continuous transmission

I don’t have any examples for this, but you should be able to write programs which are about continous signals being transmitted, rather than the discrete messages.

Maybe things like “average light intensity coming from the south”??