Thanks for sharing this! I met @Peter van Hardenberg through this group (at @stevekrouse's suggestion) and had a very enjoyable conversation in downtown SF. As part of it I read a few links from inkandswitch.com, and we had a lively discussion about the direction I've been going, and how difficult it makes it to get feedback. But this article (which I never saw before in spite of browsing to the top level at https://www.inkandswitch.com) actually gets at the crucial fork in the road:

Our team was energized by this result and we instantly wanted this capability for all of our existing systems.. But we also quickly ran into what would likely be the biggest chunk of work.. for a living system to work, the internal and external APIs need to be mostly the same.. living systems produce a tension between hackability and the danger of user breakage. For example, the user can change a card’s background color just as easily as executing a command that would discard every card onscreen or even put the system into a crashed state or infinite loop. What to allow, how to surface errors, and how to recover are deep and challenging questions we did not explore in the course of this experiment.

The crucial property for hackability is making it easy to deduce the inputs and outputs of arbitrary fragments of code anywhere in a stack. That's basically what I've been chasing with https://github.com/akkartik/mu/blob/master/Readme.md. Building out these foundations is extremely time-consuming and work-intensive, but I really don't see any alternative to get to a 'real' system. One pattern I've noticed in multiple conversations with people here: having an idea to build something, not being happy with any of the available platforms but picking one anyway just to get started. E.g. see https://futureofcoding.slack.com/archives/C5T9GPWFL/p1552547395317600. My hope is that this hackable stack I'm growing from the bottom up will one day meet others growing various ideas from the top down. And that it will help us cross-pollinate ideas. Because it seems to me that anything created with current stacks suffers from the same problem as always: you build your thing with your ideas, others build their thing with their ideas, and it's very hard to inter-operate (https://futureofcoding.slack.com/archives/CC2JRGVLK/p1550557566019800?thread_ts=1550369313.016100&cid=CC2JRGVLK)

It's encouraging to see interest from the group in this post. It is new as of today, so that would be why @Kartik Agaram hadn't seen it before.

Ah, so the date on the post is inaccurate 🙂 Is there an archive page where one can see the list of all posts? I also wish posts mentioned author(s).

@Kartik Agaram hey so I co-written most of it together with Adam Wiggins, but there were a lot of people involved in making it polished; I'd be happy to answer questions though if you have any 🙂 I also written code for the capstone experiments section if you're interested in that

This farm stuff is super interesting:

All documents in Farm, both data and code, are Hypermerge documents. A Hypermerge document is identified by its URL, and anyone with the URL is able to make changes to it and should expect them to be synchronized everwhere in the world. All hypermerge documents are constructed out of their full history.

https://github.com/inkandswitch/farm

ping @Peter van Hardenberg - @shalabh has some good notes here, I know we can't get around downloading this stuff because of technical reasons, but maybe a screenshot in the readme is a good idea?

BTW, the write-up is 💯. Embodiment is a good term - I've seen the word 'tangible' before which I think shares the same idea. The single phase, single world (vs. compile/run split world) idea is also something strongly agree with.

Am in the middle, but in the sentence “Microsoft Research … and IDEs ...” the link linked from “IDEs” isn’t working (or at least on my machine over here in Israel it redirects to youtube’s front page)

(The Livebook link doesn't work either.)

This group might find our previous Pushpin project a helpful intro with a better README, since I'm working on the Farm docs/blog right now.

Agree on all points - my comment was more 'hey if it is a web app, host it?' but sounds like its a native app, electron style.

It is indeed!

How does farm provide durability?

All work is written into a hypercore -- an append-only log of your own work -- which is written to your local disk and shared with any collaborators you have.

Sounds interesting - similar to https://scuttlebot.io/. I suppose I should just wait for the blog/docs for the full story 😄.

Scuttlebutt has some similar properties but our persistence layer, hypermerge, is document oriented rather than message oriented.

How do docs refer to each other? By path+version? Can you refer to a slice of a doc? I sense @Bosmon and @Joe Trellick might find this interesting.

Docs are identified by the public / discovery key of their originating "actor" and refer to their dependencies by the same.

Are Pushpin and Farm prototypes or products? Do you expect to support them in the long term?

They're research prototypes. They all have several substantial gaps and bugs but are intended to explore a different path forward for developing and distributing software and data.

If you don’t mind: how formal is your research process? Do you write down ahead of time what you’re hoping to learn, or what would make the prototype successful?

It varies by project, but to allocate major resources we've used a proposal process. Once the project starts we present progress regularly (weekly to monthly) back to the rest of the lab. At the end of the project, we write things up internally.

Hi all, thanks for the nice words and other feedback on our EUP article. I've fixed the two broken links (thanks @yairchu and @shalabh) and corrected the article publication date.

Thanks! I’m really glad to hear from people who have organized R&D projects outside of major institutions and a couple people in a garage.