The Mother of All Demos : From Engelbart to the Present — Prepared Remarks

TK

I want to tell a story about the confluence of three things:

On December 9th, 1968, an overcast and breezy day in San Francisco, Doug Engelbart led a team of Stanford researchers and programmers in a live demonstration of the oN-Line System or NLS.

It was a fresh and startling view on the power and place of computers in society. In a 90 minute demostration that included some participants at remote locations joining in realtime via live television feeds along with a small army of support staff behind the stage, Engelbart showed the packed house of 2000+ attendees a computing future that, for the 1960s, seemed plucked right out of a sci-fi movie. It was an experience more advanced and compelling then what was shown on a popular futuristic television series that debuted that same year: Star Trek.

Seated in a custom-built Herman-Miller chair, in front of a keyboard of Engelbart’s design — one that relied on another of his inventions, the "mouse" and a five-key "paddle" — Engelbart displayed startling features, one after another, as if they were commonplace and available to anyone from their home.

In a quiet and reassuring voice characterized by one listener as "the voice of mission control", Engelbart introduced the room to first-ever demostrations of :

All this at a time when computers where the size of travel traliers without interactive screens at all and used only to do massive computations such as plotting missle trajectories.

Engelbart was showing the world his vision of what computing could be — what he thought it should be. And he wanted people to know that his vision of an interactive computing experience was not something from the future. It was, he told the group, what computing could be like today. He wanted us to re-imagine what computers were capable of and what they could do to help us improve our lives, uplift our communities, and transform ourselves.

Engelbart was asking a lot of the people in the room. Only one decade earlier, the most powerful computer built in the United States was called the Universal Automatic Computer — also known as UNIVAC. Commissioned by the US government in the early fifties for Census work, UNIVAC represented one of the first computers created for the business community.

A key element of the UNIVAC design was that it was possible to actually program the machine — it was not a completely hard-wired system. It could read input from magnetic tape and even had buffered memory. But the UNIVAC had no display screen — it relied on typewriters to return the results of the mathematical programs fed into the machine.

In the 1950s, computers were understood as advanced mathematical engines — as room-sized calculators. The took weeks to program, days to configure, and hours to run — for each problem you wished to solve. And all this happened in carefully controlled conditions worthy of the riskiest surgical procedures of the day.

So, when Engelbart sat on stage in his custom-built office chair at a simple keyboard w/ paddles and buttons displaying real-time interactive displays on a screen 30 foot (9 meters) tall, the audience was astounded.

The world Engelbart was demonstrating was one where humans where no longer destined to spend weeks toiling away to nurse a petulant, cumbersome, and finicky computer only to discover one of the relays was set incorrectly resulting in redoing days of work before the machine could properly compute the updated actuarial tables for a large insurance company. Which is what UNIVACs were used for, by the way.

Instead Engelbart was illustrating a world where computers enable humans to spend time on more important problems, while machines handled the mundane and repetative steps of collating, sorting, computing, and storing important data. Engelbart’s computer was meant to improve everyone’s effectivness by augmenting their intellect.

Computers would help us get smarter.

But, Engelbart said, this was only true when the future of computing was interactive.

And only as long as the interaction was powered by the goal of helping humans create better solutions. and to do that faster. Which can lead to tackling more complex problems.

All based on the notion of making better use of human capabilities.

And this is what Engelbart called Bootstrapping — the process of using computers to get smarter and to solve harder problems and, in the process, build better computers to help us get smarter and solve harder problems, and so forth. A constant "leveling-up" experience.

And this is sounds very much like the promise of APIs, right? that we’ll be able to build better solutions, and build them faster, and that — in turn — can lead to using APIs to solve more complex problems, and so on and so on.

So, after about ten years of API culture, how are we doing on that score? Are APIs making us smarter? are they helping us solve harder problems? What does a typical API design-build-deploy-maintain experience look like today?

And for that I’ll turn the machine over to "Z".

TK

So, at this stage of the game, we can see that APIs, while promising, are still dependent on humans to keep them healthy. Humans need to translate written documentation into machine-readable code. And, whenever the rules of the API (URLs, protocol methods, query paramters, bodies) change, they API simply breaks. It no longer operates as expected — what we call a bug is encountered. So it takes humans, again to fix all this. To reread the documentation, update thew translation, and finally to re-deploy the machine code that works. Of course, as you can see in this example, since the weather provider changed it’s rules all the weather consumers are broken and all the weather consumers must be updated. The pain of breakage is, you see, evenly distributed.

The painful process of reading the spec, translate it into code, and getting it all working is something we’ve been dealing with since before Doug Engelbart did his demo in 1968. And someone who lived these painful details from the every beginning is Admiral Grace Hopper. And she is the subject of the next part of our story.

Grace Hopper was a gifted mathematician that helped build and operate one of the first working computers: the ENIAC that helped computer missle trajetories for World War II.

After the was was over, the ENIAC team, known as the ENIAC Six, were invited to join a new commercial venture Eckert-Mauchly Computing Corportation or EMCC. Hopper was a integral part of the newe enterprise where she worked tirelessly to standardize the way computers were programmed.

It was at EMCC that the UNIVAC was born. In the 1950s computers were all "hard-wired." You programmed them by bridging connections with wires. If that was not complicated enough, the early computer circuits were powered by vacuum tubes. If just one of the 18,000 tubes on the UNIVAC blew out, the whole system wouldn’t work.

It was up to the operators (or "computers" as they were called) to identify not only when the wiring was incorrect but also where ther failed tubes were and to replace them. Add to this the fact that there were no manuals, no programming language, and no maps explaining how this roomful ofg wires and tubes was contructed and you get some idea of the task of programming the UNIVAC.

Even into the 1960s the work of hard-wiring programs was common. So much so, that what came to be known as "plug boards" were an essential part of early IBM mainframes. Hopper recogized that this physical architecture was proving non-scalable. It took too many people too long to translate specifications into hardware and to actually "wire" the hardware up, validate the work and ship the results to the customer. Something had to be done.

What was needed, Hopper concluded was to introduce what she called "Automated Programming". Basically, she needed the machines to "program themselves." This was, Hopper was asured by the people building UNIVAC and other early compueters — impossible. And, that was all Hopper needed as motiviation. Eventually she convinced the people at EMCC to put together an "Automated Progamming" team and put here in charge of it.

+ What Hopper and her team did was create some of the first compilers for computer code. Compilers are programs that take as input a higher-level specification for the program and then translate that higher-level specification into machine-readable code.

Within the first year, her team had created thier first compiler - the "A-0". Eventually, they created the MATH-MATIC language which was followed by FLOW-MATIC in the late 1950s. Both these languages became the seeds for the world’s first universal programming language — one that would work on any mainframe computer, no matter who built it. And that language was published in 1958 and was called "Common Business-Oriented Lanuage" or COBOL.

COBOL changed the face of computing. Now, people no longer needed to hard-wire their programs. Instead, they could describe the work in general terms that any hardward installation could properly interpret and execute consistently. At the same time, programmers could focus more directly on the problem at hand and less on the hardward details, connections, and circuitry.

The represented a huge leap forward for programming. Humans no longer needed to "attend to" the mainframe, constantly repairing glitches, fixing bug as they were introduced, and generally acting as servants to the machine. Humans were finally "out of the loop" where wiring was concerned.

But now programmers had to deal with the next-level problem: software changes. In the 60s and 70s software was hard enough to maintain. It still took years to create and months to install computers but, at least, once that was done you could count on the machines to run for decades w/o introducing changes.

Anyone who works with APIs knows the pain of software changes. As we’ve already seen, Hopper’s "hard-wiring" problems for early mainframes are quite similar to the problems we have today trying to build and maintain API-centric solutions. Except. we’re not dealing with the thousands of connections of a single mainframe in the API space. Instead, we’re dealing with hundeds, possibly thousands of "endpoints" and tens, if not hundreds of client apps — millions if you consider phone apps — all subject to failure when just one part of the collection changes.

Our headlong rush into distributed computing is causing us the same kinds of problems and pains that Hopper faced over fifty years ago. And the solution she hit upon — "automatic programming" is something that could help us today, too. We need API providers and consumers to "speak" the same language — one that works for every installation for every solution, and for every API. A language that will alloew clients and servers to keep communicating even when just one of the members of the collection changes.

And that’s the challenge I put to "Z". How are we doing on that? Is it possible to solve this problem of changing APIs in a highly-connected and interdepentdent system?

TK

Doug Engelbart’s 1968 demo showed us a computing future that positioned machines as assistants to humans. For Engelbart, humans would be better off — would be actually smarter because of computing.

One of the reasons Engelbart was so adamant about his future of computing was because of the work Hopper and others had done a decade earlier. Hopper, ever the pragmatist, ever the teacher, wanted a world where computing was accessible to humans and was universal to machines. She helped create COBOL to accomplish that. She wanted to free humans from the drudgery of hard-wiring and move computing from the world of science and math into the world of business and commerce.

To put this in perspective, the IBM System/360, considered a milestone of programming excellence had just shipped three years before Engelbart’s demo. And it was still not dewigned as an interactive experience. In fact, many people at Engelbart’s demo were "skeptical" of his presentation. They tought it was "interesting" but not "practical".

(2) That phrase might sound familiar. Twenty years into the future another ground-breaking idea was described as "vague but exciting…" — that was the way leadership at CERN research labs assessed Tim Berners-Lee’s proposal for something new — the World Wide Web.

But I’m jumping ahead a bit…

What Engelbart’s audience did not know was that his demo relied on a very new technology called the ARPANET — the Advanced Research Projects Agency Network to handle the remote feeds and inter-networking he was showing off on stage.

The implementation for the ARPANET was handled by a company call Bolt, Beranek, and Newman (or BBN). The earliest technical thinking of what a world-wide network of computers would be like was documented by a scientist as BBN named JCR Licklider.

Among other things he pondered how computing systems would "learn about each other" and "reach a mutual understanding".

Licklider summed up his challenge to the committee tasked w/ designing what was then called the Intergalactice Computer Network (or IGCN) with this amazing phrase:

"[T]he problem is essentially the one discussed by science fiction writers: "How do you get communications started among totally uncorrelated sapient beings?" In other words, how can we get computers to "talk to each other"?

Essentially, this is about empowering computers to "solve the next set of problems." Hopper established "automated programming" to get rid of hard-wired solutions. Engelbart wanted to get rid of purpose-built computers that could only solve a single predetermined problem. Now Licklider wanted to make it possible for computer to "find" each other and "talk" to each other without the need for hard-wiring the connections directly. the Intergalactic Network would handle that.

Curiously, right about the time Engelbart was putting his "Mother of All Demos" together, there were people back in my home state of Kentucky in the U.S. working on a problem that would directly affect the ARAPNET and set a pattern for both the Internet for generations to come. For that we need to head underground to the vast Mammoth Cave system in western Kentucky.

In 1972, just a few years after Engelbart’s demo, Will Cowther, who was workiung for BBN at the time, posted something different on the still-new ARAPNET. It was an interactive adventure game — one of the first. It’s full name was the Colossal Cave Adventure — also known by it’s command file name - "ADVENT".

The details of the game were based on the real-life caverns in the Mammoth Caves National Park in Western Kentucky.

Crowther and his then-wife Patricia were experienced cavers and Patricia had been one of the first to find a key passage in the cagve system that linked Mammoth the the Flint Ridge caves into a single massive network. Much as BBN was creating it’s own virtual network in cyberspace.

Cowther’s ADVENT is now seen as video gaming’s most influential title. He set the mold for others to follow.

And a key aspect of what Cowther introduced is the notion of traversing a virtual space with converstational commands. He had taken Hopper’s idea one step further. Now, people with no programming experiene could,

as Will Cother said: "to make an obstinate system perform in a manner they wanted it to."

Not long after Engelbart’s demo, his oNLine-System became one of the IMP (Interface Message Processor) machines on the ARPANET. It was now part of the very Internet that Engelbart had foreseen.

And, like Hopper before him, Will Cowther introduced a higher-order converstational interactive language that showed computers could be a vital and integral part of eeryday life. These two creative thinkers — Hopper in the 50s and Cowther in the 70s — were both trying to do the same thing that Engelbart wanted to do — to rescue computing from a closed world of "priestly elites" and deliver it to the entire world. All, Engelbart would say to help humans create better solutions, do it fast, so that they could solve more complext problems and, thereby, augument human intellect.

Especially this last step in the journey, casting computing as an adventure where you make choices and act on your decisionsm, is especially important to the API space. Today, while we are able to understand Hopper’s vision of a higher-level language for APIs, and Licklider’s notion of "getting machines to talk to each other" we still haven’t figured out how to enable API clients and servers to go on their own "adventure".

Today all our work is tied up in getting humans to discover which servers we need to connect with, learn the language of that provider and then enlist several of them to solve our problem. But what happens when one of those servers goes missing? then what?

Can we easily train API clients to go on their own adventure? to solve their own problems of finding and using services without the aid of humans to work out those details ahead of time?

Again, maybe my friend "Z" has something to show us here.

TK

TK