Glisp: a design tool whose project file is a Lisp program

The project file is both the program and the drawing

Glisp, an acronym for Graphical LISP, is a prototyping project by Baku Hashimoto that asks what happens when a design tool meets a way of creative coding. The README describes it as looking like the integration of Illustrator and the Processing IDE at a glance, and explains that it adopts the intuitiveness of direct manipulation in a graphical interface together with the abstractness of a programming language.

The mechanism is the Code as Data idea from Lisp, applied to design documents. The project file uses a customised dialect of Lisp, and it is simultaneously the program that generates the output and a tree structure representing an SVG-like list of shapes. The document you edit is the thing that runs.

That has a consequence worth spelling out for anyone evaluating the tool. There is no import step between authoring and rendering, and no separate scene graph to keep in sync with code. The document is evaluated, and the result is both a picture and a list of shapes you can select and manipulate in the viewport.

The tool is MIT licensed, written in TypeScript, and the demo at glisp.app is described as Chrome only, with documentation in English and Japanese.

Homoiconicity, and why the built-in commands use the same syntax

The README makes a large part of the case with a single property: homoiconicity. Because the project file and the program's built-in features are written in identical syntax, a large part of the app's own functionality is expressed the same way a user's own code is.

The stated effect is that artists can hack the app and transform it into a tool specialised for a particular realm of graphics, whether daily graphic design, illustration, generative art, drawing flow charts, or something else entirely. The author names this attitude purpose-agnostic, contrasting it with tools that are strictly optimised for one concrete genre of graphics such as printing or the interface of a smartphone app.

The reasoning is that a tool which does not decide what kind of work it is for can be reshaped by its user. The cost, which the README does not dwell on, is that a user modifying the built-in commands is editing the application, and the application here is a prototype with a version number of 0.1.0 in its package manifest.

The interpreter and the drawing libraries underneath

The project does not start from scratch in either direction. The Lisp interpreter is a modified version of the Make a Lisp project by Kanaka. Boolean operations and some bezier manipulations come from Paper.js, and bezier curve analysis comes from Bezier.js.

That lineage explains a good deal about the codebase. An interpreter built that way keeps the codebase readable, which is exactly what you want in a project where the interpreter is the thing being demonstrated. Paper.js supplies a document model and a path API that a designer tool can lean on rather than reimplementing, and Bezier.js handles the curve maths that a pen tool and a programmatic path both need.

The dependency list in the package manifest matches that story: canvas2svg for the SVG-like shape representation, comlink for the worker-style communication between the main thread and the evaluation environment, chroma-js for colour, delaunator for triangulation and bezier-easing for timing curves. Vue 2 is the interface layer, with the composition API available alongside it.

The roadmap reads as a design document

The feature list in the README is written as a wishlist, with each entry marked by a priority symbol: high priority, personally thought cool, or important with no idea how to do it. That makes it unusually honest about what exists and what does not.

The high-priority items are UI ones: selecting a path or group by clicking in the viewport, transplanting a programmable pen tool, and a layer list view, plus a general goal of letting non-programmers edit a project without seeing any Lisp code. Touch-screen support is listed without a priority marker.

The interpreter work is where the author's own interests show. There is a proposal for an incremental evaluation system to avoid the overhead of recalculating the whole project for each tweak, an incremental Lisp parser, and the ability to refer to another node's value by relative path without defining a symbol, compared to Houdini's ch() expression. A headless REPL environment to render images by command is described as partially supported, and a standalone JavaScript library to render an embedded sketch in a web page is on the list.

Later items cover a video exporter, an After Effects style layer view and curve editor, GLSL filters for raster images, and binding commands to controllers over OSC and MIDI.

Running it: Vue-CLI, a separate REPL bundle and an Electron shell

The project adopts Vue-CLI, and the development commands in the README are the standard set, which means the quick way in is short:

yarn install
yarn serve
yarn build

The repository is more interesting than a single Vue app, though. The package manifest shows a separate REPL entry point, node ./repl/index.js, with its own webpack configuration in webpack.repl.config.js and a watch mode for it, and a script that exports reference material by running the REPL against export-refs.glisp:

yarn repl export-refs.glisp

There is an Electron shell as well, with yarn electron:serve for development and yarn electron:build for a packaged build, and the manifest names background.js as the Electron entry point. Documentation is served with docsify through yarn doc:serve, deployment runs through a task.deploy.js script, and lint runs vue-cli-service lint.

Two loose ends in the tree point at the same split. There is a test.js at the root and a repl/ directory, and an ftp.info.sample.js sitting next to export-refs.glisp, which suggests the reference export has been wired to some distribution step at some point. The manifest is marked private and versioned 0.1.0, so this is not packaged for publication as an application.

How the author positions it against other tools

The README lists the projects the author considers related, and the grouping is informative.

Programming-oriented drawing applications come first, with Para and Dynamic Brush by Jennifer Jacobs and Sketch-n-Sketch. Lisp-based creative coding toolkits follow, with Ronin from Hundred Rabbits, Quil and snek by Anders Hoff. The third group is earlier generative design research and products: AutoShop, Auto-Illustrator, Scriptographer and Paper.js by Jürg Lehni.

Scriptographer and Ronin are the two names that tell you what Glisp is trying to be. Glisp belongs to that lineage, with a Lisp program as the document and a graphical interface on top that the README describes as still unfinished for anyone who does not want to read code.

That middle position is the project's real bet, and the wishlist shows the author knows it: an interface that supports direct manipulation without requiring the user to think in Lisp is listed as high priority and not yet done.

Where the project actually stands

Glisp is a prototype with a public demo, a documentation site and a small community of supporters, and the honest summary of its maturity is in the version number. The package manifest says 0.1.0 and marks the package private, the repository has no GitHub releases, and the last push to it was on 2026-05-11.

For a reader deciding whether to try it, three things are worth checking in order. First, whether the interface works for you without writing Lisp, since that is the explicit open question in the wishlist and the demo is the only place to answer it. Second, how the evaluation behaves as a project grows, because the incremental evaluation system that would fix the recalculation cost is listed as an item the author has no idea how to implement. Third, whether the interpreter fork of Make a Lisp gives you the primitives you need, since the built-in feature set is itself written in that dialect and extending it means learning the fork.

None of that makes the project wrong for its purpose. It is explicitly a prototyping project, it is MIT licensed so the ideas can be taken, and the design decision to make the document the program is worth understanding even if you never open the editor.

Editorial conclusion

Glisp suits an artist or researcher who wants to write graphics as code and keep the drawing and the program in one document, and who is prepared to read a Lisp dialect rather than a menu. It is the wrong choice for a production workflow, since the package manifest is at version 0.1.0, the repository publishes no releases and the last push was on 2026-05-11. It is also the wrong choice if you need the interface to hide the code, because a GUI for non-programmers is still an open item in the project's own wishlist. Verify first that the interpreter fork of Make a Lisp exposes the primitives your sketches need, that the browser demo at glisp.app runs in Chrome, and that re-evaluating a large project stays fast enough for iterative work.

Frequently asked questions

Official sources

1. baku89/glisp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README