Paper Title: Live Programming Small Distributed Systems in Plain Text
Paper ID: 45
Track Name: ICLC2024 - Papers
-
- Enter your review here. (Your review will be visible to Authors and Meta Reviewers) Please include any relevant details to support your review decision. This may include, but is not limited to, details on the following points: 1) Is the paper's subject matter appropriate for ICLC and does it progress thinking and research in the field of live coding? 2) Is the paper well written, does its methodology and conclusions make sense, does it follow a consistent academic style? 3) Does the paper meaningfully address one of the three conference themes (https://iclc.toplap.org/2024/open-call.html#themes). 4) What is the likelihood that the author(s) can will be present in Shanghai for the conference, since ICLC2024 will give preference to in-person presentations.
This submission reports on the design of a distributed system that supports liveness, capabilities, process control, and inspection.Since the system is implemented in ClojureScript, liveness is achieved by on-demand interpretation of S-expressions, capabilities are implemented via closures, process control considers the mapping of functions to nodes, and inspection is provided via trace points on data flows.
The text is easy to read and understand.
However, the current form of this submission suggests the authors need to revise and extend their written account before it can be considered for publication at and archival with a scientific conference.
Already the abstract left me wondering if its three paragraphs are a statement about observations made by the authors or the contribution of their work. For my reading the submission I decided to assume the latter, but would like suggest to the authors to revise this important part of their paper. (Many conferences and journals provide advice via templates or examples...)
With most of the statements in the text I could relate based on personal experience, but very often I was left with questions of what are the contributions the authors would like to present and how those statements can be used in its support.
A few examples: "The ambition is that programmers never have to leave their (mostly) plain text programming environment while constructing and interacting with a running distributed system." -> Why? (Please explain...)
"Imperative tools are needed to run declarative code: “package manager”, “deployment script”, “test runner”, “configuration tool” etc. are all symptoms of the same problem." -> Which problem? (Please state explicitly; explain...)
The section on "State of the Art" provided an intersting list of observations, programming systems, general ideas, each of them worth discussing both in their own right and in relation to the contributions the authors are to document.
The section on "Related Work" closely resembled that of "State of the Art". What is the difference between them? Its subsection on "Originality" only mentioned REPLs as an (the?) area where the authors' work differs.
I'm sure there is more than that, but for me this is hard to tell based on the text.
A simple search revealed other related work that might be worth considering in this submission like "Clerk: Moldable Live Programming for Clojure" from 2023 [1].
The sections "Concepts" and "Discussion" might benefit from a general overview of the system developed (its architecture maybe?), illustrations to help readers contextualizing the details mentioned, and a running example touching all contributions and anything else worth documenting and discussing.
I would also suggest revisiting the references section: Some preprints mentioned there are in print for some time already. References to web pages should augmented by the date of last retrieval. Other references offer only incomplete bibliographic information. All references should be normalized to consistently adhere to ICLC's desired format
...Also, I was wondering if chances are the authors mistook live programming for live coding [2] and therefore submitted to ICLC [3] instead of events like DLS[4], LIVE [5], or similar?!
References:
[1] https://dl.acm.org/doi/10.1145/3594671.3594682M. Kavalar, P. Markovics, J. Rusher: "Clerk: Moldable Live Programming for Clojure". Programming 2023 Companion Proceedings of the 7th International Conference on the Art, Science, and Engineering of Programming, March 2023, pages 22–31.
[2] https://programming-journal.org/2019/3/1/P. Rein, S. Ramson, J. Lincke, R. Hirschfeld, T. Pape: "Exploratory and Live, Programming and Coding: A Literature Study". Journal on The Art, Science, and Engineering of Programming, volume 3, issue 1, article 1, 33 pages, 2018.
[4] https://2023.splashcon.org/home/dls-2023 (symposium series)
[5] https://2023.splashcon.org/home/live-2023 (workshop series)
This paper attempts to describe an early implementation of a live programming system based on plain text to live code small-scale distributed systems. The subject matter which is not very clearly expressed throughout is not really relevant to ICLC. There is no mention at any point of how the proposed language would have anything to do with live coding audio, music or visuals. That also means there is no consideration given to how a performer's creativity would be enhanced or aided with such a system. There may be an aspect to this proposal that might progress thinking and research in the field of live coding, but it is not very effectively communicated, the description of the proposed system is quite vague and difficult to follow. The style of the paper is rather abrupt and disjointed. Various concepts are mentioned, but not properly introduced, even the most essential components of the system - nodes and message broker. Figures illustrating the workflows in this system would be extremely helpful, however there are none. There seems to be no logical connection between the subject matter and the state of the art section. There is no comparison or discussion in the context of other live coding environments. This system is implemented in ClojureScript, so it would be helpful when trying to envision the functionality of this system if there was at least discussion of how it compares to Overtone for example (https://overtone.github.io/) which is an audio environment implemented partly in Clojure. The methodology and conclusions are not expressed very clearly. The paper does not seem to meaningfully address any of the conference themes either.
General comments:
- The paper explores live programming systems and is relevant to the ICLC, although it does not align too closely with the specified themes.
- A noticeable formatting issue exists due to the lack of well-structured paragraphs, which appears to be a quite easy fix.
Section-Specific Feedback:
Sec. 1
-
Clarify how the contribution resolves the identified problem. Address any expression mistakes to ensure a clear understanding of the solution. The connection between 1.1 and 1.2 is not clearly put.
-
While understanding the writer's intentions, the phrase "general purpose, yet minimal in concepts" lacks clarity. It would be beneficial to mention how minimality is defined. While four concepts are mentioned, it's unclear whether it's the quantity or inherent characteristics that make them minimal.
Sec. 2
The State of the Art (SOTA) seems relevant and well structured.
Sec. 3
- Consider streamlining this section. Integrate the first part of the Related Work section into the SOTA for better cohesion. Move the content in Section 3.1 to the Concepts section, aligning it better with conceptual discussions.
Sec. 4
Given the technical details in this section, I am unable to provide useful feedback. Some parts fall out of my knowledge.
Sec. 5
- Address the lack of clarity in connecting ideas in the Discussion section. Ensure that this section not only discusses limitations but also highlights the positive aspects and contributions of the research.
Sec. 6
The implementation is not finished yet but the future steps are stated clearly here.
References
I acknowledge the paper's well-cited nature.
- Identify and rectify any minor inconsistencies in the presentation of citations to ensure a consistent format for all references.
Overall observation: The paper is generally not well written. It could greatly benefit from a more precise use of academic terminology and better readability. For instance, in Section 6, the term "anything serious" lacks clarity and does not align with scientific wording standards. Similarly, the phrase "none of the concepts are new, but they have not been recombined in this specific way" (Section 1 and 7) could be refined for precision and academic rigor. Consider revisiting and enhance expressions of this nature throughout the paper.
While sharing the initial stages of a new implementation can be valuable, the writing and expression used in this paper need major improvements. I would suggest major corrections for the paper to be accepted, and in the event of non acceptance consider consolidating the entire future work into a single paper before resubmitting.