Unsettled Perceptions

Unsettled Perceptions, a project in three voices.

Miek Zwamborn, Richard van Diessen en Rutger Emmelkamp explore the relation between poetry, computer code and nature. Together they build a digital landscape which reacts on the extreme irregular conditions in Tireragan: weather, tides, seasons, moon calendar, day and night. The application will become a parallel equivalent of the area in which they work. In this ‘realistic wordscape the visitor can explore sketches and poems. Sometimes the language will be accompanied by images or sound.

Miek Zwamborn is an author, translator and artist. Her practice often delves into archival collections, drawing on the suggestive possibility of historical materials, letters, texts, objects and artefacts in order to create semi-factual narratives.

Richard van Diessen is a free-lance programmer specialized in server-side application development in Ruby, Ruby on Rails and Elixer. He studied Art and Cognitive A.I. For this project he will write in lisp*.

Rutger Emmelkamp is engaged with the visual translation of this project. He also functions as the mediator between the technological and the poetic view and language.

* for more on lisp please scroll down.


On this blog we will sketch the various experimentations that will make up this project. In a later phase these experiments will be linked together in a bigger system on a separate server.

In unknown territory, climbing the highest point helps to orient oneself. Based on the contour lines of the environment we decided upon 24 elevated viewpoints. Adding these up will give a rather complete view of this land. Each of the squares below represent one elevated landmark and links to the exact google maps location.

For each of the elevated viewpoints we will create an animated online panorama.


sea / land / coast / altitude / sightlines / granite / basalt / erosion / intrusions


celtic rainforest / acid grassland / peat / bog / heather / bracken / lichen / moss / golden eagle / seals / mink whale / plastics


wind / precipitation / temperature / humidity / uv / atmospheric pressure
(an early experimentation: air pressure will define line spacing)



Cycles / Calendar
tides (actual) / sun (position) / moon (position) / seasons (gradual)

Color fluctuations
Seasons and weather conditions define color fluctuations in the landscape. Seasons change slowly as does the vegetation. The light however is highly variable which gives the landscape a different character from minute to minute. We will capture the colors throughout the year and will translate these to color palettes for further investigation.


By analyzing grammar we seek for patterns which may be comparable with patterns in nature.


Programming languages, just like many other tools and methodologies the world of software, are highly susceptible to fashion.
At this moment Lisp cannot be called a “fashionable” language, at least not the variant that we are going to use (Common Lisp).

Leaving out technical details, here are some contextual reasons why this language is interesting for our project.

Historically, lisp was the language-of-choice for A.I and Artificial Life research. Although it is the second oldest [0] language still in use, many other programming languages have adopted at some point in time concepts that already existed in lisp, and most of the younger languages ​​(deveoped in the last 15 years) are strongly influenced by ideas originating from lisp.
You could call lisp the Nestor of dynamic, high-level [1] languages. Almost all concepts that can be introduced as new in a language existed in lisp and certain abstractions can simply not be expressed in other language than lisp. ​​[2] [3].

It is a homoiconic language, which means that the code-text itself can be used as data and can be modified in runtime. [4] This makes it possible to write code to write code and develop a so-called Domain Specific Language, a language specific for the project at hand. Our project seeks a connection between language (poetry) and code. Lisp allows the code to be a a reflection of this.

In more common languages ​​(such as Java) programming is a top-down matter (think pre-architecture, structure, code-organization). In lisp however this is an almost inevitable bottom up process. Throughout the process, you can shape the language to your needs and allow structure to manifest itself.

This project will be an ongoing search for possibilities, therefore rapid prototyping is of the essence.
This is made possible by the dynamic and functional [5] character of the language, thereby shortening the development-test-feedback cycle.

[0] Originally conceived in 1958.
[1] high-level <-> low-level: in short, far from or close to the machine.
[2] Technically, any Turing-complete language can do what any other Turing-complete language can do. We’re talking here about expressiveness: The ability to communicate an idea.
[3] An exception to this is the language Haskell.
[4] Non-homoiconic languages ​​make a clear distinction between the operations of a program and the data on which these operations are performed.
[5] “functional” is one of the (but preferred) programming paradigms supported by lisp. (Examples of other paradigms are: object-oriented, imperative, logic programming)