It has been twenty-two years since Kenny first shared Cells on comp.lang.lisp, twenty-seven years since CL’s Garnet[1] shipped with a reactive KR module, and thirty-eight years since some guy named Steele based his PhD thesis[2] on an elaboration of work he and Sussman had started on constraint programming. Steele credits Sutherland[3] with the first work on constraints, and that goes back fifty-five years. Lisp has always led the way on reactive programming and the world has almost caught up.

[1] http://repository.cmu.edu/cgi/viewcontent.cgi?article=1761&context=isr

[2] ftp:// http://publications.ai.mit.edu/ai-publications/pdf/AITR-595.pdf

[3] https://youtu.be/USyoT_Ha_bA

This will be part experience report, part survey of the reactive field, part guide to evaluating reactive libraries, but most of all an opportunity to join with Kenny in guessing at what elemental essence of information has been tapped by the simple idea of a software spreadsheet cell such that it solved trivially (our experience, in order):

Ordering of dynamic interdependent GUI geometry;

The ostensibly ineluctable problem of managing interdependent state as applications grow, the reason Fred Brooks said “No Silver Bullet” was to be had;

The Grail of OO reuse;

Dynamic object persistence; and

Callback Hell.

We will begin by making sure the audience has a hands-on feel for reactive programming with a couple of light live-coding exercises with MatrixCLJS, a straight port to Clojure and ClojureScript of Common Lisp Cells.

Rants comparing CL and Clojure and CLJS and Javascript (now enjoying a separate port of Cells) can be expected.

The live-coding will exercise Matrix in two contexts: first, a dynamic web page built with Kenny’s new CLJS Tag framework; second, not one but two solutions to asynchronous Callback Hell. Along the way we will touch on some modest but handy extensions made to Cells during the port, such as standalone Cells (inspired by CLJS Javelin [ https://github.com/hoplon/javelin ]) and per-Cell observers.

If time permits, we will re-invent Cells over the keyboard following the same incremental evolutionary steps originally taken.

With the code in hand, Kenny will provide a definition of reactive programming and then share the checklist he uses for evaluating reactive libraries. Relevant here will be an understanding of so-called “reactive glitches” (in which a system’s state can momentarily lose consistency) and Kenny’s rigorous definition of data integrity -- first enunciated in The Cells Manifesto[4] -- where “integrity” means “no glitches”.

[4] http://smuglispweeny.blogspot.com/2008/02/cells-manifesto.html

With a solid understanding of reactive technology and Kenny’s checklist in hand, we will look at a sampling of other reactive efforts:

Steele’s “bridge too far” Constraint Programming Language;

Common Lisp Garnet’s KR;

Philip Eby’s Python Cells clone, Trellis;

Adobe’s C++ Adam;

RxJS hand-wired stream dataflow;

Lifting FRP such as Scheme FrTime, and CLJS Javelin;

Michael Weststrate’s Javascript MobX (supplying the reactivity ReactJS left out).

We will close by reviewing our list of ostensibly hard problems and breaking down exactly how Cells trivially solved each, then contemplate together why exactly simple spreadsheet-like dataflow works so well in so many unanticipated ways.