Example-based live programming for everyone: building language-agnostic tools for live programming with LSP and GraalVM

Niephaus, Fabio; Rein, Patrick; Edding, Jakob; Hering, Jonas; König, Bastian; Opahle, Kolya; Scordialo, Nico; Hirschfeld, Robert

doi:10.1145/3426428.3426919

Cited by 13 publications

(2 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This results in both the applications and the tools used to create these applications being implemented in the same environment. Lively was chosen for this project because the combination of live programming and an S3 allows us to implement and execute both a programming concept and its debugging tools in the same environment (Niephaus et al 2020). Figure 23 shows how many parts of the system had to be adapted, ranging from language rewriting, providing new basic components, and creating new and adapting existing tools 6 .…”

Section: Methodsmentioning

confidence: 99%

Extensible Tooling for Reactive Programming Based on Active Expressions.

Ramson,

Brand,

Lincke

et al. 2024

JOT

View full text Add to dashboard Cite

Reactive programming uses dedicated language concepts such as signals, data bindings, and constraints, so developers can better express behavior that is triggered by data changes and user interactions. As applications also contain aspects that cannot be easily expressed through reactive programming, reactive concepts are often integrated into more generally applicable imperative programming languages. Although such language integrations are readily available, working on reactive code with tools designed for imperative code is hard, because without dedicated tool support implementation details may leak unintentionally. There are special tools for reactive programming available, however, they are expensive to make.Further, a tool typically supports only a single language concept and cannot be applied to others even though they build on similar ideas. Consequently, control flow or data flow cannot be followed between concepts.We propose to leverage the commonalities found in reactive programming concepts to create reusable tool components for data gathering and visualization. To do so we create a toolset working on a generalization of reactive programming concepts, Active Expressions. By building upon the generic tool components, tool developers can create tool support for specific reactive concepts. Furthermore, multiple reactive concepts and their potentially complex interaction can be explored in one shared environment. We implemented the approach in the Lively4 Web-based JavaScript development environment using its Active Expression framework. Our toolset gathers relevant data about the reactive system and visualizes it using code annotations, an overview tree, an event timeline, and a dependency graph. We evaluate the reusability of this toolset by adapting it to two more concepts: signals, and implicit layer activation, known from context-oriented programming. We found that most of the functionality provided by the toolset can be reused, thus, reducing the implementation effort. Further, we show that multiple reactive concepts can be supported by the same common toolset. Programmers can use and debug multiple different reactive concepts simultaneously, without requiring new tools for each one. For future work, we believe our common toolset provides a starting point for researching the interplay between multiple reactive programming concepts.

show abstract

Section: Methodsmentioning

confidence: 99%

Extensible Tooling for Reactive Programming Based on Active Expressions.

Ramson,

Brand,

Lincke

et al. 2024

JOT

View full text Add to dashboard Cite

show abstract

“…The case of the graphical syntax is particularly interesting, because it led to the definition of two different protocols for the same purpose: the Graphical Language Server Protocol 5 and the Graphical Server Protocol 6 . Another way to extend the features of LSP that was used in works such as [9] and [8] consists in arbitrarily adding support for new messages to a server and a client, and consider that all existing implementations will ignore them if they don't support them. While these two works provide very useful contributions, such an implementation raises concerns of maintainability and interoperability, which furthers motivates our vision.…”

Section: Motivationmentioning

confidence: 99%