Presentation on theme: "How Software Components Grew Up and Conquered the World zButler Lampson zFor many years programmers have dreamed of building systems from a library of."— Presentation transcript:
How Software Components Grew Up and Conquered the World zButler Lampson zFor many years programmers have dreamed of building systems from a library of reusable software components together with a little new code. The closest we've come is Unix commands connected by pipes. I'll discuss the fundamental reasons why software components of this kind haven't worked in the past and are unlikely to work in the future. Then I'll explain how the dream has come true in spite of this failure, and why most people haven't noticed.
How Software Components Grew Up and Conquered the World Butler Lampson Microsoft April 30, 2001
The software crisis zIts always with us. Why? yMoores law means always trying new things yComplexity moves into software yCant find the limits except by trial and error xA mans reach should exceed his grasp, or whats a heaven for. – Browning z Can components make a difference? yPITAC says yes
Progress? zProgramming from scratch zModifying existing code zBuilding on big components yWhite-collar computing zHigh-level programming yDeclarative yDomain-specific yExamples: spreadsheets, SQL A little A lot
The component dream zA library of tested, documented components. xMcIlroy, NATO Software Engineering Conference, 1968 zTo build your system, you take down a couple of dozen components and glue them together. Component Library
Why components dont work zNo business model zCost to understand and use zConflicting world views Business model Cost to understand World views
zA reusable component costs at least 3x as much as a good module for your system. yGenerality ySimplicity yCustomization yTesting yDocumentation yStability zWho will pay? yThe market wont support this kind of development No business model Just code it Good module for your system Reusable component ½ – 2 x 3 – 5 x Business model Cost to understand World views
Cost to understand zTo use a component, must understand its behavior yResource consumption yExceptions yCustomization yBugs yWorkarounds when it doesnt do what you want zOne measure: ratio of spec size to code size zThe alternative: re-implement it yourself Business model Cost to understand World views
Conflicting world views zA component interface embodies a view of the world: xData types xResource consumption xMemory allocation xException handling x… zWhen you put 10 world views together, the result is a mess. yNo one is responsible for design integrity, or for the whole thing working zInteractions are N 2 (N log N if youre lucky) Business model Cost to understand World views
Components that do work zUnix pipes yBuilt by Bell Labs Unix group yVery simple interface: char stream yUnencoded: just words and lines zLibraries (math and graphics) yTake a long time to perfect yClean mathematical model yWorld view inherited from math, and library usually done by a single group zLesson: It works in simple, narrow domains Business model Cost to understand World views
Components in PCs zPCs are built from (hardware) components yProcessor chip yDRAM SIMM yDisk + driver yDisplay monitor + driver y... + driver zWhy does it work? yOnly a few components work well xThese have very clear interfaces xOdd-ball ones have lots of problems yMicrosoft is responsible for integrity Business model Cost to understand World views
Community makes it easier zIncludes the component builders and its users yResearch or engineering community zPeople work for status in the community zShared context that everyone understands zCommon world view Business model Cost to understand World views
Good things, but not reusable components zCOM and Corba yThese are ways to run components zVisual Basic components and ActiveX. yYou can use a couple, but not more zModules with clean interfaces yThese are necessary, but not sufficient
Big components work zThey are so huge that you only use 3 of them. y5-20 M lines yOperating system: Linux, Windows yRAD environment: Visual Basic, Java yBrowser: Netscape, Internet Explorer yDatabase: Oracle, DB2, SQL Server User Interface Business logic Database NetscapeVisual BasicOracle
Why big components work zYou can sell them yCustomer only has to buy a few zThe spec is much smaller than the code yand you can customize them zThey impose their own world view yVendor provides design integrity inside yOnly N(N - 1)/2 = 3 interactions2 if layered zMoores law –cycles and storage to burn Business model Cost to understand World view
Customization is critical zOSs have applications, scripts zBrowsers have scripts, Java, plug-ins, DHTML zRDBs have SQL User Interface Business logic Database NetscapeVisual BasicOracle
Burning cycles zIs it bad engineering? No. zEngineers job is greatest customer value yTime to market yFlexibility yTotal cost of ownership zTodays PC = 10,000 x Alto. Where did it go? yDeliver lots of features quickly xCant have first-class design everywhere xTrade resources for time to market yIntegration ySupport lots of hardware yBackward compatibility
What else could work? zCode manipulation zSpecs with teeth yEncapsulation zDeclarative programming
Code manipulation zCopy a module and change it yThe most flexible way to customize zTools to support this ySpecs help in understanding the code yChecks (types, assertions, …) catch mistakes yAnalyzers reveal structure zThe true destiny of open source?
Specs with teeth zDocumentation with checks that: y The component matches the documentation y The use is legal zChecking ensures correct documentation yMore likely to pass the coffee stain test zPrototype: type checking
Specs with teeth zCreate/generate vs enforce yCreate: Stubs, transactions, GC yEnforce: Sandbox, Purify, types zStatic vs dynamic check yStatic: Types, PCC xNo dynamic error can occur xTheres no debugger in Peoria. Morris xWell-typed programs dont go wrong. Milner yDynamic: Sandbox, XML
Specs with teethEncapsulation zSandbox yOperating system, Java, SFI, information flow zCode modification ySFI, Eraser, Purify zTransactions yAutomatic concurrency, fault tolerance, resource management zReplicated state machines yAutomatic fault tolerance
Declarative programming zExamples ySpreadsheets ySQL yMathematica yYACC zAdvantages yCloser to intent, hence faster and more reliable yMore analysis and optimizationparallel SQL zHigh-level programming?
Summary zThe component dream cant work zBig components do work yUse only 3 yCustomize zWhat else? yEncapsulate yDeclare Business model Cost to understand World views
Your consent to our cookies if you continue to use this website.