This article maps out the landscape of programming abstractions for working with LLMs. Prior to this, there wasn't any thorough attempt that we know of to make sense of and organize all of these different approaches and philosophies for programmatically incorporating LLMs into larger systems or pipelines. Hopefully this is helpful to folks who are trying to make sense of the landscape of abstractions for working with LLMs!
> In our research, we've found that editing is usually serial or asynchronous.
Medium-to-large-size company with a town hall = many people editing a document at the same time. Workshop at a company or a university with a modest size classroom = many people editing a document at the same time. I can't tell you how many times our web-based collaborative code editors would fall over during talks with small audiences we would give back in the days when I led the Scala Center.
Just because one of the benchmarks you have seen (of a multitude of benchmarks) breaks automerge by stressing it in what we believe is the most stressful scenario possible– multiple concurrent users, which is sort of the point of concurrency/collaboration frameworks, does not make it artificial or worth so flippantly discarding.
> long-form essay with Automerge and that the end-to-end keypress-to-paint latency using Codemirror is under 10ms (next frame at 100hz)
Not at all what we measured.
I'd just like to register here that Yjs is the framework most widely used "in real usage" (your words) and not automerge (for many reasons, not just performance.)
I found very little meat in that article... Right when I had been excited about points that seemed like they were about to be made, the article unfurled into a biography and promotion of Graeber's next book :/
For a ground-up, thorough, and free course on functional programming in Scala, take the course Martin Odersky teaches our undergrads at EPFL (Functional Programming Principles in Scala):
https://www.coursera.org/course/progfun
pour one out for the NSF folks. RIP </3