"white collar" computing: spreadsheets, SQL; high-level, declarative,
domain-specific application programmings. Was good for an
order-of-magnitude.
Reused an infamously garish Tennenhouse illustration of a
purple-hatted sorcered, bubbling pot, and mythical liubrary of tested
components.
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,
documentation, stability
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
behind it"
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
components].
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
and bits.
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
open source?
"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!))
Encapsulation:
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,
resource-management
Replication
Declarative programming
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.
SUMMARY:
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.