2024-08-16
Dear Albert Zak,
The Tenth Workshop on Live Programming (LIVE 2024) program committee is delighted to inform you that your submission "Run, Build and Grow Small Systems Without Leaving Your Text Editor" has been accepted to appear at the workshop. Congratulations!
Your three reviews are appended below. Reviewers have put a great deal of thought into offering constructive feedback. Please use their comments to improve your presentation before the workshop. Any feedback about challenges understanding your work and relating it to prior art may be especially valuable to pay attention to. If you would like additional feedback on how best to prepare your final submission, please let us know and we'll try to connect you with appropriate support.
This year we received a large number of submissions and accepted 16 papers. Presentations will all be between ten and twenty minutes and we will let you know the length of your talk soon.
The workshop will occur on Oct. 21 (Mon), in-person in Pasadena, CA (near Los Angeles).
Please note that at least one author of the submission must register for the SPLASH conference and present at the workshop. If none of the authors are able to attend in person, please let us know as soon as possible and we can discuss potential accommodations. We want to emphasize that meeting people and discussing your work in person is generally the most valuable part of workshop participation and encourage everyone to attend if they can.
As is customary with academic conferences, all attendees including speakers will need to cover their own registration fee, hotel, and travel. A single day registration for the workshop ranges between $180 and $285 USD. Full registration details, including attendance of the host OOPLSA and Onward! conferences can be found here: https://2024.splashcon.org/attending/Registration
We encourage you to register early to ensure the best hotel and registration rates.
Congratulations again; we look forward to seeing you at the workshop!
Best, LIVE 2024 Co-chairs
Peter van Hardenberg (Ink & Switch) Joshua Horowitz (University of Washington) Geoffrey Litt (Ink & Switch)
- Accept
- Knowledgeable
This submission presents a live programming environment for small distributed systems. The top-level programming model is to write a function for each node in the distributed system, where the function takes the node's capabilities (eg turn on/off light, read CO2 levels, etc) and executes on each node tick. The programmer may query the live data passing through each node's function by wrapping expressions of interest in lightweight macros, which self-rewrite to display the expression's value as plain text next to / under it and update the displayed value on every tick. These displayed values may be filtered based on their closure, visually customized using arbitrary display functions, and augmented with historical values over recent ticks.
The author demos this system using a toy node set up with LEDs, CO2 sensors connected to their home, and the editor itself, which is also a node in the distributed system. Various individual features are credited to prior designs, though the overall system feels distinct in its lightweight low ceremony design.
Great demo and presentation! The system looks and feels great, your presentation was polished, and I appreciated the feature-by-feature pointers to related work.
I love the extremely lightweight feel of this system (does it have a name?). A super simple programming model + just a handful of self-rewriting macros for querying live values, all within my text buffer. No need to hover over something, figure out how to pin it, figure out what I need to click to adjust the current closure, etc. I feel that the system gives you a lot of bang for the syntactic buck.
Cool moment when the query macro was used to inspect the LED node's capabilities. What does it take to set up and connect a node to this system (eg how are the node's capabilities specified)? Overall I quite like the distributed systems contextualization, with the editor itself being a node and dashboard for all the other nodes. The easy visualization customization and history log features seem especially useful for setting up low-budget dashboards. I was confused at first by the first example of the context macro, which filtered the stream of CO2 measures based on the node's pid, because I didn't see a pid variable getting set explicitly anywhere. I've since reasoned that pid is a variable getting set within the co2 sensor node's function, and that it gets added to a closure attached to the co2 measure sent to the editor, and these closures were being read and filtered by the context macro. It would be nice to have this laid out more explicitly in the first example.
- Reviewer: Joshua Horowitz [email protected]
- Accept
- Knowledgeable
This video submission showcases a ClojureScript-based environment which is designed for live program editing with live feedback. The core mechanic is a question-mark “query macro” which inlines live values from execution back into the text editor. Numerous extensions to this query macro are described, such as versions designed for use inside threading macros and a “context” system to filter feedback to a desired context.
Separate from but complementary to the query macro is a lightweight system for distributed programming. A “node” operator allows code to be run as processes on other machines, such as Raspberry Pi computers hooked up to electronics, and web clients. A “capability” system grants processes running on remote machines access to capabilities such as GPIO pins, file systems, and in-memory persistent state. The query macro is used pervasively across machine boundaries to interactively investigate behavior on remote machines.
This is a delightful and effective system, presented delightfully and effectively. Thank you for submitting it!
A few things I particularly enjoyed:
- The presentation was playful, efficient, and clear.
- I was glad to see the project’s treatment of persistent state. Although “re-execute on every change” systems are ideal for live visibility, they must grapple at some point with application-builders’ desire for persistent state. I’m glad you started digging into this.
- The first time I saw the emoji-based visualization, I thought “cute, but you can’t do everything with emoji!” So I was impressed to see the support for HTML-based visualizations a moment later.
- Your closing discussion was great – I appreciated the listing of related work and limitations very much.
The main things I wanted to see more of all fit into the general category of zooming out, or trying to find broader lessons from your work. What makes it succeed to the extent it has succeeded so far, and what might stand in the way of further success?
The limitations you list all seem like things a team of software engineers could straightforwardly implement. If they did so, would the resulting system be wonderful and broadly usable? Or are there deeper design challenges that remain?
Are there specific domains where this system would be especially useful, or not as useful?
Your discussion of related work could fit into this zooming out. Where does your system succeed that these systems fail? What lessons are there for people building systems like this in the future? (You say that “none of the ideas here are new”, but there must have been SOMETHING that compelled you to make something new, right?)
I think the most productive presentation to the LIVE community would lean a bit more in the direction of addressing some of those questions, perhaps at the expense of giving a complete account of all the features you’ve developed.
And here are some more specific questions…
- What, ultimately, is the point of inlining live values into the flow of text, rather than, say, showing them alongside text? This question occurred to me when I considered the benefits of general HTML-based visualizations, and realized they couldn’t truly be inlined as text. But that doesn’t seem like a problem. So… why inline at all?
- The context system you developed seems useful for some things, but very manual. I imagine you’d want to grapple with the question of how to easily see, e.g., multiple iterations of a loop, or multiple calls to a single function. What do you think?
- How important is it that this system be built on top of a LISP like Clojure? Could you have done this with JavaScript? If not – why not?
Please let me know if any of these comments are unclear; happy to chat more.
Thanks & warm wishes, Josh
- Weak accept
- Some familiarity
This video introduces a live programming environment for Clojure which brings together a number of useful live affordances into a crisp experience to improve how distributed and embedded systems are programmed.
I thank the author for their submission to LIVE. I recommend that this submission is accepted to LIVE. I find the demo compelling, with many interesting features. While the author states at some point that "none of this is new," the features and their envisioned usage scenarios are fresh enough that I think it will spark interesting conversations at LIVE.
As I see it, the two strongest aspects of this submission are:
ENGAGING PRESENTATION. This is one of the best programming video demos I have seen, and I would place it in the top 10% of those I see at academic conferences. The presenter has great energy. They enthusiastically deliver their demo. Their narration, and the text on the screen, are easy to understand. The examples are, for the most part, both meaningful and easy to understand, which means that the author gets to spend quite a bit of time introducing the features, rather than explaining the code.
There were numerous very nice touches in the talk. I particularly appreciated the visual related work, which made it clear that the author's work is in dialogue with ideas from prior work. I also enjoyed the example with classified information, which set up the talk well for justifying the need for filtered views for improved security in collaboration, and was simply another enjoyable part of an already engaging presentation.
COMPELLING IDEAS. I thought many aspects of the programming environment were well-done. This included:
- The "?" macro for introducing an inline value of a visualization
- The query operator for filtering prove displays to a particular calling contexts
- Also, the fact that the syntax for each of the above was simple and fit aesthetically well into the surrounding Clojure
- ... and the fact that probe information is tightly-integrated into the editor, with inline views and the selectability of values
- The extensibility of views of values with programmable HTML views
- Collaboration support with the ability to filter data views
The features were demonstrated in a way that the value of those features was clear. In general I think it is difficult to design features like these so that there are not clunky design aspects overshadowing the value a user can get from the features, and the demonstrated features steer clear of obvious clunkiness.
There are two regards in which I felt this video fell short of what I would want to see at LIVE:
WHAT SHOULD I TAKE AWAY FROM THIS? As the author states, "none of this is new." I wish this talk gave a better sense of how it changes or adds to the conversation. For example, why are the features in this talk particularly well-suited to building distributed and embedded systems? Where do they fall short? Where is the design of these features subtly different from past incarnations, and are those differences important?
SOME OPPORTUNITIES FOR CLARIFICATION. There are a number of places where I felt I missed something, and they may represent opportunities for the author to slow down and elaborate:
- I didn't really understand how using the "bang" to redploy worked
- Initially I thought that "?" only executed once, or once per loop iteration. At 5:10, I was surprised to see it continually monitoring a file with no trigger in sight. So what triggered the "?" to run?
- How does commenting work in a way that doesn't comment out closing structural elements like "}" and ")" as in one of the examples?
- I don't entirely get how the contexts work. If I understand correctly, contexts just affect what values are visualized by the probes, but not the values that are actually handled by the code. Is that the case?
- I don't have prior experience using Clojure, and an audience member like me could use a little bit of help understanding which language elements are "just Clojure" and which ones are added by this tool. I felt this was particularly the case around 6:00, and also in other places as well.
- In retrospect, I don't know what features the author was referring to as "declarative distributed process scheduling" on the last slide.
Taking a step back, I recommend this video is accepted to LIVE. It strikes me as a potential crowd pleaser: the demo is fun and really interesting, and given the presenter's knowledge of the related work, I imagine it will lead to interesting conversations about which of these features sampled from prior work belong in future live programming interfaces.