"white collar" computing: spreadsheets, SQL; high-level, declarative,
domain-specific application programmings. Was good for an
Reused an infamously garish Tennenhouse illustration of a
purple-hatted sorcered, bubbling pot, and mythical liubrary of tested
Butler: the Macilroy symbol table dream is directly in the original
NATO-Garmisch report of 1968
"It's never gonna work -- fundamentatlly flawed -- and no amount of
federal funding will make it work"
Reusable component costs at least 3x more than coding a module.
-- added costs for generality, simplicity, customization, testing,
No business model today for developing reusable modules.
Wherever Willpower is good enough, use Willpower rather than Methodology.
Having to experiment with a new component to understand what is does
kind of destroys the dream, doesn't it?
MS just completed "Line Services" -- all typography for word
processing. Sounded familiar because I interviewed on that team in 95
when it was beginning. Indeed, that was the one: "Took 4 years, best
talent in the company, would have been killed 5 times if Bill wasn't
Huge costs, speculative returns.
Aspect-oriented complaint: too many views to square away: resources,
exceptions, power, ui, ...
Components that do work: Piped text-processors. Math and graphics
libraries (benefit from a well-founded world view).
Why did pipes work? biz model: Bell funded the whole thing. Interface
was extremely narrow (char *s) -- note how it breaks down as soon as
you code more structure into char strings.
Community makes it possible -- world views are embedded in social groups.
Things which are NOT components:
COM, CORBA, Visual Basic, clean Modules.
These are just remoting technologies.
Success stories are very, very large-scale: 5-20Mb OSes, browsers,
RAD IDEs, Databases. [Arguably, these are virtual machines more than
Why do *those* examples break the rules? they are large enough to
package and sell. Vendor provides design integrity. Specs, however
complex, are still a fraction of code size (beware of 1:1 docs and
code). These components make life easier precisely by wasting cycles
Customization is critical: scripting, SQL, programming.
Burning cycles is NOT bad engineering, necessarily.
** WHAT ELSE could work?
Code manipulation -- case-n-paste with tool support. True destiny of
"I seriously hope that Open Source meets its aspirations and Linux
competes with NT -- Microsoft works much better with competition..."
Specs with teeth (encapsulation)
active monitoring and checking. (Dave Parnas' coffee-stain test: do
people USE the req documents?)
Extends the meme of type-checking.
Axes to compare:
1. specs that generate code (stubs) to enforcement
(sandboxing, types, Purify)
2. static (types, proof-carrying-code -- checking text) vs.
dynamic (sandbox, XML (?! no explanation given!))
Sandbox: software fault isolation, multilevel secure
(Eraser system by Savage at DECSRC? eliminated races/locked data contention)
Transactions -- wonderful, wonderful magic! -- sprinkle transaction
dust on old seqential programs to gain concurrency, fault-tolerant,
e.g. Mathematica, YACC; similar to "high-level programming"
Should be closer to intent of programmer.
dramatic example of smart analysis and optimization: Parallel SQL.
The component dream can't work
Big components do work: use only 3, customize
What else? Encapsulate, Declare.
My question revolved around active proxies: does the little space of
web proxies "break the rules" -- active proxies that translate to
japanese, or distill pages, or --most promisingly-- fuse part
catalogs or aggregate multiple airline reservation sites --
correspond to a working, multilateral building-block space? -- big
components that are now *multilateral*
A: programs won't click on links. Can't have reliability, scalability
through active web proxies when you take humans out of the loop.
BL: "Customers are irrationally putting features ahead of reliablity
-- products are as successful as customers demand".
Kevin Sullivan: I can see that fine-grained components won't work,
but there haven't been infrastructure/architectures for integrating
e.g. the active document metaphor.
A: you _can_ use office as a platform, but as a component, it's
fundamentally flaky. [similar to his Web argument]. That's sad, but
that's the way it is, but it's a consequence of the business model.
Peyman: why has the HW community done such a better job? A: they're
much, much, much simpler -- and it doesn't work without lots of
software, which patches up their problems. I assure you the hardware
is in a much simpler domain.