[
Lists Home |
Date Index |
Thread Index
]
I replied to Joel in my blog. Notably, that many of the
failures of astronaut architecture he cites have succeeded.
It might be time to reexamine the examples.
On the other hand, I listened to Burt Rutan at a local
grass strip airfield where he spoke (in a hangar) about
his work on SpaceShipOne and compared it to NASA (which
he pronounces NaySay), and I might blog that later given
his insight into simplicity and getting to orbit.
The way to deal with complexity is to limit the mission
and reuse as much of the system in as many places as you
can. That ensures it can be done with a small team of
smart people, that testing costs are reduced, and that
any system to be tested is tested in an environment you
understand (the cockpit of the White Knight is the same
as the cockpit of SpaceShipOne, meaning it could go into
space itself; it doesn't, but it got waaay more flight
and therefore, more testing). He also says the worst
place to get money is Congress. So maybe the DeepPockets
of DC are the worst place to find a solution. All they
have is money. ;-) Rutan complains to anyone who listens
about the regulations and the lack of insight into
engineering principles that work when one quits attempting
to meet unrealistic demands.
Community size is irrelevant compared to reliable running code
when innovating. It is deployment that is at issue, and that
means linktypes and objects. The job of people who want
this is to prove they need it because we already have
efficient and well-understood ways to build and deploy
GUIs. If the Soyuz works, you have to ask if you need
the Space Shuttle for transportation. It makes a fine
truck but a lousy and expensive taxi.
Rutan made one comment that should stick here in the windy
wailing walls of XML-Dev. My son, Daniel, asked Rutan if he was going
to build an orbital vehicle. He said, "No, I won't say I am
going to do that because I don't know how to do that and
until I do know how and have a deep gut conviction what
I know will work, I won't say I am going to do it." I offer
that up to the overflow of vision-cum-marketing types who
have filled the Beltway with their papers and presentations
to elicit funding for ideas they have lifted from other
people's papers and presentations but don't have line of
code one written.
len
From: Michael Champion [mailto:michaelc.champion@gmail.com]
On Mon, 25 Oct 2004 08:21:39 -0500, Bullard, Claude L (Len)
<len.bullard@intergraph.com> wrote:
> That will be more complex than Hytime, Michael.
Quite possibly. Starting with something as abstract as OWL does take
the well-known path into the weeds of trying to solve intractable
concrete problems by abstracting way reality into a form that can be
solved. That has some notable successes (Newton comes to mind!) but
numerous failures, of the sort Joel Spolsky talks about in his
Architecture Astronauts essay
http://www.joelonsoftware.com/articles/fog0000000018.html
The way to deal with complexity, in my very humble opinion, is to
start with the simple and proven,such as HTML-ish one-way links (and
most people can stop there). For those who can't, the question
whether to support multiple complex ways of specifying relationships
of different directions, types, semantics, etc. or to try to converge
on one that more or less works for all. Likewise, to really help real
people the solution must have the network effect working to push it
forward as well as some evolutionary selection pressure to keep it
down to the bare minimum. HyTime, XLink, Topic Maps, etc. clearly
don't have the communities that generate the network effect and
selection pressure needed. I'm not at all sure that OWL does either,
but it does have a) a lot of smart peole building it; b) the W3C
powers-that-be pushing it, and c) some extremely deep pockets in DC
funding it and applying it.
With a gun to my head, I'd predict that OWL has the best chance among
current technologies of leading to a breakthrough in the
Modeling/Linking area, but I certainly wouldn't bet the farm that it
will avoid the fate of HyTime.
|
