The Patrick and John Collison of Stripe equivalent 20 years from now isn't going to have a whole lot to work with.

They're probably not going to see it that way. They're going to see it as, progress has stalled because all the low-hanging fruit has been taken.

But that's not how it works. There's an infinite amount of fruit in computing. You just need the right kind of research environment to cultivate it. And the right kind of research environment that has cultivated an enormous amount of fruit is what Engelbart called a bootstrapping research environment.

Engelbart who invented working with text on the screen, and mice, and hypertext, and video conferencing, and all that---the agenda of his research lab was not actually to invent any of that stuff. The purpose of the research lab was to find ways for his own research lab to be more effective at inventing stuff.

Bootstrapping is a process where you're not trying to make any particular product or technology to put into the world. You're actually trying to create your own little world. You're trying to create an environment around yourself where you're using tools and processes that are qualitatively different from those outside. Chuck Thacker at Xerox PARC who invented the Xerox Alto put it as: "We were spending a lot of money to simulate the future."

So you can think of it as, the laboratory itself is the experiment. The goal is to create a social environment in which people are living in the future. And that serves as a prototype for how all people may someday be able to do that.

Describing a memory of people making games in Dynamicland There's a bunch of people sitting around this table, and they're all making their little objects. But then they found it was more fun to make objects that messed with other people's objects. And then people reprogrammed those other people's objects, and it became this kind of communally-authored stew of software, where nobody even remembered who made what, because everybody made everything.

Alan Kay, who was one of the principals at Xerox PARC and was responsible for Smalltalk, he wanted to create a new form of literacy in which all people could model and simulate the complex systems of the world. "Understand systems are too complicated to think about in classical ways." The programming languages and operating systems, again, were kind of a byproduct of what was ultimately a completely educational goal.

Here's an illustration. What you see here on the left is the first instance of the pop-up menu. This is in Smalltalk in the early 70s. What you see on the right is the first commercialization of the menu.

These two objects have completely different purposes. These two objects have nothing to do with each other. But they look alike. And because we've grown up with descendants of that thing on the right, we can't actually see the thing on the left for what it actually is.

To understand the thing on the left, you have to understand that Alan Kay was trying to create a medium in which all people would be literate in modeling and simulating the complex systems of the world. And he thought a good way of organizing those models might be as these computational objects that are sending messages to each other. So that's where "object-oriented" came from.

And so, how do you send a message to an object? Well, one way is to write it out. You can give the name of the object and give the message. And that was the Smalltalk programming language. And that's a powerful context because you can send many messages, you can abstract over them, you can define your own messages.

But Alan Kay was trying to create a new form of literacy, which meant that it had to extend down to the world of young children. Young children had to grow up immersed in this computational medium in the same way that children today grow up immersed in a world of written text. And young children aren't particularly fluent in abstract language. But they are good at using their hands. Well, is there a way to send a message to an object using your hands? Well, maybe. You use this mouse thing to click on the object, and the object then reveals its vocabulary to you. "Here are the messages that I know how to deal with." And these are the exact same messages you can then use in the programming language.

They're the same vocabulary, whether you choose from the menu or whether you write it out. And so when a child clicks on that menu on the left, they're doing two things. One is that they're actually invoking that action. But the second thing is that they're learning this vocabulary. They're learning how to communicate with this object, and they can then use that vocabulary later, when they're ready, in the programming context, to make things of their own, to go beyond what's on the menu.

So that thing on the left is educational scaffolding. The thing on the left is designed to teach children to program. The thing on the right is access to functionality. You click on the thing on the right, it runs an assembly language subroutine written by a priesthood of programmers who have decided what you can and cannot do. And if you want to do something that's not on the menu, you buy another computer.

So that thing on the left is designed to expand your world, expand your possibilities. The thing on the right constricts your possibilities. The thing on the left is designed to teach you to become self-sufficient, to go beyond the menu. The thing on the right teaches you to be dependent on a corporation for all your needs. And that ideology on the right has become so ubiquitous and so widespread that we do live in a world where, if you want to do anything on a computer, you use an app to do it. And the idea on the left, this amazing idea that, the purpose of a user interface is to teach you to go beyond the interface, that idea has been buried.

In Realtalk you make things. You don't download apps. You make things out of stuff that other people have left lying around. And there's intended to be this very gentle slope from, you start out playing with things that are lying around. But then you can easily just make little tweaks. So you change a color from green to red. Or you put your name in there. Or you just grab two things other people made and put them together.

Then it's this gradual progression from tweaking and remixing, to taking on more substantial projects. And that extends all the way down to the system itself, which is just as visible and tangible as everything else. [...] The community just comes up and puts things on this whiteboard.

There's no distinction between OS and user. It's just basically the stuff up here has a wider scope than anything else. But anybody can go up and grab the compiler and change the compiler. And everybody is now using your new compiler.

A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus.

It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.

I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase the right thing. To such a designer it is important to get all of the following characteristics right:

• Simplicity --- the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

• Correctness --- the design must be correct in all observable aspects. Incorrectness is simply not allowed.

• Consistency --- the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.

• Completeness --- the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the MIT approach. Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.

The worse-is-better philosophy is only slightly different:

• Simplicity --- the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

• Correctness --- the design must be correct in all observable aspects. It is slightly better to be simple than correct.

• Consistency --- the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.

• Completeness --- the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the New Jersey approach. I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.