pith. sign in

arxiv: 2606.18481 · v1 · pith:DMRLR3MSnew · submitted 2026-06-16 · 💻 cs.SE · cs.CY· cs.HC

Designing L5: A Permacomputing Approach to Creative Coding

Lee Tusman , Kit Kuksenok This is my paper

Pith reviewed 2026-06-26 23:18 UTC · model grok-4.3

classification 💻 cs.SE cs.CYcs.HC
keywords creative codingpermacomputingsustainabilitydesign trade-offssoftware accessibilitycase studieslualong-term stability
0
0 comments X

The pith

Creative coding tools must navigate competing sustainability and usability values transparently instead of optimizing for a single metric.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces L5, a Lua-based creative coding library built on the LOVE framework, as a way to bring permacomputing principles to artists and learners. It walks through five case studies that each surface a tension, such as hiding or revealing seams, cutting resource use, locking in stability, limiting features, and writing documentation for low-resource access. A sympathetic reader would care because this challenges the default of maximizing beginner ease at any cost. If the claim holds, creative coding libraries can last longer by making their value choices visible rather than pretending one goal can dominate all others.

Core claim

L5 applies permacomputing principles to creative coding libraries by documenting five design tensions: balancing perceived simplicity against exposing underlying mechanics, designing for lower resource consumption, ensuring long-term stability, constraining functionality to maintain focus, and creating documentation usable under resource limits. The paper states that rather than optimizing for any single metric, sustainable creative tools succeed when they navigate these competing values in an open way.

What carries the argument

The five case studies of L5's design decisions that make trade-offs between permacomputing sustainability goals and creative coding accessibility explicit.

If this is right

  • Creative coding libraries can maintain beginner reach while adopting resource limits if the limits are documented as choices.
  • Long-term stability in these tools follows from accepting bounded functionality rather than adding every requested feature.
  • Documentation must be designed for users who may lack high-bandwidth or always-on connections.
  • Perceived simplicity can include making the system's seams visible when that visibility supports sustainability.
  • Transparent navigation of values becomes a required practice for any creative coding library that claims durability.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same transparent trade-off approach could apply to other creative software such as visual programming environments or shader tools.
  • A direct test would measure whether L5 users on low-power devices show higher continued use over years than users of higher-resource libraries.
  • Communities around existing creative coding tools might adopt similar case-study documentation to surface their own hidden value conflicts.
  • This framing connects creative coding to wider questions of software longevity without requiring new technical inventions.

Load-bearing premise

Permacomputing principles can be applied to creative coding libraries without reducing their accessibility for artists and learners.

What would settle it

A usage study or adoption comparison showing that artists and learners avoid L5 because its constraints on simplicity, features, or documentation make it less usable than standard alternatives like p5.js.

Figures

Figures reproduced from arXiv: 2606.18481 by Kit Kuksenok, Lee Tusman.

Figure 1
Figure 1. Figure 1: L5 code sketch written with L5 library in Geany editor, with running program output after mouse interaction. A circle is drawn continuously with mouse interaction. 1.3 Design Philosophy: From Access to Sustainability Just as p5.js centers accessibility through its Access Statement [17], L5 extends this practically by centering sustainability through permacomputing principles [23]. The p5.js Access Statemen… view at source ↗
read the original abstract

Creative coding libraries provide high-level tools that make computational and algorithmic art accessible to artists and learners. Processing/p5 is one such family of libraries, known for its beginner-friendly approach and wide reach across artistic and technical communities. L5 is a new member of this family, implemented in Lua using the LOVE framework. It applies permacomputing principles, a movement addressing sustainability in computing inspired by permaculture, bringing these values to a community of practice not historically centered on them. This paper explores L5's design decisions and tensions between sustainability and usability through five case studies: 1. balancing perceived simplicity versus exposing the seams, 2. designing for lower resource consumption, 3. ensuring long-term stability, 4. constraining functionality, and 5. designing documentation for resource-constrained access. Rather than optimizing for a single metric, sustainable creative tools require navigating competing values transparently.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The manuscript introduces L5, a Lua-based creative coding library built on the LOVE framework as a new member of the Processing/p5 family. It applies permacomputing principles (drawn from permaculture) to address sustainability in computing and explores the resulting design tensions with usability through five enumerated case studies: balancing perceived simplicity versus exposing seams, designing for lower resource consumption, ensuring long-term stability, constraining functionality, and designing documentation for resource-constrained access. The central claim is that sustainable creative tools require transparent navigation of competing values rather than optimization for any single metric.

Significance. If the case studies demonstrate that the described decisions instantiate permacomputing principles while preserving accessibility, the work supplies a reflective design account that could inform sustainable tool-building practices in artistic and educational computing communities, extending permacomputing ideas into a domain not previously centered on them.

major comments (2)
  1. [Abstract and Case Studies] Abstract and the five case studies: the central claim that L5 navigates the listed tensions rests entirely on descriptive narrative; no measurements, comparisons to p5.js/Processing, user studies, or outcome data are supplied to show that the decisions actually achieved lower resource use, maintained stability, or preserved accessibility, which is load-bearing for the conclusion.
  2. [Introduction / permacomputing framing] Framing section on permacomputing application: the claim that these principles can be brought to the creative-coding community without undermining accessibility for artists and learners is asserted but lacks any concrete test, metric, or falsifiable check (e.g., comparison of onboarding time or resource footprint for novice users), creating a correctness risk for the paper's positioning of L5.
minor comments (1)
  1. Number the five case studies consistently in both the abstract and body text and add explicit cross-references so readers can locate the supporting narrative for each tension.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the detailed and constructive comments. The manuscript is a reflective design paper that uses case studies to explore tensions rather than an empirical evaluation; we address the points below by clarifying scope and making targeted revisions.

read point-by-point responses

  1. Referee: [Abstract and Case Studies] Abstract and the five case studies: the central claim that L5 navigates the listed tensions rests entirely on descriptive narrative; no measurements, comparisons to p5.js/Processing, user studies, or outcome data are supplied to show that the decisions actually achieved lower resource use, maintained stability, or preserved accessibility, which is load-bearing for the conclusion.

    Authors: We agree the work is descriptive and narrative-driven. The central claim concerns the necessity of transparently navigating competing values in sustainable tool design, illustrated via the five case studies of L5's development process. No quantitative claims about achieved outcomes are made. We will revise the abstract and the opening of each case study to explicitly state the reflective, qualitative nature of the contribution and the absence of metrics or user studies. revision: partial

  2. Referee: [Introduction / permacomputing framing] Framing section on permacomputing application: the claim that these principles can be brought to the creative-coding community without undermining accessibility for artists and learners is asserted but lacks any concrete test, metric, or falsifiable check (e.g., comparison of onboarding time or resource footprint for novice users), creating a correctness risk for the paper's positioning of L5.

    Authors: The introduction describes design choices intended to balance permacomputing values with usability considerations drawn from the authors' experience; it does not assert or test that accessibility is preserved. We will revise the framing section to remove any implication of untested outcomes and to state clearly that the work is exploratory and reflective rather than validated by empirical checks. revision: partial

Circularity Check

0 steps flagged

No significant circularity

full rationale

The paper is a descriptive design account of L5, a creative coding library, presenting five case studies on trade-offs between sustainability and usability values. It contains no equations, derivations, fitted parameters, predictions, or formal claims that reduce to inputs by construction. No self-citations appear as load-bearing premises, and the central narrative relies on internal reflection rather than external uniqueness theorems or ansatzes from prior work. The derivation chain is therefore self-contained as a position paper without any of the enumerated circularity patterns.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This is a design-description paper; the central claim rests on domain assumptions about the relevance of permacomputing to creative tools and standard software usability principles, with no free parameters, quantitative fits, or new postulated entities beyond the library itself.

pith-pipeline@v0.9.1-grok · 5681 in / 1134 out tokens · 28335 ms · 2026-06-26T23:18:16.471574+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

30 extracted references · 17 canonical work pages

  1. [1]

    Roel Roscam Abbing. 2021. ‘This is a solar-powered website, which means it sometimes goes offline’: a design inquiry into degrowth and ICT. LIMITS Workshop on Computing within Limits. https://doi.org/10.21428/bf6fb269.e78d19f6

    work page doi:10.21428/bf6fb269.e78d19f6 2021

  2. [2]

    Alan Borning, Batya Friedman, and Deric Gruen. 2018. What pushes back from considering materiality in IT? In Proceedings of the 2018 Workshop on Computing within Limits, 1–6. https://doi.org/10.1145/3232617.3232627

    work page doi:10.1145/3232617.3232627 2018

  3. [3]

    André Brandão, Diogo Matos, Miguel Guimarães, Simão Cunha, and João Saraiva. 2026. The Green Side of the Lua. https://doi.org/10.48550/arXiv.2601.16670

    work page doi:10.48550/arxiv.2601.16670 2026

  4. [4]

    Marloes De Valk. 2021. A pluriverse of local worlds: A review of Computing within Limits related terminology and practices. In LIMITS Workshop on Computing within Limits. https://doi.org/10.21428/bf6fb269.1e37d8be

    work page doi:10.21428/bf6fb269.1e37d8be 2021

  5. [5]

    Alexandre Decan, Tom Mens, and Maelick Claes. 2016. On the topology of package dependency networks: a comparison of three programming language ecosystems. In Proceedings of the 10th European Conference on Software Architecture Workshops, 1–4. https://doi.org/10.1145/2993412.3003382

    work page doi:10.1145/2993412.3003382 2016

  6. [6]

    Elina Eriksson and Daniel Pargman. 2023. Exploring Inner Transition: Expanding Computing forSustainability. In Ninth Designing L5 LIMITS ’26, June 23 - 25, 2026 Computing within Limits 2023. https://doi.org/10.21428/bf6fb269.22dea4ad

    work page doi:10.21428/bf6fb269.22dea4ad 2023

  7. [7]

    Luiz Henrique de Figueiredo and Roberto Ierusalimschy. 2009. Lua. In Masterminds of Programming: Conversations with the Creators of Major Programming Languages, Federico Biancuzzi and Shane Warden (eds.). O’Reilly Media, Sebastopol, CA, 161–176

    2009

  8. [8]

    Ashwin Hirschi. 2007. Traveling Light, the Lua Way. IEEE Software 24, 5: 31–38. https://doi.org/10.1109/MS.2007.150

    work page doi:10.1109/ms.2007.150 2007

  9. [9]

    Roberto Ierusalimschy. 2008. Lua Performance Tips. In Lua Programming Gems, Luiz Henrique De Figueiredo, Waldemar Celes and Roberto Ierusalimschy (eds.). Lua.org, 15–28

    2008

  10. [10]

    Roberto Ierusalimschy, Luiz Henrique De Figueiredo, and Waldemar Celes. 2007. The evolution of Lua. In Proceedings of the third ACM SIGPLAN conference on History of programming languages. https://doi.org/10.1145/1238844.1238846

    work page doi:10.1145/1238844.1238846 2007

  11. [11]

    Esther Jang, Matthew Johnson, Edward Burnell, and Kurtis Heimerl. 2017. Unplanned Obsolescence: Hardware and Software After Collapse. In Proceedings of the 2017 Workshop on Computing Within Limits, 93–101. https://doi.org/10.1145/3080556.3080566

    work page doi:10.1145/3080556.3080566 2017

  12. [12]

    Kit Kuksenok and Lee Tusman. 2026. Processing/p5 defined through practice and learning. IEEE Computer, Software Engineering in Generative Art. https://doi.org/10.1109/MC.2026.3697659

    work page doi:10.1109/mc.2026.3697659 2026

  13. [13]

    Aymeric Mansoux, Brendan Howell, Dušan Barok, and Ville- Matias Heikkilä. 2023. Permacomputing Aesthetics: Potential and Limits of Constraints in Computational Art, Design and Culture. In LIMITS Workshop on Computing within Limits. https://doi.org/10.21428/bf6fb269.6690fc2e

    work page doi:10.21428/bf6fb269.6690fc2e 2023

  14. [14]

    Joanna McGrenere and Gale Moore. 2000. Are We All in the Same “Bloat”? Proceedings of Graphics Interface 2000 Montréal: 10 pages, 143.23 KB. https://doi.org/10.20380/GI2000.25

    work page doi:10.20380/gi2000.25 2000

  15. [15]

    Christopher Morse. 2021. Gaming Engines: Unity, Unreal, and Interactive 3D Spaces. Technology|Architecture + Design 5, 2: 246–

    2021

  16. [16]

    https://doi.org/10.1080/24751448.2021.1967068

    work page doi:10.1080/24751448.2021.1967068 2021

  17. [17]

    Michael Murtaugh. 2021. Torn at the seams: vernacular approaches to teaching with computational tools. In Vernaculars Come to Matter, (Re)Orienting Language and Technology, Cristina Cochior, Julie Boschat-Thorez and Manetta Berends (eds.). Everyday Technology Press, Rotterdam

    2021

  18. [18]

    p5.js Contributors. 2019. Our Focus on Access. p5.js. Retrieved April 3, 2026 from https://p5js.org/contribute/access/

    2019

  19. [19]

    Daniel Pargman and Elina Eriksson. 2016. At odds with a worldview: teaching limits at a technical university. Interactions 23, 6: 36–39. https://doi.org/10.1145/3003839

    work page doi:10.1145/3003839 2016

  20. [20]

    Welcome to Processing! Processing

    Processing Foundation. Welcome to Processing! Processing. Retrieved April 3, 2026 from https://processing.org//

    2026

  21. [21]

    Rather, Donald R

    Elizabeth D. Rather, Donald R. Colburn, and Charles H. Moore

  22. [22]

    In History of programming languages---II, Thomas J

    The evolution of Forth. In History of programming languages---II, Thomas J. Bergin and Richard G. Gibson (eds.). ACM, New York, NY, USA, 625–670. https://doi.org/10.1145/234286.1057832

    work page doi:10.1145/234286.1057832

  23. [23]

    Tom Shannon. 2018. Unreal Engine 4 for Design Visualization: Developing Stunning Interactive Visualizations, Animations, and Renderings. Addison Wesley, Boston

    2018

  24. [24]

    Bradley Taunt. 2022. 1MB Club: Consider Disabling HTTPS Auto Redirects. Retrieved April 3, 2026 from https://1mb.club/blog/https- redirects/

    2022

  25. [25]

    Marloes de Valk and Ville-Matias Heikkilä. 2022. Permacomputing. Counter-N 2022. https://doi.org/10.18452/25609

    work page doi:10.18452/25609 2022

  26. [26]

    Niklaus Wirth. 1995. A plea for lean software. Computer 28, 2: 64–

    1995

  27. [27]

    https://doi.org/10.1109/2.348001

    work page doi:10.1109/2.348001

  28. [28]

    Retrieved April 3, 2026 from https://l5lua.org/

    L5: A Processing Library in Lua. Retrieved April 3, 2026 from https://l5lua.org/

    2026

  29. [29]

    Retrieved April 3, 2026 from https://permacomputing.net/

    permacomputing wiki. Retrieved April 3, 2026 from https://permacomputing.net/

    2026

  30. [30]

    Retrieved April 3, 2026 from https://permacomputing.net/principles/

    permacomputing principles. Retrieved April 3, 2026 from https://permacomputing.net/principles/

    2026