(2021-07-21) Martin Copilot And Conversational Programming

Jess Martin: Copilot and Conversational Programming. A month ago, I got a demo of GitHub's Copilot and I've been pondering the implications. Here's what I've realized: Copilot will change what it means to be a programmer.

we should think of Copilot as a shift to a conversational model of programming.

About a year ago, I played with an early demo of a GPT-3-powered chatbot "teacher" that could impersonate any historical figure.... The interesting thing about this experience is how much it actually felt like talking with another human... And even more interesting, a few months later I found myself wishing for an AI that I could converse with throughout the day.

I believe programming with Copilot and other AI assistants is going to be more of like that dialogue I had with Plato last year: a conversation between a programmer and the computer. It will change how we work. (cf pair programming, cyborg)

*In 1967 Marvin Minsky was arguing with his colleagues about how we should think about writing programs. He wrote:

The programmer does not even have to be exact in his own ideas‑he may have a range of acceptable computer answers in mind*

Note the action verbs: ask, recommend, advise. Minsky understood, even in 1967, the possibility of a 2-way conversation between programmer and computer, where the program is written in collaboration

Instead of a sequence of commands, Minsky argues, writing a program could be more like offering "advice" to the computer, guiding to a solution that is "close enough" to what the programmer intended:

One of the most upvoted comments on the Hacker News post agreed: "It's really like pair programming, even though I'm coding alone."

Copilot's initial implementation is integrated directly into VS Code, a traditional IDE (integrated development environment).

By integrating Copilot into an existing workflow, programmers can taste the utility without changing their workflow. But what might be possible with a different workflow?

Under the hood, Copilot is a program synthesizer that works by combining the program's context (the existing code, right now limited to the current file) with "developer intent." Alex Polozov gives an excellent overview in this thread.

One important question is "how should we capture developer intent in order to synthesize a program?"

Programming as a process of conversation where intent and context are synthesized into programs implies a different set of constraints

What will those new tools look like? We have some clues.

Principle #1: Program in plain english

Software engineering already has standard "plain English" representations of a body of code: user stories, commit comments, bulleted lists of requirements, etc.

Principle #2: Create by Reacting

In Bret Victor's talk Inventing on Principle, he talks about his principle for creators: Here's something I've come to believe: Creators need an immediate connection to what they're creating

He expands on this idea in Learnable Programming and spells out a principle he calls "Creating by Reacting." (REPL)

A visual representation of the result of running the code might be a more natural means to communicate Copilot's suggestions Tests?

Principle #3: One rung up the ladder of abstraction

Program synthesis could be used not only to generate lines of code, but entire sets of files representing functionality at a slightly-higher level of abstraction.

Promising Examples

Microsoft Power Apps Ideas

Microsoft has already started down this road by integrating GPT-3 in Power Apps. They added a sidebar inside their Power Apps IDE with a plain text box.

Generating User Interfaces

generates the JSX code for you.

Chris Granger's Experimental Interface

Chris Granger of LightTable and EVE has been experimenting with an interface for programming using natural language

Notably, they are not using machine learning with their approach, but rather writing a new programming language that uses plain English to write programs.