1997-07-20 - Re: Will Monolithic Apps Dominate? (fwd)

Header Data

From: Robert Hettinga <rah@shipwright.com>
To: cypherpunks@ssz.com (Cypherpunks Distributed Remailer)
Message Hash: cc52cdc062b7e4f966043f120cb5b9be354d4d785c8662bc90df9f85ef085640
Message ID: <v03110702aff80c49ac56@[139.167.130.248]>
Reply To: <199707201456.JAA08917@einstein.ssz.com>
UTC Datetime: 1997-07-20 20:01:06 UTC
Raw Date: Mon, 21 Jul 1997 04:01:06 +0800

Raw message

From: Robert Hettinga <rah@shipwright.com>
Date: Mon, 21 Jul 1997 04:01:06 +0800
To: cypherpunks@ssz.com (Cypherpunks Distributed Remailer)
Subject: Re: Will Monolithic Apps Dominate? (fwd)
In-Reply-To: <199707201456.JAA08917@einstein.ssz.com>
Message-ID: <v03110702aff80c49ac56@[139.167.130.248]>
MIME-Version: 1.0
Content-Type: text/plain



At 10:56 am -0400 on 7/20/97, Jim Choate wrote:


> You should look into Plan 9

<snip>

> Since the OS already bids for processor space it would not require a
> major architecture mod to include E$/crypto functions.

Yeah. I've seen demos of what I think was plan 9, actually it's
successor(?). Both of them were Bell (now Lucent) efforts, right?

Certainly, it looks like it was a step in the right direction, if it works
as advertised.


>
> > Finally, there's the issue of Mhyrvold's software-as-a-gas idea. That is,
> > that bloatware is a direct result of Moore's Law.
>
> I have to disagree. Bloatware comes from the way we look at software
> (ie generalize & modularize it) and the way we impliment it (ie libraries).
> While it makes the programmers job easier it makes the amount of software
> required for the job larger that required because the libraries have
> functions and features that aren't used (in this product). Bloatware won't
> be fixed unless we (ugh) go back to monolithic project design with most
> code custom built with little re-use from previous versions. I suspect it is
> easier to buy another 4M of RAM than to pay the programmers to re-create the
> wheel each time a new version comes out.

No, but I bet that if there was a profit-loss feedback loop at the lowest
possible level of the, what?, solution (do we call a group of autonomous
cooperating bits of code an application?) then, at some point in the
development of a cash settlement mechanism, the benefits of efficiency
would far outweigh the extra cost of cash handling.

The idea of micromoney as processor food, I think, gets us a way to pay for
the adaptive evolution with the same, or better, results than we'd get by
top-down monolithic project design.

Cheers,
Bob Hettinga

-----------------
Robert Hettinga (rah@shipwright.com), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
The e$ Home Page: http://www.shipwright.com/







Thread