By the way, Alan Kay used to have some wonderful online lists of recommended readings, and I haven’t been able to find them lately.  Anyone know whether they’re still posted?

Although I am pleased about the positive impact that SOAP has had, I am also frustrated about how it turned out.  I always hoped we could build a stack that would be portable (we mostly achieved that), and that would scale comfortably from use in the smallest and simplest scriptable Web clients, to reasonably sophisticated enterprise applications.   The hope was for a system that could be used for highly secure, asynchronous, streamed communication between enterprise applications, but that could also be accessed from a single line of Javascript or PERL script to make simple queries or updates to those same applications, and that would integrate smoothly with the Web and with REST.

Unfortunately, SOAP was ultimately positioned at the base of a stack that is far too complex to be appealing to the sorts of communities that now, for good reason, gravitate toward JSON-over-REST.  Whether XML could ever have been a good base for such simple applications is an interesting question, but a serious effort was never really made.  WSDL, WSA, and WS-Security were from the start complex, heavyweight technologies that fit best into systems built using sophisticated tooling.

SOAP and the associated WS-* standards are indeed widely used today in conjunction with systems like Websphere and .Net, and I suppose that’s a good thing as far as it goes.   Conversely, REST is good for many things, but it doesn’t scale to high-end application-to-application communication.  I think we missed a chance to build something far simpler than WS-*, something that would have scaled from very simple to quite robust, and that would have achieved better consistency and integration for more users and more applications.

Nonetheless, SOAP was at least an important step on the way to building simple, data-driven Web applications, and perhaps it’s had some more success than that.  Either way, it’s been 10 years.

If you want to get a sense of just how small and beautifully done Unix was in the early days, take a look at the Level 6 Source code (PDF) and accompanying commentary from John Lions.  In the late 1970′s, Lions’ notes and that source were what many of us used to learn the kernel.  Yes, the entire kernel really did come in at under 9000 lines of source, and it included such enduring achievements as the open/close/read/write abstraction for files and devices, fork/exec, pipes, block and raw devices registered in the filesystem, etc.  Perhaps most important, it showed that operating systems could be portable across hardware architectures.

I can offer one small anecdote relating to Ken and Unix:  at the 1983 ACM Symposium on Operating Systems Principles,  a small crowd of us gathered at night in the big open lounge area of the Mount Washington Hotel.  Ken was making the point that what distinguished Unix was its small size and internal consistency.  I asked him:  “but Ken, many of the systems I’ve worked on have grown big because new features were added, and eventually we wound up with several ways of doing the same things”.  “Ah,” he replied, “what makes Unix different is that whenever we add something, we take something out, so it stays small.”  I think of that discussion often when I see systems like Solaris, Red Hat, Linux, or even Cygwin.

Lest the above story be taken amiss, I have tremendous admiration for Ken, whom I’ve only met once or twice since.   He is one of the great computer scientists of the 20th century, and according to our several mutual friends a really nice guy.  His Turing award lecture Reflections on Trusting Trust is one of the most important (and enjoyable!) papers in computer science.  It includes the famous quote:

“The moral is obvious. You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code.”

I also suspect that Ken would stand by what he said about keeping Unix small, notwithstanding some of the variants that have come along over the years.

Everyone was welcome to propose ideas, and if enough people liked it and used it, the design became a standard. [...]  This was the ultimate in openness in technical design and that culture of open processes was essential in enabling the Internet to grow and evolve as spectacularly as it has.

…

Our loose, unnamed meetings grew larger and semi-organized into what we called the Network Working Group. In the four decades since, that group evolved and transformed a couple of times and is now the Internet Engineering Task Force. [link added...Noah] It has some hierarchy and formality but not much, and it remains free and accessible to anyone.

The R.F.C.’s have grown up, too. They really aren’t requests for comments anymore because they are published only after a lot of vetting. But the culture that was built up in the beginning has continued to play a strong role in keeping things more open than they might have been. Ideas are accepted and sorted on their merits, with as many ideas rejected by peers as are accepted.

The IETF is still one of the most open and one of the most effective standards organizations.

While rummaging around following links about this effort, I stumbled onto a video of a terrific talk by Captain Jerry Roberts.  Captain Roberts, one of the last surviving codebreakers from Bletchley, is a wonderful character and at age 88 still a very engaging speaker.  In this talk at UCL, he tells for the first time the story of his work at Bletchley. By quite an amazing coincidence, Captain Roberts is introduced in the video by my good friend Susanne Kord, who chairs the German Department at UCL.