|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 1
Messages: 1
Messages: 1
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Microsoft's Lampson at Usenix: Write software that expects to fail!
Written by Jack Vaughan
Usenix is arguably one of the more interesting among the many computing-oriented technical conferences. It caters to the small but proud group known as system programmers, mostly the true blue Unix folks that worked out many of the kinks of network computing from first principles over a period of years. Yes, it’s a Unix hotbed, but the folks who put it on are not so doctrinaire that they mightn’t invite a Microsoft Research luminary to present a paper. That’s what brought me to Usenix in Boston at the start of June.
That Usenix invited Microsoft Research Distinguished Engineer Butler Lampson to speak is really not so surprising. He is really quite at home at Usenix, being involved over the years in development of many of the languages and features that led to systems like Unix, and its more recent off shoots such as Windows NT, MacOS, and Linux.
At a session on ‘Failures and Futures in System Research’ Lampson discussed RISC, persistence, RPCs, garbage collection, and much, much more. His thesis was not vividly discernible. But he focused on the notion that, in most cases, to succeed, systems must be able to gracefully fail. Or, alternatively, that systems specified to be perfect are almost always bound to fail.
I took the idea to be: Build simpler systems that adapt to catastrophe.
Raising an RPC ruckus
Certainly, he hoped to raise a bit of a ruckus. Basically, he ranked distributed computing, RISC, and persistent objects as failures. You might say that technologies that were highly resistant to failure were the ones he marked as successes. These by his reckoning included RDBs, packet networks, virtual memory, software objects, and GUIs.
In the case of persistent objects and RPCs (this latter technology being one that Lampson had a hand in moving forward), the architecture places too many requirements on widely scattered nodes that must continually maintain faithfulness to a particular technical structure.
The problem with RPCs, according to Lampson, is that eventually you don’t have any influence over what is going on. “For general purposes, RPC has been a failure. Because the purpose was to mask the fact that the RPC was remote – and you can’t do that. I’ve been involved in a number of the projects, and I’ve become clearly convinced that the sum contribution of our RPC efforts was negative.”
RPCs, he summarized, have “pretty much been a disaster.”
“It turns out we didn’t do it quite right. You don’t have any control of what is going on. If you use RPCs [Remote Procedure Calls], you are stuck with what the RPC system wants. Very sad but true,” said Lampson.
Fancy typed
Lampson has concerns about any trends to fancy-typed systems. And he is not optimistic about creation of functional programming languages for general purpose programming.
He said: “So far as a general purpose programming language, functional programming has been a bust. It’s been extremely successful in narrow domains. Spreadsheets essentially are a functional programming language, and so is SQL.”
He noted that Euclid, a language he created with others in the late 1970s as a verifiable system software language, was subsequently described by others as a functional language. This, he said, "was a big surprise to us.”
What works, he claimed, is virtual memory, and packet networks. “Bitmaps have been great,” he said. Object programming has worked, but it has done harm as well. That is due to polymorphism, which, he said, “kills modularity.”
While cautiously crediting object programming as a success, Lampson was clearly critical of persistent objects. “The fundamental problem with persistent objects has turned out to be: If you actually build a system with a lot of long-lived data structures, if you do a few million ‘new’s,’ the question is whether you just have anything useful, or whether you just have a rubble of objects – and the answer is unfortunately, you just have a rubble of objects.”
One might guess that Lampson sees the Web as a defining moment for systems programming research. He is vexed that it did not come out of the systems programming research community. [Ed note: Although my recollection is that Berners-Lee invented the Web in between work on RPCs!] The Web, like its host, the Internet, is an example of a system that can fail regularly, and yet be tremendously successful.
Comment
My analysis is that what Lampson’s argument was building to was a consideration of perfection – or rather, the pursuit of perfection – versus real world resiliency. Systems when conceived -- I take as one of Lampson’s tenets -- tend to aim toward perfection. Sometimes this is a fatal flaw. He noted the vaunted [and failed] FAA air traffic system rewrite [1981-1994] as a system designed to fail, in that it was over specified – specified to death. In any case, the perfect system is only in certain instances even a worthwhile goal, one might surmise after hearing Lampson.
Lampson’s cautions are backed up by very considerable experience. He is one of an increasingly rare breed that was there at the birth of the minicomputer and personal computer. With Bob Metcalfe and others, he worked in the early ‘70s on the design of the Alto at Xerox Parc. That system led to workstations and windowed personal computers. With Howard Sturgis and others, he designed Cal TSS, the first working capability-based operating system. He designed the aforementioned Euclid and developed methods for secure Internet systems. In the early '80s, with Paul Rovner and others, he designed extensions to Modula 2 which provided automatic storage deallocation, runtime types, exceptions and concurrency.
Lampson’s comments may be viewed in the shadow of the swinging pendulum that is software. Increasingly complex systems, programmed via languages and tools that humans use with varied emphasis and effect, try to perfect certain capabilities. Then the software community begins to look for simpler systems approaches with perhaps narrower goals.
At the same time, Lampson seems to describe the age-old notion that you cannot change the world, at least all at one time. The question to ask of a potential new technical discipline, he said, is “not whether it’s natural, but ‘is it effective?’"
“Karate and haiku are examples of this. One, the haiku, requires an appreciative. But karate works even if people don’t appreciate it.”
The biggest problem with software, says Lampson, is this: “Not that it is unreliable, but that too many ambitious ideas are placed upon it.”
|
|
|
Message #213772
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Overengineering
I tend to agree with the idea that a good system must be simple and handle errors gracefully. Most of the time, software is overengineered by overwhelmed developers unable to handle simply the complexity of a task. It's not a surprise that successful technologies are quite simple technologies ; for example, while billions were invested in developing WAP web sites for cellphones, billions were made with the SMS technology that seemed like an afterthought. But it's simple, reliable, well suited for the terminal it's aimed to, and effective.
I guess Lampson thinks RPC is a failure because it's too complicated and limits what you can do. But I think that spanning processes over several computers is inherently complex ; it has not been overtly complicated by the overwhelmed engineers above... A network connection is slower and you have to adapt to it when you design your API, so what ? You need more computers, because your software is no longer working with all these users, right ? Then accept it !
Persistence, on the other end, is still too complicated, while good alternatives exist (have you ever heard of this great database querying tool named SQL, that can be learnt in one week, that has been optimized for 30 years and counting ?). This has all the makings of a failure to me...
All in all, "Write software that expects to fail!" is a good advice for young engineers. But are they listening ?
|
|
|
| |
|
| New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
|
|
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|
