‹Programming› '22 Companion-PX: "A Live Environment to Improve ..."
A Live Environment to Improve the Refactoring Experience
Sara Fernandes, Ademar Aguiar, and André Restivo
(University of Porto, Portugal)
Refactoring helps improve the design of software systems, making them more understandable, readable, maintainable, cleaner, and self-explanatory. Many refactoring tools allow developers to select and execute the best refactorings for their code. However, most of them lack quick and continuous feedback, support, and guidance, leading to a poor refactoring experience. To fill this gap, we are researching ways to increase liveness in refactoring. Live Refactoring consists of continuously knowing, in real-time, what and why to refactor. To explore the concept of Live Refactoring and its main components --- recommendation, visualization, and application, we prototyped a Live Refactoring Environment focused on the Extract Method refactoring. With it, developers can receive recommendations about the best refactoring options and have support to apply them automatically. This work helped us reinforce the hypothesis that early and continuous refactoring feedback helps to shorten the time needed to create high-quality systems.
@InProceedings{‹Programming›22p30,
author = {Sara Fernandes and Ademar Aguiar and André Restivo},
title = {A Live Environment to Improve the Refactoring Experience},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {30--37},
doi = {10.1145/3532512.3535222},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Toward Understanding Task ..."
Toward Understanding Task Complexity in Maintenance-Based Studies of Programming Tools
Patrick Rein, Tom Beckmann, Toni Mattis, and Robert Hirschfeld
(HPI, Germany)
Researchers conducting studies on programming tools often make use of maintenance tasks. The complexity of these tasks can influence the behavior of participants significantly. At the same time, the complexity of tasks is difficult to pinpoint due to the many sources of complexity for maintenance tasks. As a result, researchers may struggle to deliberately decide in which regard their tasks should be complex and in which regard they should be simple. To help researchers make more deliberate decisions about the complexity of their tasks, we discuss different factors of task complexity. We draw these factors from previous user studies on programming tools as well as from a task complexity model from ergonomics research that we apply to maintenance tasks. In the end, task complexity might always be too complex to be fully controlled. Nevertheless, we hope that our discussion helps other researchers to decide in which dimensions their tasks are complex and in which dimensions they want to keep them simple.
@InProceedings{‹Programming›22p38,
author = {Patrick Rein and Tom Beckmann and Toni Mattis and Robert Hirschfeld},
title = {Toward Understanding Task Complexity in Maintenance-Based Studies of Programming Tools},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {38--45},
doi = {10.1145/3532512.3535223},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Programming in an fMRI Scanner: ..."
Programming in an fMRI Scanner: A Report from the Field
Steven Tanimoto, Rob Thompson, Todd Richards, Cheri Yates, and Virginia Berninger
(University of Washington, USA; Colorado School of Mines, USA; Seattle Childrens Hospital, USA)
A preliminary study is reported in which six human subjects were scanned while performing a simple form of computer programming. Functional magnetic resonance imaging typically precludes the use of ordinary computing equipment due to safety concerns when items with metallic parts are in the scanning room. We used a special visual programming environment, "Kokopelli's World," for which an optics-only trackball was sufficient. This research methodology is described. Aspects of the experience of programming, by one of the authors, in the fMRI scanner are reported. An analysis of the data from the scanning is presented, and brain areas where activity for coding exceeded activity for a control task were identified and are presented here. These observations suggest hypotheses and directions for future research. One hypothesis is that particular aspects of programming are inherently and measurably pleasurable.
@InProceedings{‹Programming›22p12,
author = {Steven Tanimoto and Rob Thompson and Todd Richards and Cheri Yates and Virginia Berninger},
title = {Programming in an fMRI Scanner: A Report from the Field},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {12--21},
doi = {10.1145/3532512.3535220},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-MOREVMS: "Interpreter Register Autolocalisation: ..."
Interpreter Register Autolocalisation: Improving the Performance of Efficient Interpreters
Guillermo Polito, Nahuel Palumbo, Soufyane Labsari, Stéphane Ducasse, and Pablo Tesone
(University of Lille, France; CNRS, France; Inria, France; Centrale Lille, France)
Language interpreters are generally slower than (JIT) compiled implementations because they trade off simplicity for performance and portability. They are nevertheless still important in modern Virtual Machines (VMs): e.g., not all code is hot and arrives to later compilation stages.
We propose to study more in depth the idea of interpreter registers: interpreter variables that are critical to the efficient execution of the interpreter loop. We present an automatic interpreter transformation for bytecode interpreters written in C called autolocalization. Autolocalisation makes interpreter registers local to the interpreter loop with the objective of keeping them in registers and makes those values available for other routines in the VM runtime automatically when required.
We build autolocalisation in Slang, Pharo’s VM generator framework, and evaluate the performance of several benchmarks on different configurations localising IP, SP, FP and their combinations. We show that the C compiler does not make this optimization automatically, and that this transformation yields improvements of up to 1.92x on x86-64. Moreover, we show that the performance of our automatic approach is comparable to the previously approach handwritten in the Pharo VM while making it easier to read, modify and debug.
@InProceedings{‹Programming›22p1,
author = {Guillermo Polito and Nahuel Palumbo and Soufyane Labsari and Stéphane Ducasse and Pablo Tesone},
title = {Interpreter Register Autolocalisation: Improving the Performance of Efficient Interpreters},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {1--5},
doi = {10.1145/3532512.3532518},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "An Experiment in Live Collaborative ..."
An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform
Yoshiki Ohshima, Aran Lunzer, Jenn Evans, Vanessa Freudenberg, Brian Upton, and David A. Smith
(Croquet Corporation, USA; Croquet Corporation, Canada)
This paper describes our experiences in building a live collaborative programming environment on top of the JavaScript version of the Croquet shared experience platform.
Croquet provides a clean substrate for building real-time collaborative applications. We created an application framework that supports live programming, and used that framework to build the Greenlight collaborative application, then in turn, modified it to do live programming experiments. The environment allows multiple users to modify the running application from within, with changes taking effect immediately.
The experiment was inspired by earlier work including Douglas Engelbart’s oN-Line System (NLS) and the Kansas system in Self. Analogically, the system is like the Smalltalk environment made collaborative.
In this paper we explain the Croquet architecture, its library and framework, and the Greenlight application used to make the live programming environment.
The standard version of Greenlight is available at https://croquet.io/greenlight, and the modified demo system is available at https://croquet.io/scripting.
@InProceedings{‹Programming›22p46,
author = {Yoshiki Ohshima and Aran Lunzer and Jenn Evans and Vanessa Freudenberg and Brian Upton and David A. Smith},
title = {An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {46--53},
doi = {10.1145/3532512.3535224},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "A Live Environment to Improve ..."
A Live Environment to Improve the Refactoring Experience
Sara Fernandes, Ademar Aguiar, and André Restivo
(University of Porto, Portugal)
Refactoring helps improve the design of software systems, making them more understandable, readable, maintainable, cleaner, and self-explanatory. Many refactoring tools allow developers to select and execute the best refactorings for their code. However, most of them lack quick and continuous feedback, support, and guidance, leading to a poor refactoring experience. To fill this gap, we are researching ways to increase liveness in refactoring. Live Refactoring consists of continuously knowing, in real-time, what and why to refactor. To explore the concept of Live Refactoring and its main components --- recommendation, visualization, and application, we prototyped a Live Refactoring Environment focused on the Extract Method refactoring. With it, developers can receive recommendations about the best refactoring options and have support to apply them automatically. This work helped us reinforce the hypothesis that early and continuous refactoring feedback helps to shorten the time needed to create high-quality systems.
@InProceedings{‹Programming›22p30,
author = {Sara Fernandes and Ademar Aguiar and André Restivo},
title = {A Live Environment to Improve the Refactoring Experience},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {30--37},
doi = {10.1145/3532512.3535222},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "An Experiment in Live Collaborative ..."
An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform
Yoshiki Ohshima, Aran Lunzer, Jenn Evans, Vanessa Freudenberg, Brian Upton, and David A. Smith
(Croquet Corporation, USA; Croquet Corporation, Canada)
This paper describes our experiences in building a live collaborative programming environment on top of the JavaScript version of the Croquet shared experience platform.
Croquet provides a clean substrate for building real-time collaborative applications. We created an application framework that supports live programming, and used that framework to build the Greenlight collaborative application, then in turn, modified it to do live programming experiments. The environment allows multiple users to modify the running application from within, with changes taking effect immediately.
The experiment was inspired by earlier work including Douglas Engelbart’s oN-Line System (NLS) and the Kansas system in Self. Analogically, the system is like the Smalltalk environment made collaborative.
In this paper we explain the Croquet architecture, its library and framework, and the Greenlight application used to make the live programming environment.
The standard version of Greenlight is available at https://croquet.io/greenlight, and the modified demo system is available at https://croquet.io/scripting.
@InProceedings{‹Programming›22p46,
author = {Yoshiki Ohshima and Aran Lunzer and Jenn Evans and Vanessa Freudenberg and Brian Upton and David A. Smith},
title = {An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {46--53},
doi = {10.1145/3532512.3535224},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-BOXER: "Creating New Programming Experiences ..."
Creating New Programming Experiences Inspired by Boxer to Develop Computationally Literate Society
Mark Guzdial
(University of Michigan, USA)
Boxer suggests a medium that might be used by a computationally literate society. We do not have a computationally literate society, but we do have one where computation is pervasive. Reaching computational literacy will require us to invent media that reach citizens where they are, so that they can use computation for the kinds of tasks envisioned for Boxer. Teaspoon languages are task-specific languages designed to be highly usable. By developing and disseminating Teaspoon languages, we might move towards creating a computationally literate society.
@InProceedings{‹Programming›22p67,
author = {Mark Guzdial},
title = {Creating New Programming Experiences Inspired by Boxer to Develop Computationally Literate Society},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {67--69},
doi = {10.1145/3532512.3539663},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-MOREVMS: "Toward Just-in-Time and Language-Agnostic ..."
Toward Just-in-Time and Language-Agnostic Mutation Testing
Stefan Reschke, Toni Mattis, Fabio Niephaus, and Robert Hirschfeld
(University of Potsdam, Germany; Oracle Labs, Germany)
Mutation Testing is a popular approach to determine the quality of a suite of unit tests. It is based on the idea that introducing faults into a system under test (SUT) should cause tests to fail, otherwise, the test suite might be of insufficient quality. In the language of mutation testing, such a fault is referred to as “mutation”, and an instance of the SUT’s code that contains the mutation is referred to as “mutant”. Mutation testing is computationally expensive and time-consuming. Reasons for this include, for example, a high number of mutations to consider, interrelations between these mutations, and mutant-associated costs such as the cost of mutant creation or the cost of checking whether any tests fail in response. Furthermore, implementing a reliable tool for automatic mutation testing is a significant effort for any language. As a result, mutation testing is only available for some languages.
Present mutation tools often rely on modifying code or binary executables. We refer to this as “ahead-of-time” mutation testing. Oftentimes, they neither take dynamic information that is only available at run-time into account nor alter program behavior at run-time. However, mutating via the latter could save costs on mutant creation: If the corresponding module of code is compiled, only the mutated section of code needs to be recompiled. Run-time information (like previous execution results selected by an initial test run) could help to determine the utility of a mutant. Skipping mutants of low utility could have an impact on mutation testing efficiency. We refer to this approach as just-in-time mutation testing.
In this paper, we provide a proof of concept for just-in-time and language-agnostic mutation testing. We present preliminary results of a feasibility study that explores the implementation of just-in-time mutation testing based on Truffle’s instrumentation API. Based on these results, future research can evaluate the implications of just-in-time and language-agnostic mutation testing.
@InProceedings{‹Programming›22p6,
author = {Stefan Reschke and Toni Mattis and Fabio Niephaus and Robert Hirschfeld},
title = {Toward Just-in-Time and Language-Agnostic Mutation Testing},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {6--11},
doi = {10.1145/3532512.3532514},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Toward Understanding Task ..."
Toward Understanding Task Complexity in Maintenance-Based Studies of Programming Tools
Patrick Rein, Tom Beckmann, Toni Mattis, and Robert Hirschfeld
(HPI, Germany)
Researchers conducting studies on programming tools often make use of maintenance tasks. The complexity of these tasks can influence the behavior of participants significantly. At the same time, the complexity of tasks is difficult to pinpoint due to the many sources of complexity for maintenance tasks. As a result, researchers may struggle to deliberately decide in which regard their tasks should be complex and in which regard they should be simple. To help researchers make more deliberate decisions about the complexity of their tasks, we discuss different factors of task complexity. We draw these factors from previous user studies on programming tools as well as from a task complexity model from ergonomics research that we apply to maintenance tasks. In the end, task complexity might always be too complex to be fully controlled. Nevertheless, we hope that our discussion helps other researchers to decide in which dimensions their tasks are complex and in which dimensions they want to keep them simple.
@InProceedings{‹Programming›22p38,
author = {Patrick Rein and Tom Beckmann and Toni Mattis and Robert Hirschfeld},
title = {Toward Understanding Task Complexity in Maintenance-Based Studies of Programming Tools},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {38--45},
doi = {10.1145/3532512.3535223},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Example Mining: Assisting ..."
Example Mining: Assisting Example Creation to Enhance Code Comprehension
Eva Krebs, Patrick Rein, and Robert Hirschfeld
(HPI, Germany)
Programmers often use examples with concrete values to better understand code. Code by itself is abstract, which empowers it to be used for a variety of uses, but can be difficult to grasp by developers. Babylonian Programming addresses this by allowing programmers to concretize their code by defining and visualizing examples directly in the code itself while editing.
Currently, Babylonian Programming implementations such as Babylonian/S require programmers to define examples manually. For examples containing small objects this is straightforward, however when creating large or complex objects it is not. Sometimes, workarounds such as copying existing code pieces or trying to recreate existing objects are used to reuse information already present in the system, but these workarounds can be error-prone and also time-consuming.
In this paper, we propose Example Mining to address this issue by providing techniques and integrated tools to mine examples from existing sources similar to concepts from run-time tracing and test case extraction. Example mining introduces concepts to mine examples from tests, debugging sessions, and traces of actual usage of the system under development. All tools were implemented for Babylonian/S in Squeak/Smalltalk.
We demonstrate the usefulness of the tools through walkthroughs. Our tools provide examples for many methods immediately and automatically. As a consequence, programmers have more immediate access to dynamic feedback on their abstract code, making code comprehension and debugging more effective.
@InProceedings{‹Programming›22p60,
author = {Eva Krebs and Patrick Rein and Robert Hirschfeld},
title = {Example Mining: Assisting Example Creation to Enhance Code Comprehension},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {60--66},
doi = {10.1145/3532512.3535226},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Calling Cards: Concrete Visual ..."
Calling Cards: Concrete Visual End-User Programming
Michael Homer
(Victoria University of Wellington, New Zealand)
Creating a program that performs even a simple task and shows the result is unapproachable to most people, and even trained programmers face a burden to create a new program. In this paper, we introduce a prototype system and model for live visual dataflow programming where intermediate steps are visible and all components are tangible and manifest. Our system aims to allow a user to dive in and immediately have a working program that can be incrementally extended.
@InProceedings{‹Programming›22p22,
author = {Michael Homer},
title = {Calling Cards: Concrete Visual End-User Programming},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {22--29},
doi = {10.1145/3532512.3535221},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-POSTERS: "Enhancing DrRacket with Dodona ..."
Enhancing DrRacket with Dodona for Learning Scheme
Turgut Reis Kursun, Mathijs Saey, and Viviane Jonckers
(Vrije Universiteit Brussel, Belgium)
Learning how to program in a typical setting is challenging because feedback can often not be given immediately. Tracking the work of a student is also challenging for teachers, as the work of a student is not readily accessible. Therefore, digital learning environments have been considered to facilitate the learning process. We aim to facilitate the learning process of beginner students learning Scheme. To this end, we have developed a plugin for the DrRacket IDE (used for Scheme), that communicates with Dodona, a web service geared towards helping students learn how to code. Our plugin uses the information provided by this platform to give students immediate feedback on their code inside the DrRacket IDE. To enable the above, we extended the Dodona platform to support Scheme. As part of our extensions, we introduced several dynamic and static analyses to the Dodona platform, which we use to verify additional properties of the code submitted by students.
@InProceedings{‹Programming›22p81,
author = {Turgut Reis Kursun and Mathijs Saey and Viviane Jonckers},
title = {Enhancing DrRacket with Dodona for Learning Scheme},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {81--82},
doi = {10.1145/3532512.3564142},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Example Mining: Assisting ..."
Example Mining: Assisting Example Creation to Enhance Code Comprehension
Eva Krebs, Patrick Rein, and Robert Hirschfeld
(HPI, Germany)
Programmers often use examples with concrete values to better understand code. Code by itself is abstract, which empowers it to be used for a variety of uses, but can be difficult to grasp by developers. Babylonian Programming addresses this by allowing programmers to concretize their code by defining and visualizing examples directly in the code itself while editing.
Currently, Babylonian Programming implementations such as Babylonian/S require programmers to define examples manually. For examples containing small objects this is straightforward, however when creating large or complex objects it is not. Sometimes, workarounds such as copying existing code pieces or trying to recreate existing objects are used to reuse information already present in the system, but these workarounds can be error-prone and also time-consuming.
In this paper, we propose Example Mining to address this issue by providing techniques and integrated tools to mine examples from existing sources similar to concepts from run-time tracing and test case extraction. Example mining introduces concepts to mine examples from tests, debugging sessions, and traces of actual usage of the system under development. All tools were implemented for Babylonian/S in Squeak/Smalltalk.
We demonstrate the usefulness of the tools through walkthroughs. Our tools provide examples for many methods immediately and automatically. As a consequence, programmers have more immediate access to dynamic feedback on their abstract code, making code comprehension and debugging more effective.
@InProceedings{‹Programming›22p60,
author = {Eva Krebs and Patrick Rein and Robert Hirschfeld},
title = {Example Mining: Assisting Example Creation to Enhance Code Comprehension},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {60--66},
doi = {10.1145/3532512.3535226},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-POSTERS: "Enhancing DrRacket with Dodona ..."
Enhancing DrRacket with Dodona for Learning Scheme
Turgut Reis Kursun, Mathijs Saey, and Viviane Jonckers
(Vrije Universiteit Brussel, Belgium)
Learning how to program in a typical setting is challenging because feedback can often not be given immediately. Tracking the work of a student is also challenging for teachers, as the work of a student is not readily accessible. Therefore, digital learning environments have been considered to facilitate the learning process. We aim to facilitate the learning process of beginner students learning Scheme. To this end, we have developed a plugin for the DrRacket IDE (used for Scheme), that communicates with Dodona, a web service geared towards helping students learn how to code. Our plugin uses the information provided by this platform to give students immediate feedback on their code inside the DrRacket IDE. To enable the above, we extended the Dodona platform to support Scheme. As part of our extensions, we introduced several dynamic and static analyses to the Dodona platform, which we use to verify additional properties of the code submitted by students.
@InProceedings{‹Programming›22p81,
author = {Turgut Reis Kursun and Mathijs Saey and Viviane Jonckers},
title = {Enhancing DrRacket with Dodona for Learning Scheme},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {81--82},
doi = {10.1145/3532512.3564142},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-MOREVMS: "Interpreter Register Autolocalisation: ..."
Interpreter Register Autolocalisation: Improving the Performance of Efficient Interpreters
Guillermo Polito, Nahuel Palumbo, Soufyane Labsari, Stéphane Ducasse, and Pablo Tesone
(University of Lille, France; CNRS, France; Inria, France; Centrale Lille, France)
Language interpreters are generally slower than (JIT) compiled implementations because they trade off simplicity for performance and portability. They are nevertheless still important in modern Virtual Machines (VMs): e.g., not all code is hot and arrives to later compilation stages.
We propose to study more in depth the idea of interpreter registers: interpreter variables that are critical to the efficient execution of the interpreter loop. We present an automatic interpreter transformation for bytecode interpreters written in C called autolocalization. Autolocalisation makes interpreter registers local to the interpreter loop with the objective of keeping them in registers and makes those values available for other routines in the VM runtime automatically when required.
We build autolocalisation in Slang, Pharo’s VM generator framework, and evaluate the performance of several benchmarks on different configurations localising IP, SP, FP and their combinations. We show that the C compiler does not make this optimization automatically, and that this transformation yields improvements of up to 1.92x on x86-64. Moreover, we show that the performance of our automatic approach is comparable to the previously approach handwritten in the Pharo VM while making it easier to read, modify and debug.
@InProceedings{‹Programming›22p1,
author = {Guillermo Polito and Nahuel Palumbo and Soufyane Labsari and Stéphane Ducasse and Pablo Tesone},
title = {Interpreter Register Autolocalisation: Improving the Performance of Efficient Interpreters},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {1--5},
doi = {10.1145/3532512.3532518},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-BOXER: "Automatic Programming and ..."
Automatic Programming and Education
Clayton Lewis
(University of Colorado Boulder, USA)
Automatic programming, as supported by recent language-model based AI systems, potentially allows a new approach to making computation a useful tool for learning, a goal of the Boxer project. This paper shows that the Codex system can be used to support some of the explorations in mathematics for which Boxer has been used. Virtually no knowledge of programming is required. Reflecting on the lessons from this exploration may sharpen the goals we bring to educational computing. What knowledge about computing, as distinct from the ability to creatively use computing, should learners gain?
@InProceedings{‹Programming›22p70,
author = {Clayton Lewis},
title = {Automatic Programming and Education},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {70--80},
doi = {10.1145/3532512.3539664},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "An Experiment in Live Collaborative ..."
An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform
Yoshiki Ohshima, Aran Lunzer, Jenn Evans, Vanessa Freudenberg, Brian Upton, and David A. Smith
(Croquet Corporation, USA; Croquet Corporation, Canada)
This paper describes our experiences in building a live collaborative programming environment on top of the JavaScript version of the Croquet shared experience platform.
Croquet provides a clean substrate for building real-time collaborative applications. We created an application framework that supports live programming, and used that framework to build the Greenlight collaborative application, then in turn, modified it to do live programming experiments. The environment allows multiple users to modify the running application from within, with changes taking effect immediately.
The experiment was inspired by earlier work including Douglas Engelbart’s oN-Line System (NLS) and the Kansas system in Self. Analogically, the system is like the Smalltalk environment made collaborative.
In this paper we explain the Croquet architecture, its library and framework, and the Greenlight application used to make the live programming environment.
The standard version of Greenlight is available at https://croquet.io/greenlight, and the modified demo system is available at https://croquet.io/scripting.
@InProceedings{‹Programming›22p46,
author = {Yoshiki Ohshima and Aran Lunzer and Jenn Evans and Vanessa Freudenberg and Brian Upton and David A. Smith},
title = {An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {46--53},
doi = {10.1145/3532512.3535224},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "CodeMap: A Graphical Note-Taking ..."
CodeMap: A Graphical Note-Taking Tool Cooperating with an Integrated Development Environment
Rikito Taniguchi and Hidehiko Masuhara
(Tokyo Institute of Technology, Japan)
Program comprehension is an important yet difficult activity in a software development process. One of the main causes of the difficulty is its cognitive overhead for maintaining the mental models, which consist of roles of program elements and relationships between them. Though researchers have been working on tools to help maintaining the mental models, existing tools have high adoption barrier and support only a few programming languages, which hinders wide-range of programmers from using the program comprehension tools. We propose CodeMap, a graphical note-taking tool for offloading the mental models onto a visual representation. We designed CodeMap by considering familiarity and availability for practitioners. Our tool allows programmers to extract interested information into a graphical note with a few keyboard/mouse operations, and support many programming languages by using the {language server protocol}. In this paper, we present the design and implementation of CodeMap, and discuss possible features that could be useful for program comprehension.
@InProceedings{‹Programming›22p54,
author = {Rikito Taniguchi and Hidehiko Masuhara},
title = {CodeMap: A Graphical Note-Taking Tool Cooperating with an Integrated Development Environment},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {54--59},
doi = {10.1145/3532512.3535225},
year = {2022},
}
Publisher's Version
Video
‹Programming› '22 Companion-MOREVMS: "Toward Just-in-Time and Language-Agnostic ..."
Toward Just-in-Time and Language-Agnostic Mutation Testing
Stefan Reschke, Toni Mattis, Fabio Niephaus, and Robert Hirschfeld
(University of Potsdam, Germany; Oracle Labs, Germany)
Mutation Testing is a popular approach to determine the quality of a suite of unit tests. It is based on the idea that introducing faults into a system under test (SUT) should cause tests to fail, otherwise, the test suite might be of insufficient quality. In the language of mutation testing, such a fault is referred to as “mutation”, and an instance of the SUT’s code that contains the mutation is referred to as “mutant”. Mutation testing is computationally expensive and time-consuming. Reasons for this include, for example, a high number of mutations to consider, interrelations between these mutations, and mutant-associated costs such as the cost of mutant creation or the cost of checking whether any tests fail in response. Furthermore, implementing a reliable tool for automatic mutation testing is a significant effort for any language. As a result, mutation testing is only available for some languages.
Present mutation tools often rely on modifying code or binary executables. We refer to this as “ahead-of-time” mutation testing. Oftentimes, they neither take dynamic information that is only available at run-time into account nor alter program behavior at run-time. However, mutating via the latter could save costs on mutant creation: If the corresponding module of code is compiled, only the mutated section of code needs to be recompiled. Run-time information (like previous execution results selected by an initial test run) could help to determine the utility of a mutant. Skipping mutants of low utility could have an impact on mutation testing efficiency. We refer to this approach as just-in-time mutation testing.
In this paper, we provide a proof of concept for just-in-time and language-agnostic mutation testing. We present preliminary results of a feasibility study that explores the implementation of just-in-time mutation testing based on Truffle’s instrumentation API. Based on these results, future research can evaluate the implications of just-in-time and language-agnostic mutation testing.
@InProceedings{‹Programming›22p6,
author = {Stefan Reschke and Toni Mattis and Fabio Niephaus and Robert Hirschfeld},
title = {Toward Just-in-Time and Language-Agnostic Mutation Testing},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {6--11},
doi = {10.1145/3532512.3532514},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Toward Understanding Task ..."
Toward Understanding Task Complexity in Maintenance-Based Studies of Programming Tools
Patrick Rein, Tom Beckmann, Toni Mattis, and Robert Hirschfeld
(HPI, Germany)
Researchers conducting studies on programming tools often make use of maintenance tasks. The complexity of these tasks can influence the behavior of participants significantly. At the same time, the complexity of tasks is difficult to pinpoint due to the many sources of complexity for maintenance tasks. As a result, researchers may struggle to deliberately decide in which regard their tasks should be complex and in which regard they should be simple. To help researchers make more deliberate decisions about the complexity of their tasks, we discuss different factors of task complexity. We draw these factors from previous user studies on programming tools as well as from a task complexity model from ergonomics research that we apply to maintenance tasks. In the end, task complexity might always be too complex to be fully controlled. Nevertheless, we hope that our discussion helps other researchers to decide in which dimensions their tasks are complex and in which dimensions they want to keep them simple.
@InProceedings{‹Programming›22p38,
author = {Patrick Rein and Tom Beckmann and Toni Mattis and Robert Hirschfeld},
title = {Toward Understanding Task Complexity in Maintenance-Based Studies of Programming Tools},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {38--45},
doi = {10.1145/3532512.3535223},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-MOREVMS: "Toward Just-in-Time and Language-Agnostic ..."
Toward Just-in-Time and Language-Agnostic Mutation Testing
Stefan Reschke, Toni Mattis, Fabio Niephaus, and Robert Hirschfeld
(University of Potsdam, Germany; Oracle Labs, Germany)
Mutation Testing is a popular approach to determine the quality of a suite of unit tests. It is based on the idea that introducing faults into a system under test (SUT) should cause tests to fail, otherwise, the test suite might be of insufficient quality. In the language of mutation testing, such a fault is referred to as “mutation”, and an instance of the SUT’s code that contains the mutation is referred to as “mutant”. Mutation testing is computationally expensive and time-consuming. Reasons for this include, for example, a high number of mutations to consider, interrelations between these mutations, and mutant-associated costs such as the cost of mutant creation or the cost of checking whether any tests fail in response. Furthermore, implementing a reliable tool for automatic mutation testing is a significant effort for any language. As a result, mutation testing is only available for some languages.
Present mutation tools often rely on modifying code or binary executables. We refer to this as “ahead-of-time” mutation testing. Oftentimes, they neither take dynamic information that is only available at run-time into account nor alter program behavior at run-time. However, mutating via the latter could save costs on mutant creation: If the corresponding module of code is compiled, only the mutated section of code needs to be recompiled. Run-time information (like previous execution results selected by an initial test run) could help to determine the utility of a mutant. Skipping mutants of low utility could have an impact on mutation testing efficiency. We refer to this approach as just-in-time mutation testing.
In this paper, we provide a proof of concept for just-in-time and language-agnostic mutation testing. We present preliminary results of a feasibility study that explores the implementation of just-in-time mutation testing based on Truffle’s instrumentation API. Based on these results, future research can evaluate the implications of just-in-time and language-agnostic mutation testing.
@InProceedings{‹Programming›22p6,
author = {Stefan Reschke and Toni Mattis and Fabio Niephaus and Robert Hirschfeld},
title = {Toward Just-in-Time and Language-Agnostic Mutation Testing},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {6--11},
doi = {10.1145/3532512.3532514},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "An Experiment in Live Collaborative ..."
An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform
Yoshiki Ohshima, Aran Lunzer, Jenn Evans, Vanessa Freudenberg, Brian Upton, and David A. Smith
(Croquet Corporation, USA; Croquet Corporation, Canada)
This paper describes our experiences in building a live collaborative programming environment on top of the JavaScript version of the Croquet shared experience platform.
Croquet provides a clean substrate for building real-time collaborative applications. We created an application framework that supports live programming, and used that framework to build the Greenlight collaborative application, then in turn, modified it to do live programming experiments. The environment allows multiple users to modify the running application from within, with changes taking effect immediately.
The experiment was inspired by earlier work including Douglas Engelbart’s oN-Line System (NLS) and the Kansas system in Self. Analogically, the system is like the Smalltalk environment made collaborative.
In this paper we explain the Croquet architecture, its library and framework, and the Greenlight application used to make the live programming environment.
The standard version of Greenlight is available at https://croquet.io/greenlight, and the modified demo system is available at https://croquet.io/scripting.
@InProceedings{‹Programming›22p46,
author = {Yoshiki Ohshima and Aran Lunzer and Jenn Evans and Vanessa Freudenberg and Brian Upton and David A. Smith},
title = {An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {46--53},
doi = {10.1145/3532512.3535224},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-MOREVMS: "Interpreter Register Autolocalisation: ..."
Interpreter Register Autolocalisation: Improving the Performance of Efficient Interpreters
Guillermo Polito, Nahuel Palumbo, Soufyane Labsari, Stéphane Ducasse, and Pablo Tesone
(University of Lille, France; CNRS, France; Inria, France; Centrale Lille, France)
Language interpreters are generally slower than (JIT) compiled implementations because they trade off simplicity for performance and portability. They are nevertheless still important in modern Virtual Machines (VMs): e.g., not all code is hot and arrives to later compilation stages.
We propose to study more in depth the idea of interpreter registers: interpreter variables that are critical to the efficient execution of the interpreter loop. We present an automatic interpreter transformation for bytecode interpreters written in C called autolocalization. Autolocalisation makes interpreter registers local to the interpreter loop with the objective of keeping them in registers and makes those values available for other routines in the VM runtime automatically when required.
We build autolocalisation in Slang, Pharo’s VM generator framework, and evaluate the performance of several benchmarks on different configurations localising IP, SP, FP and their combinations. We show that the C compiler does not make this optimization automatically, and that this transformation yields improvements of up to 1.92x on x86-64. Moreover, we show that the performance of our automatic approach is comparable to the previously approach handwritten in the Pharo VM while making it easier to read, modify and debug.
@InProceedings{‹Programming›22p1,
author = {Guillermo Polito and Nahuel Palumbo and Soufyane Labsari and Stéphane Ducasse and Pablo Tesone},
title = {Interpreter Register Autolocalisation: Improving the Performance of Efficient Interpreters},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {1--5},
doi = {10.1145/3532512.3532518},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-MOREVMS: "Interpreter Register Autolocalisation: ..."
Interpreter Register Autolocalisation: Improving the Performance of Efficient Interpreters
Guillermo Polito, Nahuel Palumbo, Soufyane Labsari, Stéphane Ducasse, and Pablo Tesone
(University of Lille, France; CNRS, France; Inria, France; Centrale Lille, France)
Language interpreters are generally slower than (JIT) compiled implementations because they trade off simplicity for performance and portability. They are nevertheless still important in modern Virtual Machines (VMs): e.g., not all code is hot and arrives to later compilation stages.
We propose to study more in depth the idea of interpreter registers: interpreter variables that are critical to the efficient execution of the interpreter loop. We present an automatic interpreter transformation for bytecode interpreters written in C called autolocalization. Autolocalisation makes interpreter registers local to the interpreter loop with the objective of keeping them in registers and makes those values available for other routines in the VM runtime automatically when required.
We build autolocalisation in Slang, Pharo’s VM generator framework, and evaluate the performance of several benchmarks on different configurations localising IP, SP, FP and their combinations. We show that the C compiler does not make this optimization automatically, and that this transformation yields improvements of up to 1.92x on x86-64. Moreover, we show that the performance of our automatic approach is comparable to the previously approach handwritten in the Pharo VM while making it easier to read, modify and debug.
@InProceedings{‹Programming›22p1,
author = {Guillermo Polito and Nahuel Palumbo and Soufyane Labsari and Stéphane Ducasse and Pablo Tesone},
title = {Interpreter Register Autolocalisation: Improving the Performance of Efficient Interpreters},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {1--5},
doi = {10.1145/3532512.3532518},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Toward Understanding Task ..."
Toward Understanding Task Complexity in Maintenance-Based Studies of Programming Tools
Patrick Rein, Tom Beckmann, Toni Mattis, and Robert Hirschfeld
(HPI, Germany)
Researchers conducting studies on programming tools often make use of maintenance tasks. The complexity of these tasks can influence the behavior of participants significantly. At the same time, the complexity of tasks is difficult to pinpoint due to the many sources of complexity for maintenance tasks. As a result, researchers may struggle to deliberately decide in which regard their tasks should be complex and in which regard they should be simple. To help researchers make more deliberate decisions about the complexity of their tasks, we discuss different factors of task complexity. We draw these factors from previous user studies on programming tools as well as from a task complexity model from ergonomics research that we apply to maintenance tasks. In the end, task complexity might always be too complex to be fully controlled. Nevertheless, we hope that our discussion helps other researchers to decide in which dimensions their tasks are complex and in which dimensions they want to keep them simple.
@InProceedings{‹Programming›22p38,
author = {Patrick Rein and Tom Beckmann and Toni Mattis and Robert Hirschfeld},
title = {Toward Understanding Task Complexity in Maintenance-Based Studies of Programming Tools},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {38--45},
doi = {10.1145/3532512.3535223},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Example Mining: Assisting ..."
Example Mining: Assisting Example Creation to Enhance Code Comprehension
Eva Krebs, Patrick Rein, and Robert Hirschfeld
(HPI, Germany)
Programmers often use examples with concrete values to better understand code. Code by itself is abstract, which empowers it to be used for a variety of uses, but can be difficult to grasp by developers. Babylonian Programming addresses this by allowing programmers to concretize their code by defining and visualizing examples directly in the code itself while editing.
Currently, Babylonian Programming implementations such as Babylonian/S require programmers to define examples manually. For examples containing small objects this is straightforward, however when creating large or complex objects it is not. Sometimes, workarounds such as copying existing code pieces or trying to recreate existing objects are used to reuse information already present in the system, but these workarounds can be error-prone and also time-consuming.
In this paper, we propose Example Mining to address this issue by providing techniques and integrated tools to mine examples from existing sources similar to concepts from run-time tracing and test case extraction. Example mining introduces concepts to mine examples from tests, debugging sessions, and traces of actual usage of the system under development. All tools were implemented for Babylonian/S in Squeak/Smalltalk.
We demonstrate the usefulness of the tools through walkthroughs. Our tools provide examples for many methods immediately and automatically. As a consequence, programmers have more immediate access to dynamic feedback on their abstract code, making code comprehension and debugging more effective.
@InProceedings{‹Programming›22p60,
author = {Eva Krebs and Patrick Rein and Robert Hirschfeld},
title = {Example Mining: Assisting Example Creation to Enhance Code Comprehension},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {60--66},
doi = {10.1145/3532512.3535226},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-MOREVMS: "Toward Just-in-Time and Language-Agnostic ..."
Toward Just-in-Time and Language-Agnostic Mutation Testing
Stefan Reschke, Toni Mattis, Fabio Niephaus, and Robert Hirschfeld
(University of Potsdam, Germany; Oracle Labs, Germany)
Mutation Testing is a popular approach to determine the quality of a suite of unit tests. It is based on the idea that introducing faults into a system under test (SUT) should cause tests to fail, otherwise, the test suite might be of insufficient quality. In the language of mutation testing, such a fault is referred to as “mutation”, and an instance of the SUT’s code that contains the mutation is referred to as “mutant”. Mutation testing is computationally expensive and time-consuming. Reasons for this include, for example, a high number of mutations to consider, interrelations between these mutations, and mutant-associated costs such as the cost of mutant creation or the cost of checking whether any tests fail in response. Furthermore, implementing a reliable tool for automatic mutation testing is a significant effort for any language. As a result, mutation testing is only available for some languages.
Present mutation tools often rely on modifying code or binary executables. We refer to this as “ahead-of-time” mutation testing. Oftentimes, they neither take dynamic information that is only available at run-time into account nor alter program behavior at run-time. However, mutating via the latter could save costs on mutant creation: If the corresponding module of code is compiled, only the mutated section of code needs to be recompiled. Run-time information (like previous execution results selected by an initial test run) could help to determine the utility of a mutant. Skipping mutants of low utility could have an impact on mutation testing efficiency. We refer to this approach as just-in-time mutation testing.
In this paper, we provide a proof of concept for just-in-time and language-agnostic mutation testing. We present preliminary results of a feasibility study that explores the implementation of just-in-time mutation testing based on Truffle’s instrumentation API. Based on these results, future research can evaluate the implications of just-in-time and language-agnostic mutation testing.
@InProceedings{‹Programming›22p6,
author = {Stefan Reschke and Toni Mattis and Fabio Niephaus and Robert Hirschfeld},
title = {Toward Just-in-Time and Language-Agnostic Mutation Testing},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {6--11},
doi = {10.1145/3532512.3532514},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "A Live Environment to Improve ..."
A Live Environment to Improve the Refactoring Experience
Sara Fernandes, Ademar Aguiar, and André Restivo
(University of Porto, Portugal)
Refactoring helps improve the design of software systems, making them more understandable, readable, maintainable, cleaner, and self-explanatory. Many refactoring tools allow developers to select and execute the best refactorings for their code. However, most of them lack quick and continuous feedback, support, and guidance, leading to a poor refactoring experience. To fill this gap, we are researching ways to increase liveness in refactoring. Live Refactoring consists of continuously knowing, in real-time, what and why to refactor. To explore the concept of Live Refactoring and its main components --- recommendation, visualization, and application, we prototyped a Live Refactoring Environment focused on the Extract Method refactoring. With it, developers can receive recommendations about the best refactoring options and have support to apply them automatically. This work helped us reinforce the hypothesis that early and continuous refactoring feedback helps to shorten the time needed to create high-quality systems.
@InProceedings{‹Programming›22p30,
author = {Sara Fernandes and Ademar Aguiar and André Restivo},
title = {A Live Environment to Improve the Refactoring Experience},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {30--37},
doi = {10.1145/3532512.3535222},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Programming in an fMRI Scanner: ..."
Programming in an fMRI Scanner: A Report from the Field
Steven Tanimoto, Rob Thompson, Todd Richards, Cheri Yates, and Virginia Berninger
(University of Washington, USA; Colorado School of Mines, USA; Seattle Childrens Hospital, USA)
A preliminary study is reported in which six human subjects were scanned while performing a simple form of computer programming. Functional magnetic resonance imaging typically precludes the use of ordinary computing equipment due to safety concerns when items with metallic parts are in the scanning room. We used a special visual programming environment, "Kokopelli's World," for which an optics-only trackball was sufficient. This research methodology is described. Aspects of the experience of programming, by one of the authors, in the fMRI scanner are reported. An analysis of the data from the scanning is presented, and brain areas where activity for coding exceeded activity for a control task were identified and are presented here. These observations suggest hypotheses and directions for future research. One hypothesis is that particular aspects of programming are inherently and measurably pleasurable.
@InProceedings{‹Programming›22p12,
author = {Steven Tanimoto and Rob Thompson and Todd Richards and Cheri Yates and Virginia Berninger},
title = {Programming in an fMRI Scanner: A Report from the Field},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {12--21},
doi = {10.1145/3532512.3535220},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-POSTERS: "Enhancing DrRacket with Dodona ..."
Enhancing DrRacket with Dodona for Learning Scheme
Turgut Reis Kursun, Mathijs Saey, and Viviane Jonckers
(Vrije Universiteit Brussel, Belgium)
Learning how to program in a typical setting is challenging because feedback can often not be given immediately. Tracking the work of a student is also challenging for teachers, as the work of a student is not readily accessible. Therefore, digital learning environments have been considered to facilitate the learning process. We aim to facilitate the learning process of beginner students learning Scheme. To this end, we have developed a plugin for the DrRacket IDE (used for Scheme), that communicates with Dodona, a web service geared towards helping students learn how to code. Our plugin uses the information provided by this platform to give students immediate feedback on their code inside the DrRacket IDE. To enable the above, we extended the Dodona platform to support Scheme. As part of our extensions, we introduced several dynamic and static analyses to the Dodona platform, which we use to verify additional properties of the code submitted by students.
@InProceedings{‹Programming›22p81,
author = {Turgut Reis Kursun and Mathijs Saey and Viviane Jonckers},
title = {Enhancing DrRacket with Dodona for Learning Scheme},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {81--82},
doi = {10.1145/3532512.3564142},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "An Experiment in Live Collaborative ..."
An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform
Yoshiki Ohshima, Aran Lunzer, Jenn Evans, Vanessa Freudenberg, Brian Upton, and David A. Smith
(Croquet Corporation, USA; Croquet Corporation, Canada)
This paper describes our experiences in building a live collaborative programming environment on top of the JavaScript version of the Croquet shared experience platform.
Croquet provides a clean substrate for building real-time collaborative applications. We created an application framework that supports live programming, and used that framework to build the Greenlight collaborative application, then in turn, modified it to do live programming experiments. The environment allows multiple users to modify the running application from within, with changes taking effect immediately.
The experiment was inspired by earlier work including Douglas Engelbart’s oN-Line System (NLS) and the Kansas system in Self. Analogically, the system is like the Smalltalk environment made collaborative.
In this paper we explain the Croquet architecture, its library and framework, and the Greenlight application used to make the live programming environment.
The standard version of Greenlight is available at https://croquet.io/greenlight, and the modified demo system is available at https://croquet.io/scripting.
@InProceedings{‹Programming›22p46,
author = {Yoshiki Ohshima and Aran Lunzer and Jenn Evans and Vanessa Freudenberg and Brian Upton and David A. Smith},
title = {An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {46--53},
doi = {10.1145/3532512.3535224},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "CodeMap: A Graphical Note-Taking ..."
CodeMap: A Graphical Note-Taking Tool Cooperating with an Integrated Development Environment
Rikito Taniguchi and Hidehiko Masuhara
(Tokyo Institute of Technology, Japan)
Program comprehension is an important yet difficult activity in a software development process. One of the main causes of the difficulty is its cognitive overhead for maintaining the mental models, which consist of roles of program elements and relationships between them. Though researchers have been working on tools to help maintaining the mental models, existing tools have high adoption barrier and support only a few programming languages, which hinders wide-range of programmers from using the program comprehension tools. We propose CodeMap, a graphical note-taking tool for offloading the mental models onto a visual representation. We designed CodeMap by considering familiarity and availability for practitioners. Our tool allows programmers to extract interested information into a graphical note with a few keyboard/mouse operations, and support many programming languages by using the {language server protocol}. In this paper, we present the design and implementation of CodeMap, and discuss possible features that could be useful for program comprehension.
@InProceedings{‹Programming›22p54,
author = {Rikito Taniguchi and Hidehiko Masuhara},
title = {CodeMap: A Graphical Note-Taking Tool Cooperating with an Integrated Development Environment},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {54--59},
doi = {10.1145/3532512.3535225},
year = {2022},
}
Publisher's Version
Video
‹Programming› '22 Companion-PX: "Programming in an fMRI Scanner: ..."
Programming in an fMRI Scanner: A Report from the Field
Steven Tanimoto, Rob Thompson, Todd Richards, Cheri Yates, and Virginia Berninger
(University of Washington, USA; Colorado School of Mines, USA; Seattle Childrens Hospital, USA)
A preliminary study is reported in which six human subjects were scanned while performing a simple form of computer programming. Functional magnetic resonance imaging typically precludes the use of ordinary computing equipment due to safety concerns when items with metallic parts are in the scanning room. We used a special visual programming environment, "Kokopelli's World," for which an optics-only trackball was sufficient. This research methodology is described. Aspects of the experience of programming, by one of the authors, in the fMRI scanner are reported. An analysis of the data from the scanning is presented, and brain areas where activity for coding exceeded activity for a control task were identified and are presented here. These observations suggest hypotheses and directions for future research. One hypothesis is that particular aspects of programming are inherently and measurably pleasurable.
@InProceedings{‹Programming›22p12,
author = {Steven Tanimoto and Rob Thompson and Todd Richards and Cheri Yates and Virginia Berninger},
title = {Programming in an fMRI Scanner: A Report from the Field},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {12--21},
doi = {10.1145/3532512.3535220},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-MOREVMS: "Interpreter Register Autolocalisation: ..."
Interpreter Register Autolocalisation: Improving the Performance of Efficient Interpreters
Guillermo Polito, Nahuel Palumbo, Soufyane Labsari, Stéphane Ducasse, and Pablo Tesone
(University of Lille, France; CNRS, France; Inria, France; Centrale Lille, France)
Language interpreters are generally slower than (JIT) compiled implementations because they trade off simplicity for performance and portability. They are nevertheless still important in modern Virtual Machines (VMs): e.g., not all code is hot and arrives to later compilation stages.
We propose to study more in depth the idea of interpreter registers: interpreter variables that are critical to the efficient execution of the interpreter loop. We present an automatic interpreter transformation for bytecode interpreters written in C called autolocalization. Autolocalisation makes interpreter registers local to the interpreter loop with the objective of keeping them in registers and makes those values available for other routines in the VM runtime automatically when required.
We build autolocalisation in Slang, Pharo’s VM generator framework, and evaluate the performance of several benchmarks on different configurations localising IP, SP, FP and their combinations. We show that the C compiler does not make this optimization automatically, and that this transformation yields improvements of up to 1.92x on x86-64. Moreover, we show that the performance of our automatic approach is comparable to the previously approach handwritten in the Pharo VM while making it easier to read, modify and debug.
@InProceedings{‹Programming›22p1,
author = {Guillermo Polito and Nahuel Palumbo and Soufyane Labsari and Stéphane Ducasse and Pablo Tesone},
title = {Interpreter Register Autolocalisation: Improving the Performance of Efficient Interpreters},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {1--5},
doi = {10.1145/3532512.3532518},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Programming in an fMRI Scanner: ..."
Programming in an fMRI Scanner: A Report from the Field
Steven Tanimoto, Rob Thompson, Todd Richards, Cheri Yates, and Virginia Berninger
(University of Washington, USA; Colorado School of Mines, USA; Seattle Childrens Hospital, USA)
A preliminary study is reported in which six human subjects were scanned while performing a simple form of computer programming. Functional magnetic resonance imaging typically precludes the use of ordinary computing equipment due to safety concerns when items with metallic parts are in the scanning room. We used a special visual programming environment, "Kokopelli's World," for which an optics-only trackball was sufficient. This research methodology is described. Aspects of the experience of programming, by one of the authors, in the fMRI scanner are reported. An analysis of the data from the scanning is presented, and brain areas where activity for coding exceeded activity for a control task were identified and are presented here. These observations suggest hypotheses and directions for future research. One hypothesis is that particular aspects of programming are inherently and measurably pleasurable.
@InProceedings{‹Programming›22p12,
author = {Steven Tanimoto and Rob Thompson and Todd Richards and Cheri Yates and Virginia Berninger},
title = {Programming in an fMRI Scanner: A Report from the Field},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {12--21},
doi = {10.1145/3532512.3535220},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "An Experiment in Live Collaborative ..."
An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform
Yoshiki Ohshima, Aran Lunzer, Jenn Evans, Vanessa Freudenberg, Brian Upton, and David A. Smith
(Croquet Corporation, USA; Croquet Corporation, Canada)
This paper describes our experiences in building a live collaborative programming environment on top of the JavaScript version of the Croquet shared experience platform.
Croquet provides a clean substrate for building real-time collaborative applications. We created an application framework that supports live programming, and used that framework to build the Greenlight collaborative application, then in turn, modified it to do live programming experiments. The environment allows multiple users to modify the running application from within, with changes taking effect immediately.
The experiment was inspired by earlier work including Douglas Engelbart’s oN-Line System (NLS) and the Kansas system in Self. Analogically, the system is like the Smalltalk environment made collaborative.
In this paper we explain the Croquet architecture, its library and framework, and the Greenlight application used to make the live programming environment.
The standard version of Greenlight is available at https://croquet.io/greenlight, and the modified demo system is available at https://croquet.io/scripting.
@InProceedings{‹Programming›22p46,
author = {Yoshiki Ohshima and Aran Lunzer and Jenn Evans and Vanessa Freudenberg and Brian Upton and David A. Smith},
title = {An Experiment in Live Collaborative Programming on the Croquet Shared Experience Platform},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {46--53},
doi = {10.1145/3532512.3535224},
year = {2022},
}
Publisher's Version
‹Programming› '22 Companion-PX: "Programming in an fMRI Scanner: ..."
Programming in an fMRI Scanner: A Report from the Field
Steven Tanimoto, Rob Thompson, Todd Richards, Cheri Yates, and Virginia Berninger
(University of Washington, USA; Colorado School of Mines, USA; Seattle Childrens Hospital, USA)
A preliminary study is reported in which six human subjects were scanned while performing a simple form of computer programming. Functional magnetic resonance imaging typically precludes the use of ordinary computing equipment due to safety concerns when items with metallic parts are in the scanning room. We used a special visual programming environment, "Kokopelli's World," for which an optics-only trackball was sufficient. This research methodology is described. Aspects of the experience of programming, by one of the authors, in the fMRI scanner are reported. An analysis of the data from the scanning is presented, and brain areas where activity for coding exceeded activity for a control task were identified and are presented here. These observations suggest hypotheses and directions for future research. One hypothesis is that particular aspects of programming are inherently and measurably pleasurable.
@InProceedings{‹Programming›22p12,
author = {Steven Tanimoto and Rob Thompson and Todd Richards and Cheri Yates and Virginia Berninger},
title = {Programming in an fMRI Scanner: A Report from the Field},
booktitle = {Proc.\ ‹Programming›},
publisher = {ACM},
pages = {12--21},
doi = {10.1145/3532512.3535220},
year = {2022},
}
Publisher's Version