Mary Rose Cook's notebook

The public parts of my notebook.

In Search of Tomorrow, Chris Granger

A killer summary of the many prototypes that Kodowa built in search of the future of programming.

The company did a study that found that LightTable produced a 2X programmer productivity increase over Visual Studio. But LT didn’t gain wide adoption. Chris attributed this to 2X not being enough. [It seems to me that things like staying-power, availability of supporting tools, stability will always require a tremendous force to unseat.]
Instarepl was the salient feature. This was a panel adjacent to your code that replaced variables with their values and showed function return values.

Later Chris identifies the three main things that are hard about programming. He said that LightTable only really fixed the first: programming is unobservable.

The goal of LightTable had been to make programming better and also accessible. But they hadn’t really stopped to understand the question: “How do we make programming better?” This question has two parts.
Part 1: programming. What is programming?
Part 2: better. What is hard about programming? It is unobservable. It is indirect, meaning that if you are programming a drone, you don’t manipulate the drone, you manipulate data related to the drone. And it has incidental complexity, meaning that you spend lots of time solving problems that aren’t your actual problem (eg fighting with concurrency).
Chris then gave a killer example of the hard parts of a popular programming environment: JavaScript, HTML and the DOM. He described a task where a programmer has to create a button on a webpage that displays the number of times it’s been clicked.

The six lines of JS code required

Asynchrony - incidental complexity

Closures - incidental complexity

The DOM - indirection

Identity - indirection, incidental complexity

Mutable assignment - incidental complexity

Scope - incidental complexity

They thought and realised that a programming is not a tool for building apps or websites. It’s a tool to think with.

It was symbolic, used immutable data structures and functions.
Many clever people tried and failed to use it. They found many things hard, but the main one was scope. They kept on asking if they could use values that were high in the call stack in a lower down in the call stack, or vice versa. Upon being told that they would have to thread the value up/down through the function calls, they said, “I can see it, why can’t I use it?” Kodowa tried mitigating the confusion with colours and arrows, but it didn’t help.
They thought about what happens if you take scope away. This meant no functions. It meant no nested data structures because nesting is a form of scope. And it meant no special ordering (of operations, I assume).
Excel: a successful example of programming without scope. Excel has problems. First, not all problems can be specified as a grid of numbers. Second, it’s not fast enough for really big problems.
Relational databases: another successful example of programming without scope. These are not as accessible as Excel. But they have been proven to be usable for very large problems.

A query language based on Datalog. Datalog is a smaller, faster Prolog.
Main form: when you see x do y
No data structures.
[How do you bundle state?]
How is time modelled?
Kodowa wrote an editor for their programs in 600 lines of Bloom.
Ultimately this approach wasn’t feasible. To understand any part of the program, you have to understand all of it.

Send SMSes when a button is clicked.
Make button clicks send events to a table.
Use a click and drag to join events table to SMS table. [Is the SMS now automatically sent?]
A downside is that you lose the source of the table data.
Another downside is that the user has to think about keys a lot because of all the table joins.

The aim of this prototype was to prove their relational database model and worry about a UI for writing programs later.
The code doesn’t describe changes. It just runs a query and formats the result.
[As far as I can tell, each table on the right is associated with one of the blocks of code on the left. Data is queried from tables. It is then formatted using a mini language that builds HTML.]
The data and UI displayer was written in 200 lines of the SQL-like query language and HTML building language.
[Everything is tables, and as far as I can tell, the joins happen in the code.]

Had a more sophisticated interface for building a UI.
Create a button. Create a table of clicks. Add a column to the table that used an Excel-style formula to calculate the table count. Drag the count to the button and tell it to display the data as text.
Still had the problem of losing the context of where the table data came from.

No code, UI builder worked well, but queries were awkward and the building experience was arduous. [Would have liked more details on this.]

They tried writing a visual query builder. This let them define queries as graphs and mimicked the way they described queries to each other.
The queries ended up feeling siloed from each other.
The queries focused too much on the question and not enough on the answer.

At this point, they’d written thirty prototypes. They thought about what was blocking them from coming up with something successful. They realised that their implicit assumption was that they were building a programming tool. But, really, they were trying to build a tool to think with.
Programming: asking questions and formatting the answers.

The user writes wiki-style text documents in a text area. These documents contain tags that specify data and relationships.

The user can query the documents by writing text into a text input field.

The user can turn a query into a card that describes some new piece of information.

This card is shown in relevant contexts.

#notebook #medianotes #build-software-faster