Simonyi – King Of Meta

Monday, March 12, 2007

Excerpts from “Anything You Can Do, I Can Do Meta – Space tourist and billionaire programmer Charles Simonyi designed Microsoft Office.  Now he wants to reprogram software.”

On April 9, at a remote launchpad on the plains of Kazakhstan, a ground controller will finish his countdown; a Soyuz rocket will fire; and Charles Simonyi–Microsoft’s former chief architect, the tutelary genius behind its most famous applications, the inventor of the method of writing code that the company’s programmers have used for 25 years, and now the proponent of an ambitious project to reprogram software–will begin his ascent into space…..In a career spanning four decades, every time he has confronted some intractable problem in software or life, he has tried to solve it by stepping outside or above it.  He even has a name for his favorite gambit: he calls it “going meta.”…..Simonyi believes he can solve a host of stubborn problems that have always plagued computers by offering everyone who uses them, and the coders who program them, a higher-order view of software.  Bill Gates calls Simonyi “one of the great programmers of all time.”…..Every year, according to a 2002 study by the National Institute of Standards and Technology, software failures cost $59.5 billion…..The past half-century of computing has seen wonderful progress…..This progress has been fueled by the exponential curve of Moore’s Law, Intel founder ­Gordon Moore’s prediction that microchips’ power would double (or their cost would halve) every one to two years.  But even as Moore’s Law has made each year’s new computers faster and cheaper, the flexi­bility and utility of our computer systems have been limited by the slower, uneven evolution of software.  One formulation of this problem is known as Wirth’s Law, after programming expert Niklaus Wirth: “Software gets slower faster than hardware gets faster.”…..Simonyi’s ambition is to unstop that software bottleneck–characteristically, by going meta…..If Simonyi has his way, programmers will stop trying to manage their clients’ needs. Instead, for every problem they’re asked to tackle–whether inventory tracking or missile guidance–they will create generic tools that the computer users themselves can modify to guide the software’s future evolution…..In 2004, Simonyi proposed his own law: “Anything that can be done could be done ‘meta.‘”…..

Wysiwyg is an example of a layer of abstraction–a higher-level tool that allows computer users to ignore some lower-level complexity.  Programmers use abstractions all the time.  The text code written in a programming language is an abstraction of the machine code that a computer actually understands.  A Web domain name is an abstraction of a server’s numerical Internet Protocol address…..Every generation of programmers uses its era’s programming languages and tools to build the programs of the next generation.  Layers of abstraction have accumulated like geological strata…..The history of software is the history of these layers, each of them lifting programmers farther from the binary, leaving them better able to coax computers into performing useful tasks.  Steadily, programmers gained more power.  But they were also tackling ever more ambitious problems.  Programs ballooned in size, and programmers started getting lost in tangles of what they called “spaghetti code,” which proved impossible to unravel and repair.  Thus, large software projects became epics of frustration and delay.  Program managers faced business problems like, How do you realistically schedule a project?  How do you improve individual productivity?  How do you coördinate complex work across a large team?  Each of these questions proved surprisingly difficult to answer.  The difficulty of coördinating a team’s work inspired software engineering’s most famous dictum, known as Brooks’s Law: “Adding manpower to a late software project makes it later.”  Frederick P. Brooks Jr. reached this gloomy conclusion after leading IBM’s troubled effort to write software for its 360 mainframes in the 1960s.  In his 1975 book, The Mythical Man-Month , Brooks observed that work proceeds slower on bigger teams because of “coördination costs”–the time programmers lose keeping one another apprised of their work…..Simonyi argues that his approach solves several of software engineering’s most persistent problems.  Programmers today, he often says, are “unwitting cryptographers”: they gather requirements and knowledge from their clients and then, literally, hide that valuable information in a mountain of implementation detail–that is, of code.  The catch is, once the code is written, the programmers have to make any additions or changes by modifying the code itself.  That work is painful, slow, and prone to error.  We shouldn’t be touching the code at all, Simonyi says.  We should be able to design functions and data structures–which intentional programming represents as “intentional trees”–and let the generator modify the code accordingly…..The visible fruit of Intentional’s work to date is a nifty tool called the Domain Workbench, which stores a program’s vital information in an intentional-tree database and then offers you many different “projections” of that information.  In a demonstration Intentional gave at two conferences last fall, the Workbench–using a feature called the Kaleidoscope–took a series of code fragments and displayed them in a dizzy­ing variety of formats.  It didn’t matter how the syntax of the code had been specified; you could view it, and change it, using whatever notation you preferred.  You could edit your program as traditional bracketed and indented code, or switch to outline form, or make it look like a schematic electrical-wiring diagram, or choose something called a “railroad diagram,” a kind of flowchart notation derived from old-fashioned train maps.  Each view is a translation of the underlying tree–which you can also examine and edit…..Intentional programming is similar in concept to what-you-see-is-what-you-get word processing programs, which Charles ­Simonyi, Clifford’s boss, pioneered. “Wysiwyg” text editors let computer users manipulate a document’s appearance on screen without forcing them to master the underlying code. ­ Similarly, intentional programming encourages computer users to express their needs in their own familiar language, then shows them comprehensible views or “projections” of the emerging design before the executable code is assembled.  It’s not the only programming philosophy that relies on such graphical representations; the Unified Modeling Language (UML), developed in the mid-1990s at Rational Software (now part of IBM), also uses graphical diagrams to represent a program’s function, structure, and behavior.  But UML diagrams can’t be transformed into finished software, which is Simonyi’s dream for intentional programming…..

The Law of Leaky Abstractions : Software, we’ve seen, is a thing of layers, with each layer translating information and processes for the layers above and below.  At the bottom of this stack of layers sits the machine with its pure binary ones and zeros.  At the top are the human beings, building and using these layers.  Simonyi’s Intentional Software, at heart, simply proposes one more layer between the machine and us.  Software’s layers are its essence, and they are what drive progress in the field, but they have a persistent weakness.  They leak…..In an essay titled “The Law of Leaky Abstractions,” Joel Spolsky wrote, “All non-trivial abstractions, to some degree, are leaky.  Abstractions fail.  Sometimes a little, sometimes a lot.  There’s leakage.  Things go wrong.”…..Abstractions do not really simplify our lives as much as they were meant to.….The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying, “Learn how to do it manually first, then use the wizzy tool to save time.”  Code-generation tools that pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting.  So the abstractions save us time working, but they don’t save us time learning…..And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.  So even though “the abstractions we’ve created over the years do allow us to deal with new orders of complexity in software development that we didn’t have to deal with ten or fifteen years ago,” and even though these tools “let us get a lot of work done incredibly quickly,” Spolsky wrote, “suddenly one day we need to figure out a problem where the abstraction leaked, and it takes two weeks.”  The Law of Leaky Abstractions explains why so many programmers I’ve talked to roll their eyes skeptically when they hear descriptions of Intentional Programming or other similar ideas for transcending software’s complexity.  It’s not that they wouldn’t welcome taking another step up the abstraction ladder; but they fear that no matter how high they climb on that ladder, they will always have to run up and down it more than they’d like–and the taller it becomes, the longer the trip.

Reference :

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: