Bret Victor’s talk Inventing on Principle gave me quite a bit to think about. Here’s the talk, if you want to watch it now:

There are lots of great demonstrations and though-provoking ideas in the talk, but it inspired two personal insights that I want to get down here before their luminosity dims.

The first is that it helped me understand why I am not a big fan of the vi editor, despite all of its apparent efficiency gains. I’ve written a bit more about that here.

The second is about another intuition I have about the future of programming. Most programming at the moment involves producing a static description of software (in text files), which is then “run” (possibly after “compilation”).

I suspect that this form of expression isn’t infinitely sustainable, and I’m interested in styles of programming where the developer is dealing with a system that is always running, and where modifications to that live system feel more like gardening or sculpting – software husbandry, if you will – than emitting hard, static declarations of behaviour.

Smalltalk is, as I understand it, a bit like this, because all objects are “live” and modified while the system is running. I’d like to spend more time becoming familiar with systems like Smalltalk so I can better explore this intuition that I have.

The common thread that Bret’s presentation highlighted for me is that a lot of the skill in programming (both in terms of writing the software, and using the editor to write the software in the case of vi) involves humans playing computer, and I’d very interested in ways to move beyond that.

A quote from the talk:

You essentially have to play computer – you have to simulate in your head what each line of code would do on a computer.

And to a large extent the people that we consider to be skilled software engineers are just those people that are really good at playing computer.

That. Exactly that.

Bret Victor’s talk Inventing on Principle gave me quite a bit to think about. Here’s the talk, if you want to watch it now:

There are lots of great demonstrations and though-provoking ideas in the talk, but it inspired two personal insights that I want to get down here before their luminosity dims.

The first is that it helped me understand why I am not a big fan of the vi editor, despite all of its apparent efficiency gains. I’ve written a bit more about that here.

The second is about another intuition I have about the future of programming. Most programming at the moment involves producing a static description of software (in text files), which is then “run” (possibly after “compilation”).

I suspect that this form of expression isn’t infinitely sustainable, and I’m interested in styles of programming where the developer is dealing with a system that is always running, and where modifications to that live system feel more like gardening or sculpting – software husbandry, if you will – than emitting hard, static declarations of behaviour.

Smalltalk is, as I understand it, a bit like this, because all objects are “live” and modified while the system is running. I’d like to spend more time becoming familiar with systems like Smalltalk so I can better explore this intuition that I have.

The common thread that Bret’s presentation highlighted for me is that a lot of the skill in programming (both in terms of writing the software, and using the editor to write the software in the case of vi) involves humans playing computer, and I’d very interested in ways to move beyond that.

A quote from the talk:

You essentially have to play computer – you have to simulate in your head what each line of code would do on a computer.

And to a large extent the people that we consider to be skilled software engineers are just those people that are really good at playing computer.

That. Exactly that.