(2016-07-18) Huebert When I Sit Down At My Editor I Feel Relaxed

Matt Huebert: When I Sit Down At My Editor, I Feel Relaxed. My environment of work was more often a distraction, rather than help, to the flashes of vision that would enter my mind and wish to exist. The flow state between imagination and concrete representation in the world was constantly interrupted.

A Note on Objectives

A working statement of objective might be:
To create programming environments which focus as much as possible on the essential problems at hand, and can flexibly adapt to the preferences, cognition styles and contexts of diverse people.

An ideal programming environment will continue to be a place of struggle, but more often, struggling with real problems rather than those of our own making or of our tools. Our aim is not to eliminate complexity or uncertainty, but to offer tools and perspectives that encourage us to address them calmly

Main Aspects of the Prototype

We wish to help programmers focus on the task at hand, while flexibly adapting to diverse preferences and cognitive styles; to create an environment which is learnable and intuitive, but retains the power and flexibility of general-purpose programming. We seek techniques and interfaces that need not be abandoned as a project grows in scope and size.

It is the general-purpose nature of the goal that has led to a ‘whole-system’ approach. The prototype is a browser-based editing environment, consisting of:

  • A visual tree vew interface to organize a project, instead of files;
  • A notion of cells as the primary unit of composition, compilation, evaluation, dependency management, and revision control, running as a dataflow graph with history;
  • An editor featuring movement toward flexible visual representations, in the form of ‘visual macros’ and custom formatters.

All of what is shown and most of what is discussed has been implemented in the prototype. Some aspects of the system as described remain speculative.

Instead of Files, A Tree

If a user treats 'programming' files like ‘normal’ files, naming and moving them for intuitive sense-making or organizational purposes, programs will break without warning. To cope effectively, a user must build and hold in mind a detailed model of the file structure expectations of the programming system at hand.

Instead of files, we use a visual tree featuring collapsible, zoomable nodes which can be either plain text, for documentation or note-taking purposes, or cells, formula-value pairs which we'll describe in detail later. We can zoom to any part of the tree, and follow a breadcrumb back to the top. Users can name and organize nodes of the tree however they like.

Interfaces of this type can remain performant and usable even as a tree grows to tens of thousands of nodes.

Cells

From the dataflow model of a spreadsheet we borrow the notion of a cell as a formula-value pair. Presently, the formula (or source code) of a cell is written in ClojureScript, a Lisp dialect that compiles to JavaScript

A user can reference another cell by finding it in the autocomplete drop-down menu.

We compose programs out of cells. Each cell returns a single value, and has no knowledge of the cells which depend on it. Information should not ‘leak’ out of a cell; intercellular communication happens only via dataflow.

The cell is the unit of dependency management

other cells are referenced by unique ID (UUID?). A cell's ID is sufficient to find and fetch it from the internet for local evaluation.

We may depend on cells which are mounted and evaluated in remote environments, whose values are streamed to the local runtime.

Cells catch errors, which flow through to dependent cells so that a programmer can trace an error to its ‘root cell’

Cells are persisted to a database, but could just as easily persist to files. The means of persistence is not the interface for interaction.

Dataflow, with a Twist of Reduce

To modify a cell's value in response to time or an event, we apply reducing functions, which receive a cell's current value as an argument and return the next value. (cf map reduce)

In fact, all cells can be thought of as reducing functions, because we can use the keyword self to refer to a cell's previous value.

Text Editor

The editor built using CodeMirror, by Marijn Haverbeke is a bridge between the cell graph and the tree, using information from both to meaningfully represent code. Efforts are underway to introduce flexible, ad-hoc visual representation of code. The examples below are primitive but indicate possibilities.

Visual Macros

By quoting the visual macro in cell b, we see the underlying code.

A key idea behind visual macros is that one could always see the code behind the view, or disable them if desired. Rather than design a comprehensive ‘visual programming language’, we look for specific places and contexts where visual enhancement can add value, and improve experience in an ad-hoc manner.

Visual macros may be discovered which have general utility. It is my view that useful and practical visual enhancements are more likely to come ‘from the bottom’ than from a language or editor designer. This requires an iterable medium for visual representation of code

Whether we represent numbers as text or something else is a matter of taste, purpose and context. “Each notation highlights some types of information at the expense of obscuring other types; each notation facilitates some operations at the expense of making others harder

I think we've not yet scratched the surface. Alan Blackwell wrote that programming “involves loss of direct manipulation as a result of abstraction over time, entities or situations.

Unfortunately, in most cases this loss has been total. Many editors have literally no facility for adding meaning to the abstract representations of what are, fundamentally, meaning-laden entities. As a thought experiment, imagine what users would think of spreadsheets if it was impossible to format dates, numbers, and currencies. What time of day is 1468417963?

Physical’ S-Expressions

The editor allows parentheses to be dragged with the mouse, with movement restricted to valid positions. In this way the user can have a direct experience of the structure of Lisp code.

Direct Manipulation

We may find it useful to treat some cells more like ‘documents’ than ‘source code’, i.e., the primary interface is through direct manipulation of the view. Below, the circle function returns an HTML view which rewrites the arguments supplied to its invocation in the cell's source code: Instrumentation allows a function to trace its invocation in the cell stack, and apply a function to its arguments (supplied as an ordinary Clojure data structure.)

Docstrings

Popouts

a cell's source code or value to the bottom-right corner of the screen, to remain visible while working on another part of the program.

Conclusion

I would now like to conclude with a short note about why work in this field might matter.

As software affects life more intensely, the payoff for having a say in the matter goes up. The opportunities for solving practical problems with code multiply. The social milieu surrounding ‘code’ and ‘programming’ thickens. We have a large and growing number of reasons why it may be valuable and important for the average person to understand what it means to code. (learning programming)

The message of the medium of code is flexibility. Given time and motivation, we can make a system perform as we like. It can be artistic, logical, poetic, sequential, linguistic, mechanical, musical, humourous—or whatever your mind comes up with tomorrow. That is the message I hope my work can point toward, in whatever small way it can


Edited:    |       |    Search Twitter for discussion