SPLASH 2017
Sun 22 - Fri 27 October 2017 Vancouver, Canada

Slack will be used during the workshop. If you plan to attend, please email sean.mcdirmid@ycr.org so we can send you an invite.

Live programming systems abandon the traditional edit-compile-run cycle in favor of fluid user experiences that encourages powerful new ways of “thinking to code” and enables programmers to see and understand their program executions. Programming today requires much mental effort with broken stuttering feedback loops: programmers carefully plan their abstractions, simulating program execution in their heads; the computer is merely a receptacle for the resulting code with a means of executing that code. Live programming aims to create a tighter more fluid feedback loop between the programmer and computer, allowing the computer to augment more of the programming process by, for example, allowing programmers to progressively mine abstractions from concrete examples and providing continuous feedback about how their code will execute. Meanwhile, under the radar of the PL community at-large, a nascent community has formed around the related idea of “live coding”—live audiovisual performances which use computers and algorithms as instruments and include live audiences in their programming experiences. This workshop focuses on exploring notions and degrees of live programming as they relate to development, creative activities, learning, and performance. We are interested in methodologies, tools, demos, infrastructures, language designs, and questions that stimulate interest and understanding in live programming.

Following up on the success of LIVE workshops at ECOOP 2016 and ICSE 2013, LIVE 2017 solicits high quality submissions on live programming and will discuss how to move forward with this topic to enable better programming experiences.

Call for Papers

LIVE 2017 aims to bring together people who are interested in live programming. Live programming systems abandon the traditional edit-compile-run cycle in favor of fluid user experiences that encourage powerful new ways of “thinking to code” and enable programmers to see and understand their program executions. Programming today requires much mental effort with broken stuttering feedback loops: programmers carefully plan their abstractions, simulating program execution in their heads; the computer is merely a receptacle for the resulting code with a means of executing that code. Live programming aims to create a tighter more fluid feedback loop between the programmer and computer, allowing the computer to augment more of the programming process by, for example, allowing programmers to progressively mine abstractions from concrete examples and providing continuous feedback about how their code will execute. Meanwhile, under the radar of the PL community at large, a nascent community has formed around the related idea of “live coding”—live audiovisual performances which use computers and algorithms as instruments and include live audiences in their programming experiences.

We encourage short research papers, position papers, web essays, tool demonstrations (as videos), and performance proposals in areas such as:

  • Recent work in REPLs, language environments , code playgrounds, and interactive notebooks.
  • Live visual programming.
  • Programming by example.
  • Programming tools for creative experiences and interactive audio visual performances.
  • Live programming as a learning aid.
  • Fluid debugging experiences
  • Language design in support of the above.

Submissions will go through EasyChair. The workshop is open to various kinds of media: you can write a traditional short paper (PDF), a web essay with embedded videos, a narrated video, or whatever else you think can explain your work best! Content should be consumable in 30 minutes to an hour of casual reader’s time, which means around 5-10 pages for a paper, a video from 10-20 minutes (assuming the viewer would need to pause to contemplate), and essays of around a few pages length. Video and non-paper submissions can by listed as URLs (e.g. to a web page, file locker, or streaming site) in the submission’s abstract.

Any questions or trouble with submitting, please contact sean.mcdirmid@ycr.org.

For fairness reasons, all submitted papers should conform to the formatting instructions. Submissions that violate these instructions may be rejected without review.

Submission Site

Please take a moment to read the instructions below before using the submission site.

Concurrent Submissions

Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy. Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism.

Format

Submissions should use the ACM SIGPLAN Conference acmart Format with ‘sigplan’ Subformat, 10 point font, using the font family Times New Roman. All submissions should be in PDF format. If you use LaTeX or Word, please use the provided ACM SIGPLAN acmart Templates provided here. Otherwise, follow the author instructions.

If you are formatting your paper using LaTeX, you will need to set the 10pt option in the \documentclass command. If you are formatting your paper using Word, you may wish to use the provided Word template that supports this font size. Please include page numbers in your submission with the LaTeX \settopmatter{printfolios=true} command. Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible.

Publication (Digital Library Early Access Warning)

AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work.