Greetings,
    One of the books I have been reading lately is "The Next 
    Fifty Years, Science in the First Half of the 21st Century".
    It is a collection of essays by 25 third party experts.
    One of the them is by Jaron Lanier. His essay is about 
    complexity.  He makes an interesting statement:

	"Since the complexity of software is currently limited by the
	ability of human engineers to explicitly analyze and manage it,
	we can be said to have already reached the complexity ceiling 
	of software as we know it.  If we don't find a different way
	of thinking about and creating software, we will not be writing
	programs bigger than about 10 million lines of code, no matter 
	matter how fast, plentiful or exotic our processors become."
	-Jaron Lanier  (The Next Fifty Years, page 219)

    Most of my experience is in relatively small PC and embedded systems.
    I wonder, is Lanier's perspective common on larger systems?
<curious>
-het




-- 
"Simplicity is the ultimate sophistication."  -olde Apple ad

Computer Links: http://www.autobahn.mb.ca/~het/clinks.html
H.E. Taylor  http://www.autobahn.mb.ca/~het/

"H. E. Taylor" <het@despam.autobahn.mb.ca> wrote in message
news:3F00F29A.43B@despam.autobahn.mb.ca...
> Greetings,
>     One of the books I have been reading lately is "The Next
>     Fifty Years, Science in the First Half of the 21st Century".
>     It is a collection of essays by 25 third party experts.
>     One of the them is by Jaron Lanier. His essay is about
>     complexity.  He makes an interesting statement:
>
> "Since the complexity of software is currently limited by the
> ability of human engineers to explicitly analyze and manage it,
> we can be said to have already reached the complexity ceiling
> of software as we know it.  If we don't find a different way
> of thinking about and creating software, we will not be writing
> programs bigger than about 10 million lines of code, no matter
> matter how fast, plentiful or exotic our processors become."
> -Jaron Lanier  (The Next Fifty Years, page 219)
>
>     Most of my experience is in relatively small PC and embedded systems.
>     I wonder, is Lanier's perspective common on larger systems?
> <curious>
>


although plenty of predictions do come true
most do not.
although there may be a limit as to how simple something can be
there seems to be no linit to complexity!

"philo" <philo@plazaearth.com> wrote in message
news:vg1msvke27tb8f@corp.supernews.com...
>
> "H. E. Taylor" <het@despam.autobahn.mb.ca> wrote in message
> news:3F00F29A.43B@despam.autobahn.mb.ca...
> > Greetings,
> >     One of the books I have been reading lately is "The Next
> >     Fifty Years, Science in the First Half of the 21st Century".
> >     It is a collection of essays by 25 third party experts.
> >     One of the them is by Jaron Lanier. His essay is about
> >     complexity.  He makes an interesting statement:
> >
> > "Since the complexity of software is currently limited by the
> > ability of human engineers to explicitly analyze and manage it,
> > we can be said to have already reached the complexity ceiling
> > of software as we know it.  If we don't find a different way
> > of thinking about and creating software, we will not be writing
> > programs bigger than about 10 million lines of code, no matter
> > matter how fast, plentiful or exotic our processors become."
> > -Jaron Lanier  (The Next Fifty Years, page 219)
> >
> >     Most of my experience is in relatively small PC and embedded
systems.
> >     I wonder, is Lanier's perspective common on larger systems?
> > <curious>
> >
>
>
> although plenty of predictions do come true
> most do not.
> although there may be a limit as to how simple something can be
> there seems to be no linit to complexity!
>
Depends on what you mean by "program".  How many lines of code in
MVS/OS390?  OS400 including SLIC?  Windows XP?  Word XP?  Unix?  Oracle?
DB2?

Who is this John Lanier guy?  Somebody I should have heard of?

Seems to me that modular programming, object orientation, or just
languages with higher level constructs will resolve many of his
concerns.  One doesn't design an airplane or bridge by writing down how
to mine ore, smelt it, make bolts and rivets, roll sheet etc.

del cecchi
>

On Mon, 30 Jun 2003 19:31:54 -0700, "H. E. Taylor"
<het@despam.autobahn.mb.ca> wrote:

>Greetings,
>    One of the books I have been reading lately is "The Next 
>    Fifty Years, Science in the First Half of the 21st Century".
>    It is a collection of essays by 25 third party experts.
>    One of the them is by Jaron Lanier. His essay is about 
>    complexity.  He makes an interesting statement:
>
>	"Since the complexity of software is currently limited by the
>	ability of human engineers to explicitly analyze and manage it,
>	we can be said to have already reached the complexity ceiling 
>	of software as we know it.  If we don't find a different way
>	of thinking about and creating software, we will not be writing
>	programs bigger than about 10 million lines of code, no matter 
>	matter how fast, plentiful or exotic our processors become."
>	-Jaron Lanier  (The Next Fifty Years, page 219)
>
>    Most of my experience is in relatively small PC and embedded systems.
>    I wonder, is Lanier's perspective common on larger systems?
><curious>
>-het

FWIW:

http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf

"a single domestic passenger airplane alone can contain as many as 6
million parts"

http://www.majorprojects.org/pubdoc/677.pdf

" Aircraft carrier project--a naval project with 30 million parts (a
submarine has only 8 million parts)."

Why would software be any harder?

A paradigm already exists for scaling programs to arbitrarily large
sizes.  It's called a network.

RM

In article <aN6Ma.1222$IP6.53730@eagle.america.net>,
del cecchi <dcecchi@msn.com> wrote:
>Who is this John Lanier guy?  Somebody I should have heard of?

    His early claim to fame was involvement in and promotion of early
Virtual Reality efforts, when that was hot in the early 90s. Seems to
have gone on to industry punditry since.
    Jon
    __@/

In article <2o12gvc6ishbpa20n8938rsae42s47vgbo@4ax.com>,
Robert Myers <rmyers@rustuck.com> writes:
|> 
|> FWIW:
|> 
|> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
|> 
|> "a single domestic passenger airplane alone can contain as many as 6
|> million parts"
|> 
|> http://www.majorprojects.org/pubdoc/677.pdf
|> 
|> " Aircraft carrier project--a naval project with 30 million parts (a
|> submarine has only 8 million parts)."
|> 
|> Why would software be any harder?

Because it is less well engineered.  Also, do you know how many
such military engineering systems have significant and even major
components that are decommissioned before they are got to work in
the field?

|> A paradigm already exists for scaling programs to arbitrarily large
|> sizes.  It's called a network.

Yeah, right.  I was having run-ins with the "structured programming"
dogmatists back in the 1960s and 1970s on this one, and the common
errors have not changed.

By splitting programs into functions of at most 20 lines long (yes,
seriously), you may be able to understand every function at a glance.
You will not, however, be able to understand their interactions.  So
you split the program into separate ones of at most 20 functions,
and can now understand every program.  But you will not be able to
understand the network of programs.  And so on.

The same thing applies to hardware.  It is easy to analyse and debug
race and other inconsistency conditions involving two entities.  As
networks grow in complexity, it becomes harder and harder.  There
comes a point (approaching, in some networks) where most failure
time (down time or debugging) is not associated with a problem in
ANY component, but is associated with the network structure itself.
TANSTAFFL.

Have you ever tried to report a problem to a large vendor that is
due SOLELY to the underlying computational assumptions of three or
more separately developed components being subtly incompatible?
I have.  Guess how far I got.


Regards,
Nick Maclaren.

Regards,
Nick Maclaren.

In article <Pine.LNX.4.55.0307010926370.12021@ask.diku.dk>,
"Peter \"Firefly\" Lund" <firefly@diku.dk> writes:
|> On Tue, 1 Jul 2003, Nick Maclaren wrote:
|> 
|> > |> Why would software be any harder?
|> >
|> > Because it is less well engineered.  Also, do you know how many
|> 
|> No.  Because you don't have high-level screws.  10 million lines of mostly
|> flat-line code broken into pieces that interact very little with each
|> other would be a lot easier to understand than 10 million typical lines.

I suggest learning a little more about the design of such systems.
Your point is correct, but your viewpoint of their problems is
overly simplistic.

|> It would also be even easier if we did apply the engineering we know and
|> cut it down to say 5 or 10 thousand lines (probably less).

I know of no such example.  If you have ever tried to write a
serious product and keep it down to that size, you will have found
out that only some of the bloat is due to engineering incompetence.
Rather more is due to interfaces being designed non-mathematically,
but there is a large residue of special cases, messy situations and
so on that can't be handled compactly.

Factors of 10 reduction are often possible; factors of 100, perhaps.
I do not believe factors of 1,000 and more, as you are claiming.


Regards,
Nick Maclaren.

Nick Maclaren wrote:
<...snip...>
> Factors of 10 reduction are often possible; factors of 100, perhaps.
> I do not believe factors of 1,000 and more, as you are claiming.
> 
> Regards,
> Nick Maclaren.

I recently explored this area in a short article at (long link may be 
broken in parts by the newsreader):
www.extra.research.philips.com/natlab/sysarch/BloatingExploredPaper.pdf
"Exploration of the bloating of software"

regards Gerrit

-- 
Gaudi systems architecting:
http://www.extra.research.philips.com/natlab/sysarch/

In article <1057052079.161351@saucer.planet.gong>,
   "Rupert Pigott" <roo@dark-try-removing-this-boong.demon.co.uk> wrote:
>"Robert Myers" <rmyers@rustuck.com> wrote in message
>news:2o12gvc6ishbpa20n8938rsae42s47vgbo@4ax.com...
>
>[SNIP]
>
>> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
>>
>> "a single domestic passenger airplane alone can contain as many as 6
>> million parts"
>>
>> http://www.majorprojects.org/pubdoc/677.pdf
>>
>> " Aircraft carrier project--a naval project with 30 million parts (a
>> submarine has only 8 million parts)."
>>
>> Why would software be any harder?
>
>Simple : Because only in the software industry would you expect less
>than a handfull of people to develop and maintain such a system. I
>imagine that Boeing et al have > 5 people designing an airliner, and
>it almost certainly has > 5 when it comes to actually fabricating
>the sucker.

On a plane one day, I sat next to a guy who owned a company who
made just airplane wings.  He told me it took 9 months to make one.
That gives just a hint about complexity.

/BAH

Subtract a hundred and four for e-mail.

Robert Myers <rmyers@rustuck.com> wrote in 
news:2o12gvc6ishbpa20n8938rsae42s47vgbo@4ax.com:

> On Mon, 30 Jun 2003 19:31:54 -0700, "H. E. Taylor"
> <het@despam.autobahn.mb.ca> wrote:
> 
>>Greetings,
>>    One of the books I have been reading lately is "The Next 
>>    Fifty Years, Science in the First Half of the 21st Century".
>>    It is a collection of essays by 25 third party experts.
>>    One of the them is by Jaron Lanier. His essay is about 
>>    complexity.  He makes an interesting statement:
>>
>>     "Since the complexity of software is currently limited by the
>>     ability of human engineers to explicitly analyze and manage it,
>>     we can be said to have already reached the complexity ceiling 
>>     of software as we know it.  If we don't find a different way
>>     of thinking about and creating software, we will not be writing
>>     programs bigger than about 10 million lines of code, no matter 
>>     matter how fast, plentiful or exotic our processors become."
>>     -Jaron Lanier  (The Next Fifty Years, page 219)
>>
>>    Most of my experience is in relatively small PC and embedded systems.
>>    I wonder, is Lanier's perspective common on larger systems?
>><curious>
>>-het
> 
> FWIW:
> 
> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
> 
> "a single domestic passenger airplane alone can contain as many as 6
> million parts"
> 
> http://www.majorprojects.org/pubdoc/677.pdf
> 
> " Aircraft carrier project--a naval project with 30 million parts (a
> submarine has only 8 million parts)."
> 
> Why would software be any harder?
> 
> A paradigm already exists for scaling programs to arbitrarily large
> sizes.  It's called a network.

The problem is with so-called "emergent behaviour" in which the 
each component is well defined and understood, but the interactions
of a large number of components isn't.

A simple non-technical analogy (always dangerous :) is 
that 
    	- the propoerties of each grain of sand are well 
    	  defined and understood.
    	- they don't help when trying to understand why
    	  heaps of sand are conical with (IIRC) a 35 degree
    	  half angle, which is only very ewakly dependent on
    	  the size and shape of the individual grains
Nowhere in the "definition" of a grain of sand is that 
35 degrees "encoded".

But of course good engineering can delay the point at which 
unexpected emergent behaviour appears.

In article <Pine.LNX.4.55.0307011032230.12021@ask.diku.dk>,
"Peter \"Firefly\" Lund" <firefly@diku.dk> writes:
|> On Tue, 1 Jul 2003, Nick Maclaren wrote:
|> 
|> > I suggest learning a little more about the design of such systems.
|> 
|> I suggest you get better at reading metaphors.

Sigh.  Yes, I read it as a metaphor.  It was a bad one, which
is why I responded.  The equivalents to the bolts (or screws)
in a ship are the symbols like parentheses in a program.

There are equivalently higher-level concepts in naval architecture,
and those are the ones that cause the trouble.  Such as the open
communications ducts that caused the fire in HMS Sheffield, which
has an exact analogy in the failure of software.  And, like the
latter, it was known to be a problem in the 1960s (in high-rise
building), yet had been ignored by the builders of that class of
vessel in the 1980s.

The fact that modern passenger aircraft don't crash as often as
modern computer systems is not because they are simpler, but
because traditional engineering discipline is used.


Regards,
Nick Maclaren.

"Robert Myers" <rmyers@rustuck.com> wrote in message
news:2o12gvc6ishbpa20n8938rsae42s47vgbo@4ax.com...

[SNIP]

> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
>
> "a single domestic passenger airplane alone can contain as many as 6
> million parts"
>
> http://www.majorprojects.org/pubdoc/677.pdf
>
> " Aircraft carrier project--a naval project with 30 million parts (a
> submarine has only 8 million parts)."
>
> Why would software be any harder?

Simple : Because only in the software industry would you expect less
than a handfull of people to develop and maintain such a system. I
imagine that Boeing et al have > 5 people designing an airliner, and
it almost certainly has > 5 when it comes to actually fabricating
the sucker.

Cheers,
Rupert

On Tue, 1 Jul 2003, Nick Maclaren wrote:

> Sigh.

Sighing makes you sound old, Nick.

-Peter

In article <bdre26$56m$1@pegasus.csx.cam.ac.uk>,
Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>
>In article <Pine.LNX.4.55.0307010926370.12021@ask.diku.dk>,
>"Peter \"Firefly\" Lund" <firefly@diku.dk> writes:
>|> On Tue, 1 Jul 2003, Nick Maclaren wrote:
>|> 
>|> > |> Why would software be any harder?
>|> >
>|> > Because it is less well engineered.  Also, do you know how many
>|> 
>|> No.  Because you don't have high-level screws.  10 million lines of mostly
>|> flat-line code broken into pieces that interact very little with each
>|> other would be a lot easier to understand than 10 million typical lines.
>
>I suggest learning a little more about the design of such systems.
>Your point is correct, but your viewpoint of their problems is
>overly simplistic.
>
>|> It would also be even easier if we did apply the engineering we know and
>|> cut it down to say 5 or 10 thousand lines (probably less).
>
>I know of no such example.  If you have ever tried to write a
>serious product and keep it down to that size, you will have found
>out that only some of the bloat is due to engineering incompetence.
>Rather more is due to interfaces being designed non-mathematically,
>but there is a large residue of special cases, messy situations and
>so on that can't be handled compactly.

You need a way to isolate the residue of special cases. A language, 
a subsystem. You need to bring their complexity contribution down to
additive levels, not multiplicative.

>Factors of 10 reduction are often possible; factors of 100, perhaps.
>I do not believe factors of 1,000 and more, as you are claiming.

I don't believe most large projects really can be rolled back that
drastically. They must be compartmentalized instead. 

-- mrr

In article <3F018251.7060309@cavtel.net>,
   jonah thomas <j2thomas@cavtel.net> wrote:
>Nick Maclaren wrote:
>> Robert Myers <rmyers@rustuck.com> writes:
>
>> |> A paradigm already exists for scaling programs to arbitrarily large
>> |> sizes.  It's called a network.
>
>> Yeah, right.  I was having run-ins with the "structured programming"
>> dogmatists back in the 1960s and 1970s on this one, and the common
>> errors have not changed.
>
>> By splitting programs into functions of at most 20 lines long (yes,
>> seriously), you may be able to understand every function at a glance.
>> You will not, however, be able to understand their interactions.  So
>> you split the program into separate ones of at most 20 functions,
>> and can now understand every program.  But you will not be able to
>> understand the network of programs.  And so on.
>
>The way I understand that dogma, you need first to have your small 
>functions interact only across a known simple interface.  So the 
>interaction of functions is known and simple, and you can ignore their 
>details and look only at the inputs and outputs.  Then you make them 
>interact using programs that are no more complicated than those first 
>functions.  The high-level programs must also be short and simple and 
>interact only through simple known interfaces.  And so on, hierarchically.
>
>This approach can sometimes work well.  But you lose a sort of 
>efficiency in allowing only simple hierarchical interactions.  If you're 
>lucky everything works fine.  If you're unlucky you get a system with 
>such poor performance that it isn't worth using even though it doesn't 
>do anything unexpected.
>
>When it works, one of the things that happens is that the interfaces 
>seem intuitive.  If they don't, then you'll drown in numbers of simple 
>interactions.  When it's simple components connected simply, you have 
>the possibility still to just get so many of them that you can't keep 
track.

It's not intuitive!  The interfaces are documented.  Anything that
doesn't follow the call gets an immediate error return.

>
>> The same thing applies to hardware.  It is easy to analyse and debug
>> race and other inconsistency conditions involving two entities.  As
>> networks grow in complexity, it becomes harder and harder.  There
>> comes a point (approaching, in some networks) where most failure
>> time (down time or debugging) is not associated with a problem in
>> ANY component, but is associated with the network structure itself.
>> TANSTAFFL.
>
>By analogy I'd say that you might need hierarchical networks where you 
>never get too many units interacting at once.  Then you at least have 
>the possibility to track down the problems.  But performance degrades 
>across the hierarchy even in the best case.  Still, what choice do you 
>have?  If the alternative is sacrificing a system administrator to the 
>network gods every full moon....

I don't understand.  We used to call it black box development.
Rather similar to a box in a flow chart.  If you are outside the
box, the only thing you need to know is what goes in or what comes
out and NOT what happens inside.  

The complexity of programming is that there exists nested black 
boxes.  If you keep going lower and lower and lower, you can
find yourself back in the electric generator at the power station
and then there are all those black boxes in the physics and wiring
areas.

The fun is arranging things so that a CATCH-22 becomes a nested
black box within itself.  That's a lot of fun. :-)

/BAH

Subtract a hundred and four for e-mail.

Nick Maclaren wrote:
> 
> |> Seems to me that modular programming, object orientation, or just
> |> languages with higher level constructs will resolve many of his
> |> concerns.  One doesn't design an airplane or bridge by writing down how
> |> to mine ore, smelt it, make bolts and rivets, roll sheet etc.
> 
> No, but they would push the limits further.  Instead of modern
> systems being bug-ridden and almost unusable heaps, debuggable
> only by calling in the dwindling number of people with really
> low-level hacking experience, they could be fairly robust and
> largely self-diagnosing.
> 
> We could be talking about a factor of 10 reduction in development
> effort and administrator effort, a factor of 100 reduction in
> visible problems, a factor of 100 increase in software MTBF in
> problem situations, coupled with a factor of 10 increase in size.
> There is plenty of margin :-(
> 
> There is no way to ELIMINATE the problems of complexity, however.
> 

Another part of the problem is people related also.  They need to stop
promoting programmers who are really good with dealing with complexity
to system designers.  It seems like a good idea but it's not.  Because
the last thing these system designers are going to do is design simpler
systems, level the playing field and give up a major advantage they
have over other programmers.

Joe Seigh

> " Aircraft carrier project--a naval project with 30 million parts (a
> submarine has only 8 million parts)."
> 
> Why would software be any harder?

Because people insist on designing it in a strongly-coupled way.

And even when designing as loosely-coupled hierarchical systems, airplanes
et al. develop surprising "emergent" interactions - some of which are hard
to solve even in principle. An example would be the Warzaw Airbus incident,
or even the Ariane 501 failure.

	Jan

In article <e5ordb.8u3.ln@acer>,
Morten Reistad <mrr@reistad.priv.no> writes:
|> >|> 
|> >|> " Aircraft carrier project--a naval project with 30 million parts (a
|> >|> submarine has only 8 million parts)."
|> >|> 
|> >|> Why would software be any harder?
|> 
|> Because there are more interactions.
|> 
|> A bolt holding a radar mast on an aircraft carrier does just that.  It
|> can be inspected, maintained and changed by a person knowing about
|> bolts and naval warship construction. [S]He does not have to know much
|> about radar systems.
|> 
|> A failure of this bolt will only lead to failure of one subsystem
|> (beside someone getting hit by a falling mast). 
|> 
|> Ditto for the whole radar subsystem. This can be assembled, tested and 
|> validated pretty much in isolation. 

While there is some truth in that, most of the independence is as
the result of careful design.  Let us take your bolt as an example.

The fitting is designed so that a failure of the bolt does not
cause the movement of the mast to degrade some other component.
It is also designed so that the bolt can be replaced without
having to dismantle the mast, let alone having to disable some
other component.  The bolt is designed so that its probability of
failure is related to the severity of the consequence of its
failure.  It is designed so that expected human error will not
cause the bolt to fail in use.  And so on.

This doesn't always work, but failure to achieve such targets is
regarded as a fault in the design.  This is not so in most modern
software.


Regards,
Nick Maclaren.

Nick Maclaren wrote:
> Robert Myers <rmyers@rustuck.com> writes:

> |> A paradigm already exists for scaling programs to arbitrarily large
> |> sizes.  It's called a network.

> Yeah, right.  I was having run-ins with the "structured programming"
> dogmatists back in the 1960s and 1970s on this one, and the common
> errors have not changed.

> By splitting programs into functions of at most 20 lines long (yes,
> seriously), you may be able to understand every function at a glance.
> You will not, however, be able to understand their interactions.  So
> you split the program into separate ones of at most 20 functions,
> and can now understand every program.  But you will not be able to
> understand the network of programs.  And so on.

The way I understand that dogma, you need first to have your small 
functions interact only across a known simple interface.  So the 
interaction of functions is known and simple, and you can ignore their 
details and look only at the inputs and outputs.  Then you make them 
interact using programs that are no more complicated than those first 
functions.  The high-level programs must also be short and simple and 
interact only through simple known interfaces.  And so on, hierarchically.

This approach can sometimes work well.  But you lose a sort of 
efficiency in allowing only simple hierarchical interactions.  If you're 
lucky everything works fine.  If you're unlucky you get a system with 
such poor performance that it isn't worth using even though it doesn't 
do anything unexpected.

When it works, one of the things that happens is that the interfaces 
seem intuitive.  If they don't, then you'll drown in numbers of simple 
interactions.  When it's simple components connected simply, you have 
the possibility still to just get so many of them that you can't keep track.

> The same thing applies to hardware.  It is easy to analyse and debug
> race and other inconsistency conditions involving two entities.  As
> networks grow in complexity, it becomes harder and harder.  There
> comes a point (approaching, in some networks) where most failure
> time (down time or debugging) is not associated with a problem in
> ANY component, but is associated with the network structure itself.
> TANSTAFFL.

By analogy I'd say that you might need hierarchical networks where you 
never get too many units interacting at once.  Then you at least have 
the possibility to track down the problems.  But performance degrades 
across the hierarchy even in the best case.  Still, what choice do you 
have?  If the alternative is sacrificing a system administrator to the 
network gods every full moon....

Morten Reistad wrote:
> Example : a stock accounting system. There are three hairy
> problems associated with these
>
> 1) Transactional integrity and security validable by any auditor.
> 2) Business logic of outlandish complexity.
> 3) Large transaction volumes with near realtime response demands.
>
> If done in a monolithic fashion complexity will explode.
>
> You need to separate 1 and 2 and make a little language for
> the business complexity, where the language itself guarantees
> 1 and has a shot at 3. I have never seen this done.

I'm not sure that there is much of a problem apart from 3. In all sorts of
accounting systems I know of 1 and 2 is solved by breaking the job into
little steps which are executed in turn.

Most people I know get into trouble when trying to automate accounting
calculations (e.g. for their tax returns). The problem is that they try to
do too much in one go. When I try to convince them that this is a problem
already solved, they refuse to belive me and insist that the accounting
stuff is really difficult. The interesting bit is that they seem to have no
problem doing the sums properly on their paper tax return forms.

greetings,

On 1 Jul 2003 07:24:41 GMT, nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>
>In article <2o12gvc6ishbpa20n8938rsae42s47vgbo@4ax.com>,
>Robert Myers <rmyers@rustuck.com> writes:
>|> 
>|> FWIW:
>|> 
>|> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
>|> 
>|> "a single domestic passenger airplane alone can contain as many as 6
>|> million parts"
>|> 
>|> http://www.majorprojects.org/pubdoc/677.pdf
>|> 
>|> " Aircraft carrier project--a naval project with 30 million parts (a
>|> submarine has only 8 million parts)."
>|> 
>|> Why would software be any harder?
>
>Because it is less well engineered.

If by less well engineered you mean that most software never goes
through a design, specification, and test process anything like
something built for the military or intended for civilian flight, I
agree with you, but there is nothing fundamental about software that
dictates that it be built that way.

>Also, do you know how many
>such military engineering systems have significant and even major
>components that are decommissioned before they are got to work in
>the field?
>

If you take a subscription to Aviation Week you can follow at least
some of the misadventures of aerospace engineering projects in real
time.

The American aerospace industry has been repeatedly belittled, at
least in the American press, as being this inept sinkhole for money.
Even a sympathetic insider, after having sat through just a few
interminable meetings, might wonder how anything ever gets done.

The reality is that the industry has acquired an astonishing mastery
of complexity and an ability to marshall heterogeneous resources from
the most unlikely places to bring about sometimes quite amazing
results.

For all its reputation for coverups, aerospace has been incredibly
unsuccessful in hiding its screwups.  The spectacular successes, on
the other hand, are often concealed from public view under pain of a
prison sentence.

>|> A paradigm already exists for scaling programs to arbitrarily large
>|> sizes.  It's called a network.
>
>Yeah, right.  I was having run-ins with the "structured programming"
>dogmatists back in the 1960s and 1970s on this one, and the common
>errors have not changed.
>
>By splitting programs into functions of at most 20 lines long (yes,
>seriously), you may be able to understand every function at a glance.
>You will not, however, be able to understand their interactions.  So
>you split the program into separate ones of at most 20 functions,
>and can now understand every program.  But you will not be able to
>understand the network of programs.  And so on.
>
>The same thing applies to hardware.  It is easy to analyse and debug
>race and other inconsistency conditions involving two entities.  As
>networks grow in complexity, it becomes harder and harder.  There
>comes a point (approaching, in some networks) where most failure
>time (down time or debugging) is not associated with a problem in
>ANY component, but is associated with the network structure itself.
>TANSTAFFL.

I believe in lots of things most other people don't, including magic
and free lunches.  The internet works.  Bank ATM networks work.  The
global financial system works.  The telephone system works.

Jan Vorbr�ggen <jvorbrueggen@mediasec.de> hit it dead on:

>> " Aircraft carrier project--a naval project with 30 million parts (a
>> submarine has only 8 million parts)."
>> 
>> Why would software be any harder?
>
>Because people insist on designing it in a strongly-coupled way.
>

If the eyes of students don't roll heavenward when they are presented
with a network stack, told how useful the concept is, and then watch
how actual software breaks the layering model right from the git-go,
they don't belong in engineering.

I deliberately did *not* choose some common term from software
engineering, like structured programming or object oriented
programming.

A network is such a powerful paradigm for software design because each
node has a finite number of ports.  Like an ancient walled city, all
information must come in or go out through the gates.  Each city is
governed separately.  Requests for information go out through a gate
(and can be logged completely if necessary) and responses go out
through a gate (and can be logged completely if necessary).  The
communication protocal is transparent and communication traffic can be
intercepted outside the city gates, so that no principality's word has
to be taken for it as to what it is saying to the other principalities
or what it is hearing from other principalities.

When the number of city-states becomes unmanageable, nations form.  If
their borders are porous, it is not intentional.  Defining actual
nations without randomly porous borders is impossible, but in the case
of software, it is not.  When nations become too large, you form
confederations of nations.  At every level of governance the rules are
the same: each principality manages its own internal affairs,
communicates with the outside world only through a finite number of
ports, and uses a communication protocol that can be intercepted an
deciphered by an authorized examiner of network traffic outside the
city walls.

By some no very great stretch of the imagination, the internet is just
one big program.  By a slightly smaller stretch of the imagination, my
humble intranet is a program, and a very complicated one, at that.  By
no stretch of the imagination at all, very complicated programs
designed, written, and supervised by independent parties can cooperate
over a far-flung network to perform a single a task in a way that is
no different from a "Hello, World" program.

As to "emergent behavior".  Yes, such things happen.  That's how
systems engineers stay employed. :-).

>
>Have you ever tried to report a problem to a large vendor that is
>due SOLELY to the underlying computational assumptions of three or
>more separately developed components being subtly incompatible?
>I have.  Guess how far I got.
>

When an aerospace contractor buys anything other than services, there
is a specification.  There are even specifications for specifications.
All questions of culpability for subcontractors come down to one
question: did the subcontractor deliver parts that meet the agreed to
specification, or not.  The general contractor is responsible for
selecting and coordinating subcontractors in such a way that the
overall system works.  If all subcontractors have delivered according
to spec, it is the general contractors' job to fix it.  That's why
they get the big bucks.

If you've bought software and/or hardware from a general contractor,
you almost certainly bought a support contract with it.  If your
vendor isn't meeting the terms of the support contract and you are
having a hard time enforcing them, you have my sympathy, with no trace
of sarcasm.  Huge companies in this business have survived very hard
times by going to great lengths to avoid leaving their customers
feeling that way.

RM

In article <9h13gvs2ac1mh3tldtkacneml84v7150iu@4ax.com>,
Robert Myers <rmyers@rustuck.com> writes:
|> 
|> If by less well engineered you mean that most software never goes
|> through a design, specification, and test process anything like
|> something built for the military or intended for civilian flight, I
|> agree with you, but there is nothing fundamental about software that
|> dictates that it be built that way.

Precisely.  I agree with you completely.

|> If you take a subscription to Aviation Week you can follow at least
|> some of the misadventures of aerospace engineering projects in real
|> time.
|> 
|> The American aerospace industry has been repeatedly belittled, at
|> least in the American press, as being this inept sinkhole for money.
|> Even a sympathetic insider, after having sat through just a few
|> interminable meetings, might wonder how anything ever gets done.

Why single the Americans out?  I thought that was generally true :-)

|> The reality is that the industry has acquired an astonishing mastery
|> of complexity and an ability to marshall heterogeneous resources from
|> the most unlikely places to bring about sometimes quite amazing
|> results.

Yes.  I am amazed at how well it does.

|> For all its reputation for coverups, aerospace has been incredibly
|> unsuccessful in hiding its screwups.  The spectacular successes, on
|> the other hand, are often concealed from public view under pain of a
|> prison sentence.

Nice one!

|> If you've bought software and/or hardware from a general contractor,
|> you almost certainly bought a support contract with it.  If your
|> vendor isn't meeting the terms of the support contract and you are
|> having a hard time enforcing them, you have my sympathy, with no trace
|> of sarcasm.  Huge companies in this business have survived very hard
|> times by going to great lengths to avoid leaving their customers
|> feeling that way.

It is actually the problem that there is no definition of whether
software works or not.  At any level :-(

You might be surprised at how few software vendors have a reputation
for honouring the spirit (or even the letter) of their contracts.
The real question is how badly they let you down.  Their problem is
that, IF they took every little bug and other fault seriously, they
would go broke.


Regards,
Nick Maclaren.

Morten Reistad <mrr@reistad.priv.no> wrote in news:e5ordb.8u3.ln@acer:
> A bolt holding a radar mast on an aircraft carrier does just that.  It
> can be inspected, maintained and changed by a person knowing about
> bolts and naval warship construction. [S]He does not have to know much
> about radar systems.
> 
> A failure of this bolt will only lead to failure of one subsystem
> (beside someone getting hit by a falling mast). 
> 
> Ditto for the whole radar subsystem. This can be assembled, tested and 
> validated pretty much in isolation. 

Completely false in all respects, because of the 
"rusty bolt" problem!

Theory: rusty bolts act as crude semiconductors, and rectify 
any EM radiation falling on them. The result of rectification,
as any radio engineer knows, is that the bolt generates and 
re-radiates harmonics and subharmonics of the incident radiation.
In other words, energy gets splatted indiscriminately across 
the radio spectrum. The consequence is that it is very 
difficult to predict  which combination of systems will work
together, and which will interfere; you have to suck it and see.

Practice: HMS Sheffield was sunk because its long-range radar 
had been turned off in order to allow satellite communications;
thus missing the Exocet coming down its throat.

Jan C. Vorbr�ggen <jvorbrueggen@mediasec.de> writes:
> Known? It was ignored when a terminal at D�sseldorf airport was
> built, which lead to the death of 17 (IIRC) people. When I first
> read the account in the paper, I couldn't believe it.

is it my imagination or were terminals at dusseldorf and dresden
done by the some architect?

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ 
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

> is it my imagination or were terminals at dusseldorf and dresden
> done by the some architect?

I couldn't say. The bug was in the low-level code, as it were, which is
not the usual level for architects to work at. And the implementors violated
all agreed-upon rules of the art in so doing, of course. 

So what else is new.

	Jan

Robert Myers <rmyers@rustuck.com> writes:

> If by less well engineered you mean that most software never goes
> through a design, specification, and test process anything like
> something built for the military or intended for civilian flight, I
> agree with you, but there is nothing fundamental about software that
> dictates that it be built that way.

I concur that there's nothing fundamental that dictates that it must
be built that way, but I think it's part of the intangible nature of
software that leads to being built that way.

When you build an airplane, the later you decide to change things, the
more it costs.  Change it on paper, and it might cost you a man-month.
Change it after the first prototypes are built, and it might cost you
10 man-years.  Fail to test it adequately, and the results will be
obvious.  Software, being intangible, isn't perceived as having this
problem.  (This is why, when a user says to me, "It will never need to
do X," I clarify that we share an understanding of 'never', and I get
the statement in writing anyway, because it's been my experience that
'never' means 'for the next three to five months' when used in that
construction.)

The need for stable design and rigorous testing is apparent to PHBs
for a number of reasons: for one thing, the airplane is *tangible*,
and the PHB can see just how a small change can ripple through the
whole design.  Another thing is regulation: designs must be approved
by certified people and must meet certain standards.  There's also
legal liability; most software systems disclaim as much liability as
possible.  Thus it's apparent to the PHB that clear specifications are
more important than wiggle room.

In software, that's not often the case.  A PHB who commits to a
certain set of specifications will be responsible if that certain set
of specifications doesn't get the job done, and so there's a good
reason for not conforming to specifications -- leave it to the
programmers to work out, and if the software system doesn't do what it
needs, it will be the programmers' fault.  With any luck, there won't
even be any blame assigned for it, or at least none that sticks; just
a lot of frustrated programmers and a PHB who's looking for the next
project to kill.

Charlton

On Tue, 01 Jul 2003 11:55:20 -0400, Paul Wallich <pw@panix.com> wrote:

>
>Those counts for aircraft, submarines and such aren't really comparable, 
>because  although there are zillions of pieces, the vast majority of 
>them are instantiations of a much smaller number of masters. Counting 
>that way is like counting lines of code after inlining all of your 
>calls. Where you do have oodles of different part types, physical 
>designs benefit from the continuous nature of physical properties (each 
>one isn't an entirely new problem) and from the fact that you usually 
>can't put the wrong components together (think of bolt sizes and 
>connector layouts as strong typing).
>
>One famous case of a complex physical design going horribly wrong was 
>the Hartford Civic Center roof, a space frame built from hundreds of 
>thousands of apparently identical components. It turned out that some of 
>the rods and connectors were made of high-strength steel and intended to 
>  go in particular areas of stress concentration, but that the workers 
>had not heeded the fine print of which identical-looking part to put 
>where. As a result, loads followed paths that weren't designed to 
>sustain them, and the whole thing fell down.
>

Why would you imagine that aerospace systems would be immune to such
problems?

Example of one "part":

"The type of jackscrew assembly involved in the accident was
originally designed by Douglas Aircraft in 1965 for the DC-9. It
weighs 100 pounds, is two inches in diameter, and costs $60,000." 

Excessive (thousandths of an inch) wear to the threads of the part in
question was determined to be the probable cause of an Alaska Airlines
flight nosediving into the Pacific.

On balance, I think the parts count analogy for aerospace systems is
conservative.

Whether that is true or not, the point is that, whether the software
industry has adopted the methodologies or not, successful
methodologies exist and have been demonstrated successfully for
managing mind-bending levels of complexity, and I see no reason to
place an upper bound on the level of complexity that can be managed
for any kind of engineering system, including software.

RM

On Tue, 1 Jul 2003, Paul Wallich wrote:

> them are instantiations of a much smaller number of masters. Counting
> that way is like counting lines of code after inlining all of your
> calls.

Precisely.  Maybe Nick will read it this time.

-Peter

In article <bdc3gv4hk1tmi6graq3l3tepl8ssaj9n60@4ax.com>,
Robert Myers <rmyers@rustuck.com> writes:
|> 
|> Whether that is true or not, the point is that, whether the software
|> industry has adopted the methodologies or not, successful
|> methodologies exist and have been demonstrated successfully for
|> managing mind-bending levels of complexity, and I see no reason to
|> place an upper bound on the level of complexity that can be managed
|> for any kind of engineering system, including software.

What is abundantly clear, however, is that complexity increases
cost and delay.  Good methodology helps to reduce this but, for
any fixed methodology, there is sooner or later a vast increase
in cost and delay caused by complexity.  One can argue whether
it is exponential or not, but it is often close to it.

So, while there may not be a theoretical upper bound, there most
definitely is a practical one.  We don't know of a methodology
for handling systems a hundred times more complex than a modern
jumbo jet, for example.  Yet building software is cheap enough
that such products can be contemplated - and are.


Regards,
Nick Maclaren.

Robert Myers wrote:

> Whether that is true or not, the point is that, whether the software
> industry has adopted the methodologies or not, successful
> methodologies exist and have been demonstrated successfully for
> managing mind-bending levels of complexity, and I see no reason to
> place an upper bound on the level of complexity that can be managed
> for any kind of engineering system, including software.

How long does it take to design a new airplane?  How much change from 
the last design?

Maybe the time-to-market is part of the problem?  If we were only 
willing to wait 4 years for a well-designed application for Win2000, 
we'd get well-designed applications for Win2000.  In fact we could have 
had some well-designed apps for Win98 by sometime last year, and 
well-designed apps for Win95 by 1999.

But then, why should apps be forced to run on too-new, poorly-designed 
OSs?  Surely a complicated OS shouldn't be allowed out the door for at 
least 8 years, after say 3 years in beta testing and maybe an extra 5 
years of redesign.

The central problem is maybe that having a lot of errors is usually 
acceptable in software.  It isn't like planes falling out of the sky. 
You just shrug and reboot.

Short of liability lawsuits from the relatives of defunct customers, 
perhaps we could get much better reliability if, after the beta testing 
is done, we went through about a year's worth of gamma testing in which 
any error is likely to kill the top management of the company.  It would 
make for great TV commercials, kind of like the Maytag ones.  The calm, 
collected company president sitting at his desk with a piano suspended 
over him.  He contentedly works away.  Every now and then he looks up 
and looks kind of thoughtful.  "I'm not worried.  Our product is 100% 
reliable.  I'd stake my life on it."

Maybe there wouldn't be quite so much schedule pressure if it was done 
like that.

On Tue, 01 Jul 03 08:28:57 GMT, jmfbahciv@aol.com <jmfbahciv@aol.com> wrote:
>
>On a plane one day, I sat next to a guy who owned a company who
>made just airplane wings.  He told me it took 9 months to make one.
>That gives just a hint about complexity.

A friend of mine makes Airbus wings just a few miles from here, and they
do take months to make - even with their sophisticated computer controlled
machinery.  (They machine the skin, with integral stiffening ribs, from a 
*huge* flat billet of aluminum!)  
They fly them out in the fattest plane you've ever seen...

-- 
Cheers,
Stan Barr     stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)

The future was never like this!

nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in message news:<bdre26$56m$1@pegasus.csx.cam.ac.uk>...
> In article <Pine.LNX.4.55.0307010926370.12021@ask.diku.dk>,
> "Peter \"Firefly\" Lund" <firefly@diku.dk> writes:
> |> On Tue, 1 Jul 2003, Nick Maclaren wrote:
> |> 
> |> > |> Why would software be any harder?
> |> >
> |> > Because it is less well engineered.  Also, do you know how many
> |> 
> |> No.  Because you don't have high-level screws.  10 million lines of mostly
> |> flat-line code broken into pieces that interact very little with each
> |> other would be a lot easier to understand than 10 million typical lines.
> 
> I suggest learning a little more about the design of such systems.
> Your point is correct, but your viewpoint of their problems is
> overly simplistic.
> 
> |> It would also be even easier if we did apply the engineering we know and
> |> cut it down to say 5 or 10 thousand lines (probably less).
> 
> I know of no such example.  If you have ever tried to write a
> serious product and keep it down to that size, you will have found
> out that only some of the bloat is due to engineering incompetence.
> Rather more is due to interfaces being designed non-mathematically,
> but there is a large residue of special cases, messy situations and
> so on that can't be handled compactly.
> 
> Factors of 10 reduction are often possible; factors of 100, perhaps.

Largish complex systems often rely on tools such as table look-up to
reduce the amount of C code and maximize the ability for at least the
tables to be machine-checked for consistency.  This is really shifting
the solution domain from "C code" (or whatever general-purpose
computing language they use that week) to writing down the tables.

> I do not believe factors of 1,000 and more, as you are claiming.

I've seen some extreme cases of a factor of 1000, but in those cases
they were *only* counting lines of C code and ignoring library calls
and the complexity of the tables, even ignoring the tools used to
build the tables.  i.e. they were cheating.

MLOC's (Millions of Lines of Code) are one way to measure system complexity
but certainly not the best one!

Tim.

Robert Myers wrote:

> On Tue, 01 Jul 2003 11:55:20 -0400, Paul Wallich <pw@panix.com> wrote:
> 
> 
>>Those counts for aircraft, submarines and such aren't really comparable, 
>>because  although there are zillions of pieces, the vast majority of 
>>them are instantiations of a much smaller number of masters. Counting 
>>that way is like counting lines of code after inlining all of your 
>>calls. Where you do have oodles of different part types, physical 
>>designs benefit from the continuous nature of physical properties (each 
>>one isn't an entirely new problem) and from the fact that you usually 
>>can't put the wrong components together (think of bolt sizes and 
>>connector layouts as strong typing).
>>
>>One famous case of a complex physical design going horribly wrong was 
>>the Hartford Civic Center roof, a space frame built from hundreds of 
>>thousands of apparently identical components. It turned out that some of 
>>the rods and connectors were made of high-strength steel and intended to 
>> go in particular areas of stress concentration, but that the workers 
>>had not heeded the fine print of which identical-looking part to put 
>>where. As a result, loads followed paths that weren't designed to 
>>sustain them, and the whole thing fell down.
>>
> 
> 
> Why would you imagine that aerospace systems would be immune to such
> problems?
> 
> Example of one "part":
> 
> "The type of jackscrew assembly involved in the accident was
> originally designed by Douglas Aircraft in 1965 for the DC-9. It
> weighs 100 pounds, is two inches in diameter, and costs $60,000." 

Nope, that's not a part. It's an assembly. Consists of a bunch of parts 
put together.

> Excessive (thousandths of an inch) wear to the threads of the part in
> question was determined to be the probable cause of an Alaska Airlines
> flight nosediving into the Pacific.

Although thousandths of an inch may sound tiny and hard to detect, 
anyone who has worked with mechanical systems will tell you that that 
kind of margin is enormous for things like screw threads. An 
undergraduate physics student in his first or second session in front of 
a toolroom lathe can machine parts to a tolerance of a few thousandths 
of an inch.

> On balance, I think the parts count analogy for aerospace systems is
> conservative.

Note also that addendum: originally designed almost 40 years ago for a 
completely different aircraft, and still in service. How many 
40-year-old code modules are still in daily use?

And more to the point, for any that are, does a central authority have 
the phone number of every person using them, so that they can be 
notified by day's end if a bug is found?

> Whether that is true or not, the point is that, whether the software
> industry has adopted the methodologies or not, successful
> methodologies exist and have been demonstrated successfully for
> managing mind-bending levels of complexity, and I see no reason to
> place an upper bound on the level of complexity that can be managed
> for any kind of engineering system, including software.

As someone else pointed out, We don't really seem to be willing to pay 
the price, either in time or money, that it would cost to implement such 
a system. And the IT industry fights tooth and nail against any efforts 
to impose the kind of liability incentives that are standard for more 
rigorous forms of engineering.

In my limited experience, the larger a cohesive project you get, the 
further behind best practices it falls, perhaps because of the amount of 
effort that needs to be put into managing just the simplest parts of the 
complexity, like making sure all those thousands of programmers get paid.

paul

In alt.folklore.computers Stan Barr <stanb45@dial.pipex.com> wrote:
> A friend of mine makes Airbus wings just a few miles from here, and they
> do take months to make - even with their sophisticated computer controlled
> machinery.  (They machine the skin, with integral stiffening ribs, from a 
> *huge* flat billet of aluminum!)  
> They fly them out in the fattest plane you've ever seen...

The Guppy? Incredible thing - I've seen it somewhere near Manchester -
heading for Broughton?

Isn't there an Airbus-based replacement for the Guppy on the way?

pete
-- 
pete@fenelon.com "there's no room for enigmas in built-up areas" HMHB

Robert Myers wrote:
> 
> FWIW:
> 
> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
> 
> "a single domestic passenger airplane alone can contain as many as 6
> million parts"

5,900,000 of which are rivets ?

> 
> http://www.majorprojects.org/pubdoc/677.pdf
> 
> " Aircraft carrier project--a naval project with 30 million parts (a
> submarine has only 8 million parts)."
> 
> Why would software be any harder?
> 
> A paradigm already exists for scaling programs to arbitrarily large
> sizes.  It's called a network.
> 
> RM
> 

In article <bdru9p$kcj$1@pegasus.csx.cam.ac.uk>,
Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
> The fitting is designed so that a failure of the bolt does not
> cause the movement of the mast to degrade some other component.
> It is also designed so that the bolt can be replaced without
> having to dismantle the mast, let alone having to disable some
> other component.  The bolt is designed so that its probability of
> failure is related to the severity of the consequence of its
> failure.  It is designed so that expected human error will not
> cause the bolt to fail in use.  And so on.

Ah yes, another point.

Each component in a software system has to be measured against all the
*kinds* of components in a hardware system. In fact when you have very
meny components in a software system doing the same job (the 'screws')
then either they're actually custom parts (drivers, or all the individually
shaped tiles on the Space Shuttle), or a design flaw (programmers A, B,
and C all wrote their own memory manager).

So in the software system, there isn't any analog to "the bolt", there's
"all the bolts of this type", and if you need to change them you need to
make sure that change doesn't change any of the places that bolt is used.

This also means that a 10 million line software system is probably more
complex than the 30 million component aircraft carrier.

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

Peter da Silva wrote:

> The real issue is getting people to do this in a world where someone
> can honestly claim that a web browser is an integral part of an operating
> system without being shipped off to the funny farm.

Do we have a world where someone can honestly claim that a web browser 
is an integral part of an operating system?

In article <3F01D82E.7060907@cavtel.net>,
jonah thomas  <j2thomas@cavtel.net> wrote:
> Peter da Silva wrote:
> > The real issue is getting people to do this in a world where someone
> > can honestly claim that a web browser is an integral part of an operating
> > system without being shipped off to the funny farm.

> Do we have a world where someone can honestly claim that a web browser 
> is an integral part of an operating system?

Five years of lawsuits over that and Microsoft still has the essential
components of Internet Explorer embedded like a tumor in Windows, because
they convinced enough people that it was essential that it be there.

Whether they were honest about it, there are enough people who believe them
that I have to say we live in that world.

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

Peter da Silva wrote:
> This also means that a 10 million line software system is probably more
> complex than the 30 million component aircraft carrier.
> 

Do large-scale mechanical designers have a tool available to them
that would be analogous to a programming language compiler?

That is, a mechanized way to generate an optimized "nuts and bolts" 
assembly from a higher-level specification?

According to Pete Fenelon  <pete@fenelon.com>:
> The Guppy? Incredible thing - I've seen it somewhere near Manchester -
> heading for Broughton?
> 
> Isn't there an Airbus-based replacement for the Guppy on the way?

A funny thing flew over Oxford today: looked a bit like a Hercules,
only with four jet engines, and painted the usual military grey.  No
idea what it was, though, but it was flying bloody low.

Chris.
-- 
"If the world was an orange it would be like much too small, y'know?" Neil, '84
  Currently playing: random early '80s radio stuff
  http://www.chrishedley.com - assorted stuff, inc my genealogy.     Gan canny!

Larry__Weiss wrote:
> Peter da Silva wrote:

>>This also means that a 10 million line software system is probably more
>>complex than the 30 million component aircraft carrier.

> Do large-scale mechanical designers have a tool available to them
> that would be analogous to a programming language compiler?

> That is, a mechanized way to generate an optimized "nuts and bolts" 
> assembly from a higher-level specification?

Not usually.  What they have is lists of standard parts with known 
properties.  The goal is to find ways to use the standard parts so they 
work right.

Programmers would have something like that if they had serious code 
re-use.  But it's a different kind of system.

If you form custom aluminum parts and you then rivet them together, 
there's a question what kind of rivets to use and how close to space 
them and a few things like that.  You have standard parts with a new 
part that they fit into.  The new part is like a glue that sticks 
together the standard parts.  I think there's a fundamental difference 
between an automobile chassis and a standard headlight you can put on 
it.  But I'm having trouble defining the difference.  Somehow I think 
there's more difference between the standard parts and the "glue" parts 
in mechanical systems than there is in code.  But I don't know how to 
say what the difference is.

Robert Myers <rmyers@rustuck.com> wrote:
> FWIW:
> 
> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
> 
> "a single domestic passenger airplane alone can contain as many as 6
> million parts"
> 
> http://www.majorprojects.org/pubdoc/677.pdf
> 
> " Aircraft carrier project--a naval project with 30 million parts (a
> submarine has only 8 million parts)."
> 
> Why would software be any harder?
> 

Two reasons:

First, in a physical device, interactions between parts are usually
limited by location (each part only affects other, nearby, parts)
whereas in software, every line of code can affect ANY piece of the
program state. This means that, in general, physical systems have a
complexity that is something like N**k (N = number of parts, k = some
degree of local interaction, N>>k) while software has a complexity
much closer to N**N (every part has potential interaction with every
other part).

Second, humans have a much more experience managing the construction
of large mechanical systems than with constructing large information
systems. Management, as a science, is based, almost entirely, on vast
amounts of empiracle data: We just don't have enough of it, yet, to
know what we are doing as Software Engineers. Other disciplines of
engineering, on the other hand, have much larger and older bodies of
knowledge to draw upon.

- Jeff Dutky

In article <3F01DAEE.56856D50@airmail.net>,
Larry__Weiss  <lfw@airmail.net> wrote:
> Peter da Silva wrote:
> > This also means that a 10 million line software system is probably more
> > complex than the 30 million component aircraft carrier.

> Do large-scale mechanical designers have a tool available to them
> that would be analogous to a programming language compiler?

Sure. Lots of them.

> That is, a mechanized way to generate an optimized "nuts and bolts" 
> assembly from a higher-level specification?

Um, no, that's not the analog of a compiler. A compiler is like Autocad and
plotters and numerically controlled machines.

The source code you feed into the compiler... *that* is the "nuts and bolts"
assembly already.

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

In article <aN6Ma.1222$IP6.53730@eagle.america.net>,
del cecchi <dcecchi@msn.com> wrote:
>> "H. E. Taylor" <het@despam.autobahn.mb.ca> wrote in message
>> news:3F00F29A.43B@despam.autobahn.mb.ca...
>> >     One of the books I have been reading lately is "The Next
>> >     Fifty Years, Science in the First Half of the 21st Century".
>> >     It is a collection of essays by 25 third party experts.
>> >     One of the them is by Jaron Lanier. His essay is about
>> >     complexity.  
>> >
>> > If we don't find a different way
>> > of thinking about and creating software, we will not be writing
>> > programs bigger than about 10 million lines of code, no matter
>> > matter how fast, plentiful or exotic our processors become."
>> > -Jaron Lanier  (The Next Fifty Years, page 219)
>>
>Depends on what you mean by "program".  How many lines of code in
>MVS/OS390?  OS400 including SLIC?  Windows XP?  Word XP?  Unix?  Oracle?
>DB2?

Actually, he just gave a talk on that subject (May before I went on
vacation, you can find the abstract in a.f.c. on google).
It's hard to summarize what he said, so I was thinking of inviting
him to work and having them do all the seminar arranging stuff.


>Who is this John Lanier guy?  Somebody I should have heard of?

Jaron is a character.
He's more in the human interface, virtual reality (VPL glove),
graphics crowd than in high end computing (but he has sat on serious
HPCC committees).

Should you have heard of him?  I dunno.
Jaron used to be a pretty serious coder in some ways,
not so batch oriented, much more interface interactive programmming.

>Seems to me that modular programming, object orientation, or just
>languages with higher level constructs will resolve many of his
>concerns.  One doesn't design an airplane or bridge by writing down how
>to mine ore, smelt it, make bolts and rivets, roll sheet etc.

I think a better analysis of the types of complexity would be better.
I've never been a fan of line of code as a metric.  There are instances,
Szilard and the bomb, and the SR-71, where knowing basic materials like
stuff while seemingly trivial made critical differences in the final
product (boron used in making graphite and distilled not tap water used
in finishing and cleaning Ti).  And I'd guess there were similar Cray
stories.

jonah thomas wrote:
> Peter da Silva wrote:
> 
>> The real issue is getting people to do this in a world where someone
>> can honestly claim that a web browser is an integral part of an operating
>> system without being shipped off to the funny farm.
> 
> 
> Do we have a world where someone can honestly claim that a web browser 
> is an integral part of an operating system?
> 

Peter might have meant
"where someone can successfully claim..."

JKA

In comp.arch J Ahlstrom <jahlstro@cisco.com> wrote:
> 
> 
> Robert Myers wrote:
>> 
>> FWIW:
>> 
>> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
>> 
>> "a single domestic passenger airplane alone can contain as many as 6
>> million parts"
> 
> 5,900,000 of which are rivets ?
> 

And really - if somebody wants to compare the number of components in an 
airplane to software, they should compare parts to opcodes. 

-- 
	Sander

+++ Out of cheese error +++

<snip>

I beleive that the basic idea is ti manage complexity, and isolate it as much as
possible. The main advantage that we have with software is that if it is built
correctly, the peices can be tested much earlier than the finished product. Most
of the complexity that I see everyday is in interaction between systems (
systems, components, programs, subprograms, etc.), and these can be mitigated by
identifying as early as possible these critical interactions. Thus, the earlier
in the implementatinos that integration can be applied can help expose
errors/incompatabilites in the design. Each peice can the be thought of as that
black box that everyone wants to acheive.

The problems I have seen is that the PHBs do not want the time spent in putting
together these early systems (that takes time, which we all know is money), and
rather want tangible results (we have sucessfully coded x% of the project...
earned value and all that). They want the full engineering perfomed up front,
instead of abstracting the system, doing the early integration, finding the
problems early (whrn it is less costly to fix by the way) and then going on to
the next level (yes I am a "fan" of spiral development).

Thanks
Joe, NY

eugene@cse.ucsc.edu (Eugene Miya) writes:
> I think a better analysis of the types of complexity would be better.
> I've never been a fan of line of code as a metric.  There are instances,
> Szilard and the bomb, and the SR-71, where knowing basic materials like
> stuff while seemingly trivial made critical differences in the final
> product (boron used in making graphite and distilled not tap water used
> in finishing and cleaning Ti).  And I'd guess there were similar Cray
> stories.

K.I.S.S.

there are also all the boyd stories about the f15, f16, etc ... trying
to get it right .... and then there is the air force air-to-air
missile when some really bright people miss a very simple point
.... what is the hottest part of a jet? misc.
http://www.garlic.com/~lynn/subboyd.html#boyd

specific:
http://www.garlic.com/~lynn/99.html#120 atomic History
http://www.garlic.com/~lynn/2003j.html#13 A Dark Day



-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ 
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

On Tue, 01 Jul 2003 11:12:28 -0700, J Ahlstrom <jahlstro@cisco.com>
wrote:

>
>
>Robert Myers wrote:
>> 
>> FWIW:
>> 
>> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
>> 
>> "a single domestic passenger airplane alone can contain as many as 6
>> million parts"
>
>5,900,000 of which are rivets ?
>

Estimating the surface area of a Boeing 747 to be about 30,000 square
feet, that would allow for about 200 rivets per square foot of surface
area.  Even with one foot square surface panels, rivets one inch on
center would only give 25 rivets per square foot.  That's the best my
envelope can do at this time of night.

RM

On Tue, 01 Jul 2003 12:48:58 -0400
Robert Myers <rmyers@rustuck.com> wrote:

RM> Whether that is true or not, the point is that, whether the software
RM> industry has adopted the methodologies or not, successful
RM> methodologies exist and have been demonstrated successfully for
RM> managing mind-bending levels of complexity, and I see no reason to
RM> place an upper bound on the level of complexity that can be managed
RM> for any kind of engineering system, including software.

	Unfortunately these methodologies are expensive to implement
and best suited to systems for which there is a great deal of prior
experience. As several people have observed the problems that occur when
operating outside that experience are remarkably similar to those
experienced in software. Software developers spend a lot of time
developing beyond the areas where there is a lot of experience. Worse
most approved methodologies encourage throwing the experience away at the
start.

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

On Tue, 01 Jul 2003 18:04:09 -0000, Pete Fenelon <pete@fenelon.com> wrote:
>
>Isn't there an Airbus-based replacement for the Guppy on the way?

I believe so, but I've not seen it yet.

-- 
Cheers,
Stan Barr     stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)

The future was never like this!

On 1 Jul 2003 14:34:00 -0800, eugene@cse.ucsc.edu (Eugene Miya) wrote:

>>
>>FWIW:
>>
>>http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
>>
>>"a single domestic passenger airplane alone can contain as many as 6
>>million parts"
>
>What is it worth?
>Are you attempting to equate a line of code to a plane part?
>
>>http://www.majorprojects.org/pubdoc/677.pdf
>>
>>" Aircraft carrier project--a naval project with 30 million parts (a
>>submarine has only 8 million parts)."
>
>Are you attempting to equate a line of code to ship parts?
>

I have written or supervised the writing of complicated software to
simulate or to analyze complicated aerospace hardware, so the
comparison seems natural to me.  I introduced it because I have been
truly impressed by the ability of large aerospace organizations (full
disclosure: my customers, not my employers) to cope with complexity.
If the comparison seems inappropriate or forced to you, feel free to
find another, but from what little I know of your background, I am
surprised that the comparison would not seem natural to you.

>>Why would software be any harder?
>
>I can think of a number of reasons, likely some enumerated by other
>follow ups.  One would get into the vague issues of natural language.
>You can start with Brooks.
>

Maybe it's just that it's the end of a long day.  Maybe it is that I
got so many pugilistic responses to what seemed like a fairly benign
comparison (truth be told, I think I touched a nerve).  Whatever the
reason, Brooks' article strikes me as a lame laundry list of
techniques with no real unifying insight as to the problem he claims
to be addressing.  I'll try reading it again tomorrow.

I have said in another thread recently, and I will say it again, that,
when it comes to understanding of algorithms, we are like children.  I
am therefore naturally suspicious of articles that attempt to draw
general conclusions about methods of describing algorithms via
software, since I don't know how you can draw conclusions about
methods of describing what you don't fully understand to begin with.

>>A paradigm already exists for scaling programs to arbitrarily large
>>sizes.  It's called a network.
>
>Huh?  What kind of network?

I responded to the same question posed by Nick Maclaren in some detail
in this thread.

What I described is a message-passing paradigm for stitching together
software that is common in clusters but I don't think is used for
routine programming.  I also gave a reasonably clear description of
why I think the model is, to all appearances, indefinitely
extensible.

As I said in responding to Nick, I think Jan C. Vorbr�ggen got it
exactly right when he said that what is different about software is
that it is written in a strongly-coupled way.  A message-passing
paradigm is one way of strictly limiting the coupling and allowing for
complete monitoring of the interactions between separate program
modules.

Notice, please, that I am not proposing a message-passing paradigm for
all programming.  I am proposing it as a way of coping with extremely
complex systems.  

>Did Forrest cover the address space greater
>than 32-bits thread in comp.arch a while back?

The fact that the curve began with "Now that The Forrest Curve has
become obviously true..." was more than a little off-putting to me,
since I take the Forrest Curve about as seriously as I took the
article entitled "IT Doesn't Matter" in the Harvard Business Review.
Both discussions might as well have started with "Let's suppose that
no one will ever think of entirely new ways of using computers."

In any case, the thread has no particular relevance to the argument I
made in responding to Nick, because the 32-bit thread dealt with
programs on a single machine, and I take the very broad view that if
two programs can talk to each other, they might as well be a single
program.

RM

On Tue, 01 Jul 2003 21:59:02 +0200
Toon Moene <toon@moene.indiv.nluug.nl> wrote:

TM> Peter da Silva wrote:
TM> 
TM> > In article <2o12gvc6ishbpa20n8938rsae42s47vgbo@4ax.com>,
TM> > Robert Myers  <rmyers@rustuck.com> wrote:
TM> 
TM> >>Why would software be any harder?
TM> 
TM> > Why would software be any easier? 10 million lines of code puts a
TM> > program somewhere between a 747 and the Enterprise.
TM> 
TM> Isn't that the fundamental answer ?  If you commission a 10**7 million
TM> line software project, the resulting product should have approximately
TM> the same cost as a 747.

	After making due allowances for the expense of obtaining, storing
and handling with suitable precision all that metal and plastic etc.
About the same cost in terms of time and skull sweat seems appropriate.

	Testing is a bit cheaper too :)

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

> Where you do have oodles of different part types, physical designs benefit
> from the continuous nature of physical properties (each one isn't an
> entirely new problem) 

I agree with the premise - benefit from the continuous nature - but the 
reason this helps, IMO, is that such systems aren't "brittle" in their
behaviour, meaning that a small change in the input usually means a small
change in the output. While there are examples where this isn't true (e.g.,
crossing a phase transition), brittleness is the usual behaviour of software:
even of defensively coded software, not to speak of the usual stuff.

> and from the fact that you usually can't put the wrong components together
> (think of bolt sizes and connector layouts as strong typing).

....which, however, still needs design to work - asymmetric connectors, for
instance, and you'd better not mix metric and non-metric bolts and tools,
because there are some common sizes that _almost_ fit.

	Jan

> > "a single domestic passenger airplane alone can contain as many as 6
> > million parts"
> 5,900,000 of which are rivets ?

No, those are at most a few hundred thousand. If I remember the number from
the film showing how an A320 is being built correctly, they said 145,000.

But even counting parts isn't easy. Is every stringer a part?

	Jan

> There are instances, Szilard and the bomb, and the SR-71, where knowing
> basic materials like stuff while seemingly trivial made critical 
> differences in the final product (boron used in making graphite and
> distilled not tap water used in finishing and cleaning Ti).  And I'd 
> guess there were similar Cray stories.

Asimov also wrote a nice little story, based on a society where knowledge
and expertise is extremely fractioned and specialised (so that nobody has
the holistic view, and the different "experts" do not allow themselves to
critique their colleagues from a different field) and the biological
properties of Beryllium.

	Jan

> Second, humans have a much more experience managing the construction
> of large mechanical systems than with constructing large information
> systems. Management, as a science, is based, almost entirely, on vast
> amounts of empiracle data: We just don't have enough of it, yet, to
> know what we are doing as Software Engineers. Other disciplines of
> engineering, on the other hand, have much larger and older bodies of
> knowledge to draw upon.

While the relative "more" is surely true, I do believe we have "enough" of
it: Once in a while a serious software project does comes through on schedule
and on (or even under) budget, a recent example (as far as I can tell from
the news) being the system running the London Congestion Charge - in a 
country that has probably the most horrible record of large public software
projects being scrapped after wasting hundreds of millions. However, there
is no accepted "state of the art" to software project management that is
routinely applied, and that indeed the project's customer demands to be used.

	Jan

In article <BmeJLUA5ceA$Ewmr@mooremusic.org.uk>, Ken Moore <ken@i12.com> writes:
|> In article <Xns93AB9CF857F46gardnertlogicacom@158.234.29.254>, Tom
|> Gardner <gardnertSPAM@TRAPlogica.com> writes
|> >Practice: HMS Sheffield was sunk because its long-range radar 
|> >had been turned off in order to allow satellite communications;
|> >thus missing the Exocet coming down its throat.
|> 
|> That's why it was hit.  The hit killed people and made a large hole, but
|> it didn't sink Sheffield immediately.  It would probably have survived
|> if the cable insulation had not been flammable, or if the bulkhead
|> transitions had had some sort of flame trap.

While it is off-topic, the analogy is relevant.

When that occurred, I remembered the problem arising in some of the
first high-rise blocks that were built with communications ducts.
Lift shafts were protected against fire (by law), but people had
forgotten the ducts.  That was in the 1960s or 1970s.

Cycling home from work, I designed a cheap way of building a flame
trap that would have stopped that problem.  Just a hinged metal
flap (alternating in direction) with a bag of silica gel up against
the side it moves towards.  Yes, it would get in the way of
maintenance but not catastrophically.

Now to the relevance.  I have begged more vendors and developers
than I care to think for the use of similar techniques in kernels,
device interfaces and so on.  Just a very simple trap so that,
when one component melts down, it doesn't take the rest of the
system with it.  No attempt to recover, no attempt to be clever,
but an almost bulletproof flame trap to stop disaster spreading.

Almost every time I do, I can see such a trap come down over their
eyes, to block out radical ideas from entering their brain :-(

I then get told that the solution is not to write broken devices
or drivers, never to install devices or drivers you can't trust,
that there is no way a CPU or kernel can protect itself from a
broken (by design, not failed) device or driver, and so on.  I
can't get the message across that good engineering is designing
for failure modes, not how well things work when everything goes
according to plan.

Nor can I explain to most of those people that very rare failures
should be protected against, if they are likely to cause disaster.
In the HPC context, a catastrophic failure is not a system crash,
so much as a too-frequent system crash that you can't locate the
cause of or reduce the probability of.  But that is a detail.

Anyone recognise my dislike of IA-64 and Infiniband in the above?
To name but two things ....


Regards,
Nick Maclaren.

In article <3F02299D.61BD05A7@stny.rr.com>, dada  <sman1@stny.rr.com> wrote:
><snip>
>
>I beleive that the basic idea is ti manage complexity, and isolate it as much as
>possible. The main advantage that we have with software is that if it is built
>correctly, the peices can be tested much earlier than the finished product. Most
>of the complexity that I see everyday is in interaction between systems (
>systems, components, programs, subprograms, etc.), and these can be mitigated by
>identifying as early as possible these critical interactions. Thus, the earlier
>in the implementatinos that integration can be applied can help expose
>errors/incompatabilites in the design. Each peice can the be thought of as that
>black box that everyone wants to acheive.

There seems to be a  pretty good consensus in this group about what to do 
and not to do in terms of software design; and there have been numerous
suggestions. The suggestions all attack complexity and try to establish 
quality control points at different points along the route.

The downside with these methods seems to be a slight time delay, but this
should be possible to recover in terms of better scalability.

>The problems I have seen is that the PHBs do not want the time spent in putting
>together these early systems (that takes time, which we all know is money), and
>rather want tangible results (we have sucessfully coded x% of the project...
>earned value and all that). They want the full engineering perfomed up front,
>instead of abstracting the system, doing the early integration, finding the
>problems early (whrn it is less costly to fix by the way) and then going on to
>the next level (yes I am a "fan" of spiral development).

If we set labels on it I tend to call it "iterative"; and "towards-the-middle".
A little top-down to establish structure; a little bottom-up to establish
control over the worst pitfalls in terms of external interfaces, and let
the middle sort itself out in an iterative fashion.

Now, to something completly different 

I have been looking at Open Source "products"; and we could use these
as analysis of how to and how not to. They are almost completly up in the
open, and can be scrutinized.

The metrics are impressive. I ran some scripts on my "build box", where I 
build FreeBSD utilities for myself and friends. I ran some scripts over
the source files, and did a rudimentary line count. This is just a raw
line count, for metric counts we'll probably have to reduce these by up to
a third.

The FreeBSD kernel, device drivers etc. are 2.4 M LOC
Add the utilities (everything in /usr/src) and we are at 7.4.
Add my "minimal set" of tools (basic Gnu, emacs, gcc, lynx, trn/leafnode, 
mh, etc.). These contain around 5.1 M Loc, exclusive of X11; and
the total is 12.5. This is the source for my expectation of a civilized
unix server; sans user graphics.  

I haven't gotten the script to run over the x11 tree; but this is
probably well documented elsewhere.

If I add together all the code I find in the source trees that I 
have built (and this includes X11, mozilla, java, openoffice etc) I find
close to 80 million lines of code. Some of these are duplicates, but
not very much.  FreeBSD is very well organized in this respect. I would
guess I have build somewhat more than half the projects in the ports
tree.

The vast bulk of these projects have a software quality that ranges 
well beyond what is normal. They are almost all run by software artisans.
And they seem to be pulling off a collective complexity that run well 
beyond what is a normal pain point in the software industry. 

Buggy projects  are normally clearly tagged as such; ref wine (alpha state).

I think the software industry should take due note and study what has been
accomplished here.

-- mrr

In article <3F0287DE.71D1B539@mediasec.de>, Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de> writes:
|> > There are instances, Szilard and the bomb, and the SR-71, where knowing
|> > basic materials like stuff while seemingly trivial made critical 
|> > differences in the final product (boron used in making graphite and
|> > distilled not tap water used in finishing and cleaning Ti).  And I'd 
|> > guess there were similar Cray stories.
|> 
|> Asimov also wrote a nice little story, based on a society where knowledge
|> and expertise is extremely fractioned and specialised (so that nobody has
|> the holistic view, and the different "experts" do not allow themselves to
|> critique their colleagues from a different field) and the biological
|> properties of Beryllium.

God help me, he could be describing the present.


Regards,
Nick Maclaren.

In article <3F019E50.6040705@cavtel.net>,
   jonah thomas <j2thomas@cavtel.net> wrote:
>jmfbahciv@aol.com wrote:
>>    jonah thomas <j2thomas@cavtel.net> wrote:
>
>>>When it works, one of the things that happens is that the interfaces 
>>>seem intuitive.  If they don't, then you'll drown in numbers of simple 
>>>interactions.  When it's simple components connected simply, you have 
>>>the possibility still to just get so many of them that you can't keep 
>>>track.
>
>> It's not intuitive!  The interfaces are documented.  Anything that
>> doesn't follow the call gets an immediate error return.
>
>Yes.  But if it isn't intuitive, you'll likely make lots of errors in 
>spite of the documentation.  When it works, usually it turns out to be 
>intuitive and also well-documented.

NOthing about computers is intuitive.

>
>>>>The same thing applies to hardware.  It is easy to analyse and debug
>>>>race and other inconsistency conditions involving two entities.  As
>>>>networks grow in complexity, it becomes harder and harder.  There
>>>>comes a point (approaching, in some networks) where most failure
>>>>time (down time or debugging) is not associated with a problem in
>>>>ANY component, but is associated with the network structure itself.
>>>>TANSTAFFL.
>
>>>By analogy I'd say that you might need hierarchical networks where you 
>>>never get too many units interacting at once.  Then you at least have 
>>>the possibility to track down the problems.  But performance degrades 
>>>across the hierarchy even in the best case.  Still, what choice do you 
>>>have?  If the alternative is sacrificing a system administrator to the 
>>>network gods every full moon....
>
>> I don't understand.  We used to call it black box development.
>> Rather similar to a box in a flow chart.  If you are outside the
>> box, the only thing you need to know is what goes in or what comes
>> out and NOT what happens inside.  
>
>The first theory was that if every individual black box works 
>'correctly' then a network of them will also work correctly.  But you 
>can get network problems that no individual component will show.  And 
>the more components in the network the harder it is to find out how the 
>problems start.
>
>To the extent that you can solve software problems by using simple 
>components connected simply in hierarchies (and this doesn't solve 
>everything) maybe you could apply the same approach to networks.  Simple 
>networks are easier to fix.

No, they're not.  I watched bit gods work on "simple" networks. 
Anything having to do with comm (interaction with human fingers)
is complex, frustrating, and fraught with CATCH-22s and deadly 
embraces.  Google (I hope that works) for a post that talked 
about Bob Clements' IRMA bit (named for the gal who could
consistently type in such a way to reproduce the problem) in
TOPS-10.

>
>So break a big network into small networks, and each of them can be made 
>to work.  Then you have a network of networks, and there are a limited 
>number of networks in the big network, and maybe you can fix that.  And 
>then the network of networks of networks.

You are approaching networks in an incorrect way.  You are trying
to think of each node as a black box and you can't IF you're debugging
a network problem.

>
>At each level you can hope to treat the components of that level as 
>black boxes.  But when you make the hierarchy you've restrictrd the 
>communication to established channels.  This may degrade the performance 
>in the best case.

But the "components" of a network is not each computer.  Components of
a network are [fingers fumbling for words it doesn't have] the functions;
I wanted to type layers but that's not quite correct.

>
>> The complexity of programming is that there exists nested black 
>> boxes.  If you keep going lower and lower and lower, you can
>> find yourself back in the electric generator at the power station
>> and then there are all those black boxes in the physics and wiring
>> areas.
>
>> The fun is arranging things so that a CATCH-22 becomes a nested
>> black box within itself.  That's a lot of fun. :-)
>
>"Doctor, it hurts when I do this."
>"Then don't do that."

No.  A CATCH-22 is when it also hurts when you don't do that.

/BAH

Subtract a hundred and four for e-mail.

Ken Moore <ken@i12.com> wrote in news:BmeJLUA5ceA$Ewmr@mooremusic.org.uk:

> In article <Xns93AB9CF857F46gardnertlogicacom@158.234.29.254>, Tom
> Gardner <gardnertSPAM@TRAPlogica.com> writes
>>Practice: HMS Sheffield was sunk because its long-range radar 
>>had been turned off in order to allow satellite communications;
>>thus missing the Exocet coming down its throat.
> 
> That's why it was hit.  The hit killed people and made a large hole, but
> it didn't sink Sheffield immediately.  It would probably have survived
> if the cable insulation had not been flammable, or if the bulkhead
> transitions had had some sort of flame trap.

True enough.

My father used to tell a story about a nuclear reactor, 
a power failure, a technician crawling through a duct 
with a candle (!), insulation set on fire, and all 
three "independent" scram circuits being routed through 
that duct.

Next somebody will mention optical fibres and backhoes.

In article <bec993c8.0307010930.4b55651@posting.google.com>,
   shoppa@trailing-edge.com (Tim Shoppa) wrote:
>nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in message 
news:<bdre26$56m$1@pegasus.csx.cam.ac.uk>...
>> In article <Pine.LNX.4.55.0307010926370.12021@ask.diku.dk>,
>> "Peter \"Firefly\" Lund" <firefly@diku.dk> writes:
>> |> On Tue, 1 Jul 2003, Nick Maclaren wrote:
>> |> 
>> |> > |> Why would software be any harder?
>> |> >
>> |> > Because it is less well engineered.  Also, do you know how many
>> |> 
>> |> No.  Because you don't have high-level screws.  10 million lines of 
mostly
>> |> flat-line code broken into pieces that interact very little with each
>> |> other would be a lot easier to understand than 10 million typical 
lines.
>> 
>> I suggest learning a little more about the design of such systems.
>> Your point is correct, but your viewpoint of their problems is
>> overly simplistic.
>> 
>> |> It would also be even easier if we did apply the engineering we know 
and
>> |> cut it down to say 5 or 10 thousand lines (probably less).
>> 
>> I know of no such example.  If you have ever tried to write a
>> serious product and keep it down to that size, you will have found
>> out that only some of the bloat is due to engineering incompetence.
>> Rather more is due to interfaces being designed non-mathematically,
>> but there is a large residue of special cases, messy situations and
>> so on that can't be handled compactly.
>> 
>> Factors of 10 reduction are often possible; factors of 100, perhaps.
>
>Largish complex systems often rely on tools such as table look-up to
>reduce the amount of C code and maximize the ability for at least the
>tables to be machine-checked for consistency.  This is really shifting
>the solution domain from "C code" (or whatever general-purpose
>computing language they use that week) to writing down the tables.
>
>> I do not believe factors of 1,000 and more, as you are claiming.
>
>I've seen some extreme cases of a factor of 1000, but in those cases
>they were *only* counting lines of C code and ignoring library calls
>and the complexity of the tables, even ignoring the tools used to
>build the tables.  i.e. they were cheating.
>
>MLOC's (Millions of Lines of Code) are one way to measure system 
complexity
>but certainly not the best one!

I usually thought in total CPU cycles to get my bit to
your bit; that included the ones outside the room and the
cycles needed to "create" that bit.  Note that this doesn't
include time to go get coffee and other stuff.

/BAH

Subtract a hundred and four for e-mail.

Ken Moore <ken@i12.com> writes:

> In article <Xns93AB9CF857F46gardnertlogicacom@158.234.29.254>, Tom
> Gardner <gardnertSPAM@TRAPlogica.com> writes
> >Practice: HMS Sheffield was sunk because its long-range radar 
> >had been turned off in order to allow satellite communications;
> >thus missing the Exocet coming down its throat.
> 
> That's why it was hit.  The hit killed people and made a large hole, but
> it didn't sink Sheffield immediately.  It would probably have survived
> if the cable insulation had not been flammable, or if the bulkhead
> transitions had had some sort of flame trap.

ISTR reading that the Exocet didn't detonate but that the engine
exhaust set the aluminum hull on fire. Don't have any reference
though.

*p

nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in 
news:bduadp$kp2$1@pegasus.csx.cam.ac.uk:

>  It is trivial to get factors of thousands
> or even millions if you do that.  Yes, I really do mean that there
> are program and data generators that will turn (say) 1 KB into 1 GB,
> and not be totally stupid!
> 

I recently had some salesmen that thought it impressive 
that their code generator had spat out 550.000 LOC of C++.
They didn't like it when I was unimpressed because, by 
that "reasoning", my codegen could have spat 
out 1,000,000 LOC.

No, they didn't do anything to justify their desired 
impression that 550KLOC was appropriate or beneficial :)

> |> Asimov also wrote a nice little story, based on a society where knowledge
> |> and expertise is extremely fractioned and specialised (so that nobody has
> |> the holistic view, and the different "experts" do not allow themselves to
> |> critique their colleagues from a different field) and the biological
> |> properties of Beryllium.
> God help me, he could be describing the present.

Oh, I'm sure it was pure satire, with a lot of jabs at science culture
(postoring, tirading, and so on), but it was quite overboard. I've been
there, and it's not _quite_ as bad. Although that passage in the "Double
Helix" when Chargaff visits Cambridge would fit right in.

	Jan

In article <3F02C43B.9DB145B1@mediasec.de>, Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de> writes:
|> > |> Asimov also wrote a nice little story, based on a society where knowledge
|> > |> and expertise is extremely fractioned and specialised (so that nobody has
|> > |> the holistic view, and the different "experts" do not allow themselves to
|> > |> critique their colleagues from a different field) and the biological
|> > |> properties of Beryllium.
|> 
|> > God help me, he could be describing the present.
|> 
|> Oh, I'm sure it was pure satire, with a lot of jabs at science culture
|> (postoring, tirading, and so on), but it was quite overboard. I've been
|> there, and it's not _quite_ as bad. Although that passage in the "Double
|> Helix" when Chargaff visits Cambridge would fit right in.

I wouldn't bet on it.  It is now VERY hard for someone from area A
(or even a generalist) to publish a result in area B in a 'technical'
journal, let alone get taken seriously.  And computing is definitely
one of those areas B!

I have personal experience of this, and know a fair number of other
people who have.  Areas of computing like complexity theory are
particularly bad examples of B, but there are lots of equally bad
ones in the older sciences, too.

It is fairly common for something to be rejected because it conflicts
with Authority, when a cursory inspection finds that the standard
Authoritative reference in area B is obviously false to anyone who
has a clue.  Where "has a clue" is relative to area A.

In order to get such things published, you FIRST have to tackle the
Authorised Beliefs head on.  I can witness that it isn't enough
just to demonstrate the flaw and provide counter-examples :-(

I agree that it is not yet universal ....


Regards,
Nick Maclaren.

Per Ekman <pek@pdc.kth.se> writes:

>ISTR reading that the Exocet didn't detonate but that the engine
>exhaust set the aluminum hull on fire. Don't have any reference
>though.

I don't think you can find a reference for that, because her hull and
superstructure were made of steel. The missile's remaining fuel was
indeed the chief cause of the fire.

"Morten Reistad" <mrr@reistad.priv.no> wrote in message
news:e5ordb.8u3.ln@acer...
> >|> " Aircraft carrier project--a naval project with 30 million parts (a
> >|> submarine has only 8 million parts)."
> >|>
> >|> Why would software be any harder?
>
> Because there are more interactions.

That depends on the compartmentalization.

And it also depends on the interface between compartments being implemented
as specified (or vice versa).

> A bolt holding a radar mast on an aircraft carrier does just that.  It
> can be inspected, maintained and changed by a person knowing about
> bolts and naval warship construction. [S]He does not have to know much
> about radar systems.
>
> A failure of this bolt will only lead to failure of one subsystem
> (beside someone getting hit by a falling mast).

Unless, of course, that bolt only partially fails, allowing the radar mast
to vibrate.  These vibrations might travel to other nearby parts and cause
more failures...

> They missed the ball big-time. The big potential for re-use is
> not of subroutines. It is of binary, working programs with defined
> interfaces; often rigorously standardized. Jfr. e-mail.

This is exemplified in the proliferation of *ix command line utilities such
as tr, sed, cp, cat, etc. which each do one thing and do it perfectly every
time -- Microsoft Word does the same exact functions, but it does it all in
one place requiring not only code to decide which function to perform but
also code to make sure functions don't interfere with each other.

> >Have you ever tried to report a problem to a large vendor that is
> >due SOLELY to the underlying computational assumptions of three or
> >more separately developed components being subtly incompatible?
> >I have.  Guess how far I got.

I worked at such a vendor; my experience was that any _reproducible_ bug was
patched within a few days.  Unfortunately, most bugs reported were
never reproduced in a lab and quickly closed due to lack of information.

> I have had the privilige of setting up operations for such
> software. Lesson#1 : You can write any SLA you want as long as
> there is a stringent validation for entry into the SLA. I never
> saw more than around 1/4th of projects ever make it into SLA
> terms; i.e. past external validation.

Or you learn to price the business such that you still make an acceptable
profit even if you fail every SLA...

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

Stephen Sprunk wrote:
> 
> > >Have you ever tried to report a problem to a large vendor that is
> > >due SOLELY to the underlying computational assumptions of three or
> > >more separately developed components being subtly incompatible?
> > >I have.  Guess how far I got.
> 
> I worked at such a vendor; my experience was that any _reproducible_ bug was
> patched within a few days.  Unfortunately, most bugs reported were
> never reproduced in a lab and quickly closed due to lack of information.
> 

The not reproducible is a major cop out.  I'm suprised that most vendors are
allowed to get away with this excuse but apparently they do.

A lot of not reproducible are thread related and this goes a long way in
explaining the sorry state of threaded programming.  You can have incompetent
programmers write crap threaded code and get away with it because most of
the bugs are "not reproducible".

Joe Seigh

In alt.folklore.computers Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
> 
> I wouldn't bet on it.  It is now VERY hard for someone from area A
> (or even a generalist) to publish a result in area B in a 'technical'
> journal, let alone get taken seriously.  And computing is definitely
> one of those areas B!

Slightly too easy in some Area Bs: ;)

http://www.physics.nyu.edu/faculty/sokal/

pete
-- 
pete@fenelon.com "there's no room for enigmas in built-up areas" HMHB

Joe Seigh wrote:
>
> The not reproducible is a major cop out.  I'm suprised that most
> vendors are allowed to get away with this excuse but apparently they
> do.

I am not a lawyer, but if someone had me up in court and failed to
produce evidence, I'd be more than a bit miffed if I was convicted.
However, World War Two isn't reproducible and yet no-one doubts
that it happened, so I suppose you are right.

Perhaps the problem is that the only evidence available tends to be
a crash dump. If more programs were capable of recording their own
execution history then we might have fewer bugs.

I have very little experience of software outside the PC mass-market.
Is this something that I'd find in other kinds of computer system?
To what extent can it be done by a without detailed knowledge of the
software package being monitored? (For example, could the OS vendor
help users by shipping a standard "baby sitting" program?)

In article <bduo0b$rj9$1$8302bc10@news.demon.co.uk>,
"Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:
|> Joe Seigh wrote:
|> >
|> > The not reproducible is a major cop out.  I'm suprised that most
|> > vendors are allowed to get away with this excuse but apparently they
|> > do.
|> 
|> I am not a lawyer, but if someone had me up in court and failed to
|> produce evidence, I'd be more than a bit miffed if I was convicted.
|> However, World War Two isn't reproducible and yet no-one doubts
|> that it happened, so I suppose you are right.
|> 
|> Perhaps the problem is that the only evidence available tends to be
|> a crash dump. If more programs were capable of recording their own
|> execution history then we might have fewer bugs.

Quite.  This is one of my hobby horses.  It used to be good practice.

|> I have very little experience of software outside the PC mass-market.
|> Is this something that I'd find in other kinds of computer system?

Rarely, but it used to more common.

|> To what extent can it be done by a without detailed knowledge of the
|> software package being monitored? (For example, could the OS vendor
|> help users by shipping a standard "baby sitting" program?)

Effectively not.  Black box approaches tend to produce excessive
output, be unhelpful, or both.

What the system COULD do is to provide some decent tools for such
diagnosis - such as being able to log all signals, with source,
destination and properties.  HP-UX certainly used to be able to
do a lot of this, under the name of auditing.  And most mainframes
could, of course.


Regards,
Nick Maclaren.

On 2 Jul 2003 06:20:37 -0700, bernd.paysan@gmx.de (Bernd Paysan)
wrote:

>It's all 
>information theory: how much information does a single rivet bear if you 
>make your ship out of thousands rectangular steel plates bend a bit and all 
>bound together with hundreds rivets on each side?

On the other hand, if an entire structure is held together with a
fastener of a single type, then the most subtle flaw in analysis or
quality control failure for that type of fastener could lead to
disaster.  If there are millions of anything in your design, you'd
better give a commensurate amount of time to thinking about the
anything.

Don't have the time to look up the reference, but there was a fairly
recent incident in which a well-respected structural engineer
miscalculated the wind loading on an already-completed skyscraper in
NYC.  The fix: tear the building apart piece by piece from the inside
and weld the joints that had previously only been bolted.

An even more dramatic example: an MIT study shows that the WTC towers
might not have collapsed if the horizontal strucutal members had been
attached with two bolts instead of just one.

For those who are interested in learning might have been done outside
the field of vision of their own computer monitor,

"information theory" "managing complexity"

is an interesting google search topic.  People have done a great deal
of thinking about this problem in many contexts.  It would be pure
hubris to imagine that the best thinking on this subject necessarily
comes out of software engineering.  

RM

"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:bduadp$kp2$1@pegasus.csx.cam.ac.uk...
>
> In article <_LxMa.1690$C36.2270@rwcrnsc51.ops.asp.att.net>,
> "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> writes:

> |> I would say that you should include the input data to such tools, but
not
> |> the tools themselves.  You wouldn't, for example, include the size of
the
> |> compiler used to compile a project in the complexity of the project,
though
> |> the compiler must exist.
>
> It depends on context.  If you are assessing the potential reliability
> of the resulting program in context, then you do need to be concerned
> about that.  A vast, complex compiler is likely to be buggier than a
> small, simple one.

Hmm.  Maybe it needs a different degree of complexity.  The object code of a
hello world program is not increased in complexity by the size of the
compiler.  Only a small portion of the compiler will be used, anyway.

Now, say I compile a C program containing a large table of high complexity
data.  (The source of that data being left unsaid for now.)   Still only a
small part of the compiler will be used, and not much more bugs are likely
to be found.

But yes, more complex programs tend to use more of the compiler, and uncover
bugs.  Maybe, though, it is that the compiler complexity is distributed over
all programs that it compiles?

> And, of course, you must include any tools that are specific to the
> project, or even customised for it.  Like Tim, I have seen claims
> based on moving the real code out to a library and denying that the
> library was part of the program (even though it had to be developed
> specially for that program!)

So if it is only useful for that project it counts.  If it is useful for
other projects is complexity is distributed over all the projects?

> The other form of cheating, which it appears that Peter Lund was
> using, is to use the OUTPUT from tools rather than their INPUT as
> the measure of complexity.  It is trivial to get factors of thousands
> or even millions if you do that.  Yes, I really do mean that there
> are program and data generators that will turn (say) 1 KB into 1 GB,
> and not be totally stupid!

I think, then, that you have to look at the actual complexity of the data.
A million digits of 0 has no complexity, while a million digits of pi could
be considered to have complexity.  Though those million digits could be
generated by a ten line program, so should be considered to have ten lines
of complexity?   As above, there is some dependence on the compiler.

-- glen

"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:5EDMa.59$I8.472@rwcrnsc53...

snip

> I think, then, that you have to look at the actual complexity of the data.
> A million digits of 0 has no complexity, while a million digits of pi
could
> be considered to have complexity.  Though those million digits could be
> generated by a ten line program, so should be considered to have ten lines
> of complexity?

That is pretty much the definition of the work that Greg Chatain has been
working on.  He defines complexity as the size of the smallest program that
can generate the output.   There is a lot more math and theory related to
this, but he has written a book and there whould be lots of references to
his work.

-- 
 - Stephen Fuld
   e-mail address disguised to prevent spam

In article <f19af6fc.0307020520.383e94b9@posting.google.com>,
Bernd Paysan <bernd.paysan@gmx.de> wrote:

Hey, we missed you at the ca-fest.

>Eugene Miya wrote:
>>>" Aircraft carrier project--a naval project with 30 million parts (a
>>>submarine has only 8 million parts)."
>> 
>> Are you attempting to equate a line of code to ship parts?
>
>Especially when the parts are all identical. How many nuts and bolts, screws 
>and rivets of a certain kind are used? The complexity of such a project is 
>more the number of different parts and the way they are arranged. It's all 
>information theory: how much information does a single rivet bear if you 
>make your ship out of thousands rectangular steel plates bend a bit and all 
>bound together with hundreds rivets on each side?

I decided to leave part diversity out.  That's the # of unique ICs in
the Cray-1 thread.

I realize that IT theory can be considered in this way, but I think
this detracts from the materials science and other empirical sciences
at this time.  We lack the universal tape reader to decode that tape.
And I know about the argument keeping the information of the individual
bolt (the easiest being bar code technology and far more methods of ID).
I think the infrastructure is the more important place to view the
complex object.  This is why the military-industrial complex to build
subs in Gorton fights for every sub contract it can get.

Diversity complicates the discussion.....
The question is how much noting it adds to the vault of the thread
(which is largely 1-D).

Jan C. Vorbr�ggen wrote:

>>NOthing about computers is intuitive.
> 
> 
> I don't agree with that. A lot of things are much more intuitive to me
> than to others (as deduced from observation and experience). I don't think
> I'm the only person wired that way.

No, you're not.

Grokking computers/programming/logic was a matter of a few weeks.

Personal interactions is something I'm still working on. :-(

OTOH, I'm definitely getting better. :-)

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

In article <ucm4gvor5eg0qfh3e00uv5agjsbf48of6v@4ax.com>,
Robert Myers  <rmyers@rustuck.com> wrote:
>On 1 Jul 2003 14:34:00 -0800, eugene@cse.ucsc.edu (Eugene Miya) wrote:
>>Are you attempting to equate a line of code to a plane part?
>>
>>>http://www.majorprojects.org/pubdoc/677.pdf
>>>
>>>" Aircraft carrier project--a naval project with 30 million parts (a
>>>submarine has only 8 million parts)."
>>
>>Are you attempting to equate a line of code to ship parts?
>
>I have written or supervised the writing of complicated software to
>simulate or to analyze complicated aerospace hardware, so the
>comparison seems natural to me.  I introduced it because I have been
>truly impressed by the ability of large aerospace organizations (full
>disclosure: my customers, not my employers) to cope with complexity.
>If the comparison seems inappropriate or forced to you, feel free to
>find another, but from what little I know of your background, I am
>surprised that the comparison would not seem natural to you.

My first high school job was designing parts (fasteners and stiffners)
for the B-1 bomber [that isn't impressive as it might sound as there
were over 50,000 people doing that].

I would hold with the academic (Brooks) line that the degree of
complexity exceeds anything so far known in the physical realm.

If you plan to induct based on numbers like this, you need to show to me
as a start, that 1 line of code is the necessary and sufficient comparison
to a single part of a sub/ship/plane.  That's just the start,
we'll get to the next step after that.

>>>Why would software be any harder?
>>
>>I can think of a number of reasons, likely some enumerated by other
>>follow ups.  One would get into the vague issues of natural language.
>>You can start with Brooks.
>
>Maybe it's just that it's the end of a long day.  Maybe it is that I
>got so many pugilistic responses to what seemed like a fairly benign
>comparison (truth be told, I think I touched a nerve).  Whatever the
>reason, Brooks' article strikes me as a lame laundry list of
>techniques with no real unifying insight as to the problem he claims
>to be addressing.  I'll try reading it again tomorrow.
>
>I have said in another thread recently, and I will say it again, that,
>when it comes to understanding of algorithms, we are like children.  I
>am therefore naturally suspicious of articles that attempt to draw
>general conclusions about methods of describing algorithms via
>software, since I don't know how you can draw conclusions about
>methods of describing what you don't fully understand to begin with.

The net is pugilistic because it shares an academic, message passing
history.  Your comparison is only benign because it's on the net and not
in active use that I can see.  Brooks gives no solution other than "it's
better to plan right" in his book and article.  Sending word messages is
its only effective method of working.  Typical (you don't see much
AutoCAD being exchanged here).

What mankind does know about complex systems is make them as simple as
possible and no simpler.  From that in the past few decades came the
term "over-engineering."  Rather than look at carriers look at the
Titanic, if sub, look at the Thresher, the Scorpion, and the various
Soviet era subs.  The problem with those comparisons is that they
suffered catastrophic failures.  You only have to know enough of the
algorithm.  And that's not enough for the system (system != algorithm).


>>>A paradigm already exists for scaling programs to arbitrarily large
>>>sizes.  It's called a network.
>>
>>Huh?  What kind of network?
>
>I responded to the same question posed by Nick Maclaren in some detail
>in this thread.
>
>What I described is a message-passing paradigm for stitching together
>software that is common in clusters but I don't think is used for
>routine programming.  I also gave a reasonably clear description of
>why I think the model is, to all appearances, indefinitely
>extensible.
>
>As I said in responding to Nick, I think Jan C. Vorbr�ggen got it
>exactly right when he said that what is different about software is
>that it is written in a strongly-coupled way.  A message-passing
>paradigm is one way of strictly limiting the coupling and allowing for
>complete monitoring of the interactions between separate program
>modules.

Message passing from the 60s to today is performance limited.
This is a common criticism (e.g., call by reference vs. call by value)
and it way COMMON blocks also got created.


>Notice, please, that I am not proposing a message-passing paradigm for
>all programming.  I am proposing it as a way of coping with extremely
>complex systems.  

Packet switching.
Data flow.
 etc.

>>Did Forrest cover the address space greater
>>than 32-bits thread in comp.arch a while back?
>
>The fact that the curve began with "Now that The Forrest Curve has
>become obviously true..." was more than a little off-putting to me,
>since I take the Forrest Curve about as seriously as I took the
>article entitled "IT Doesn't Matter" in the Harvard Business Review.
>Both discussions might as well have started with "Let's suppose that
>no one will ever think of entirely new ways of using computers."

That's why Jon was trolling.


>In any case, the thread has no particular relevance to the argument I
>made in responding to Nick, because the 32-bit thread dealt with
>programs on a single machine, and I take the very broad view that if
>two programs can talk to each other, they might as well be a single
>program.

This is the use of arrows in chemistry.  It boils down to thermodynamics
and whether processor are reversible.  As as absolute as "might as well be.."
it would be like tossing out eqn in
	... chem | pic| tbl | eqn | troff ...
which is not invertable.  Sometimes I want 2 separate programs.

Gotta run.

On Wed, 02 Jul 2003 12:36:00 GMT
Joe Seigh <jseigh_01@xemaps.com> wrote:

JS> The not reproducible is a major cop out.  I'm suprised that most
JS> vendors are allowed to get away with this excuse but apparently they
JS> do.

	It's really hard to fix something when you cannot make it go
wrong, it's even harder to know if you have fixed it.

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

On Wed, 02 Jul 2003 09:40:10 GMT
"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:

GH> Remember MIPS, Meaningless Indicator of Processor Speed.  Someone will
GH> need a new definition for MLOC's.

	Mandatory Layers Of Cruft.

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

In article <bdrcvp$4hr$1@pegasus.csx.cam.ac.uk> nmm1@cus.cam.ac.uk
(Nick Maclaren) writes:

>In article <2o12gvc6ishbpa20n8938rsae42s47vgbo@4ax.com>,
>Robert Myers <rmyers@rustuck.com> writes:
>
>|> A paradigm already exists for scaling programs to arbitrarily large
>|> sizes.  It's called a network.
>
>Yeah, right.  I was having run-ins with the "structured programming"
>dogmatists back in the 1960s and 1970s on this one, and the common
>errors have not changed.
>
>By splitting programs into functions of at most 20 lines long (yes,
>seriously), you may be able to understand every function at a glance.
>You will not, however, be able to understand their interactions.  So
>you split the program into separate ones of at most 20 functions,
>and can now understand every program.  But you will not be able to
>understand the network of programs.  And so on.

This is the fundamental failing of the Structured Programming
zealots.  They didn't eliminate complexity; they just moved it
from individual modules to the relationships between them.  My
quip at the height of the religious wars was that Structured
Programming represented the ultimate victory of the bureaucrats,
who finally managed to infiltrate the programming world with their
byzantine organizational techniques.

I realize that some large applications are unavoidably complex.
However, too much effort is being devoted to managing complexity
when it should go towards minimizing the complexity that has to
be dealt with in the first place.  Given the exponential nature
of complexity, a little work would go a long way.

I'm not holding my breath, though.  There are still many people
who equate complexity with sophistication, and who will worship
any package that flashes all sorts of intricate screens and has
them clicking buttons left and right - even though it's crippling
them in the process.

--
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

Stephen Fuld wrote:

> "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
>>be considered to have complexity.  Though those million digits could be
>>generated by a ten line program, so should be considered to have ten lines
>>of complexity?

Maybe a little more, but in that ballpark.
> 
> That is pretty much the definition of the work that Greg Chatain has been
> working on.  He defines complexity as the size of the smallest program that
> can generate the output.   There is a lot more math and theory related to
> this, but he has written a book and there whould be lots of references to
> his work.

This seems like a very straightforward extension of information theory:

The minimum number of bits to generate the output is the same as the 
information content of said program, right?

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Steve O'Hara-Smith wrote:
> On Tue, 01 Jul 2003 21:59:02 +0200
> Toon Moene <toon@moene.indiv.nluug.nl> wrote:
> 
> TM> Peter da Silva wrote:
> TM> 
> TM> > In article <2o12gvc6ishbpa20n8938rsae42s47vgbo@4ax.com>,
> TM> > Robert Myers  <rmyers@rustuck.com> wrote:
> TM> 
> TM> >>Why would software be any harder?
> TM> 
> TM> > Why would software be any easier? 10 million lines of code puts a
> TM> > program somewhere between a 747 and the Enterprise.
> TM> 
> TM> Isn't that the fundamental answer ?  If you commission a 10**7 million
> TM> line software project, the resulting product should have approximately
> TM> the same cost as a 747.
> 
> 	After making due allowances for the expense of obtaining, storing
> and handling with suitable precision all that metal and plastic etc.
> About the same cost in terms of time and skull sweat seems appropriate.
> 
> 	Testing is a bit cheaper too :)
> 

10,000,000 lines of code-

at 30 lines/day
at 240 days/year
at $100,000 year =

$139,000,000

About the cost of a 747.

Edward Wolfgram

jonah thomas wrote:
> jmfbahciv@aol.com wrote:

>> I watched bit gods work on "simple" networks. Anything having to do 
>> with comm (interaction with human fingers)
>> is complex, frustrating, and fraught with CATCH-22s and deadly 
>> embraces.  Google (I hope that works) for a post that talked about Bob 
>> Clements' IRMA bit (named for the gal who could
>> consistently type in such a way to reproduce the problem) in
>> TOPS-10.

> I'll google it.

I found nothing but another newsgroup post by you.  There was an IRMA 
something-or-other related to PDP and TOPS-10, but I didn't track down 
how it was named.  There were various geneology references.  Maybe some 
other keyword will show up.

In article <3F034861.6080707@ibi.com>,
Edward Wolfgram  <Edward_Wolfgram@ibi.com> wrote:
	...
>10,000,000 lines of code-
>
>at 30 lines/day
>at 240 days/year
>at $100,000 year =
>
>$139,000,000
>
>About the cost of a 747.

The difference is that management expects the software to be delivered
in 3 months instead of N years, makes major feature changes (read
"additions") several times in that period, and doesn't want to
increase head count to do the project.

But they are otherwise the same (:-).

Craig

Nick Maclaren wrote:
> jonah thomas  <j2thomas@cavtel.net> wrote:

>>I would have thought that adding extra components would add potential 
>>problems, so that more complicated networks would be even harder to fix. 
>> But it isn't my specialty and I'll defer to your knowledge.

> Don't confuse "simple" and "small".  It would have blown my mind
> back when I started computing to know that I would investigate
> AND LOCATE bugs in programs using MILLIONS of times larger data.
> If current systems were millions of times more complex, I would
> have taken up some other job :-)

Dealing with things like timing problems I'd expect rare hits to show up 
more often on large networks, and still be hard to reproduce.  But that 
might be a side issue.

When it's complexity of *behavior* you're talking about, then clearly 
simpler is easier.  Long action chains have places to fail than short 
chains.  Long branching chains have room for special cases that nobody 
thinks about because after all there are so many special cases possible, 
and you can't think of them all, and some of them are things that nobody 
in his right mind would want.

Could you get any value from levels of abstraction?  If at one level you 
have messages that are strings of bits that go from sources to 
destinations, and the system does indeed send the right strings from the 
right sources to the right destinations, then the question becomes why 
the sources aren't sending message or sending wrong messages.  The 
*network* is OK, it's just some uses of it that are failing.

Bernd Paysan wrote:
> Eugene Miya wrote:

>>>" Aircraft carrier project--a naval project with 30 million parts (a
>>>submarine has only 8 million parts)."

>>Are you attempting to equate a line of code to ship parts?

> Especially when the parts are all identical. How many nuts and bolts, screws 
> and rivets of a certain kind are used? 

Yes, but how many macros are used in the code?

> The complexity of such a project is 
> more the number of different parts and the way they are arranged. It's all 
> information theory: how much information does a single rivet bear if you 
> make your ship out of thousands rectangular steel plates bend a bit and all 
> bound together with hundreds rivets on each side?


Yes.  But then, suppose the programmers under-use macros?  For each task 
they see how many different ways they can do it?  That increases the 
information content, but not the value.

Shannon information content is sort of a measure of how *surprising* the 
code is.  I don't want to see a bunch of surprising ways to do the same 
thing.  I'd rather see a single routine to do a single thing, and let 
the surprise come in how well the various routines are fit together.

"Stephen Fuld" <s.fuld@PleaseRemove.att.net> wrote in message news:<%nEMa.32953$3o3.2401443@bgtnsc05-news.ops.worldnet.att.net>...
> "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:5EDMa.59$I8.472@rwcrnsc53...
> > I think, then, that you have to look at the actual complexity of the data.
> > A million digits of 0 has no complexity, while a million digits of pi
>  could
> > be considered to have complexity.  Though those million digits could be
> > generated by a ten line program, so should be considered to have ten lines
> > of complexity?
> 
> That is pretty much the definition of the work that Greg Chatain has been
> working on.  He defines complexity as the size of the smallest program that
> can generate the output.   There is a lot more math and theory related to
> this, but he has written a book and there whould be lots of references to
> his work.

My problem with that definition is that it defines a quantity that cannot
be measured.

That doesn't mean that it's useless.  "Voltage" of a single point is
useless, but the voltage difference between two points is useful.  Similarly
the Kolmogorov-Chatain complexity, even though it isn't a simple number,
has some conceptual value.

Tim.

>>>>" Aircraft carrier project--a naval project with 30 million parts (a
>>>>submarine has only 8 million parts)."

Eugene Miya wrote:
>>>Are you attempting to equate a line of code to ship parts?

Bernd Paysan wrote:
>> Especially when the parts are all identical. How many nuts and bolts, screws 
>> and rivets of a certain kind are used? 

In article <3F0361E4.4020606@cavtel.net>,
jonah thomas  <j2thomas@cavtel.net> wrote:
>Yes, but how many macros are used in the code?

An argument can be made fo inlining (for performance an other reasons).

>> The complexity of such a project is 
>> more the number of different parts and the way they are arranged. It's all 
>> information theory: how much information does a single rivet bear if you 
>> make your ship out of thousands rectangular steel plates bend a bit and all 
>> bound together with hundreds rivets on each side?
	we are now starting to describe the proverbal elephant as blind men.
>Yes.  But then, suppose the programmers under-use macros?  For each task 
>they see how many different ways they can do it?  That increases the 
>information content, but not the value.

In the past, in a simpler coding era, programmers/coders got along w/o
forms of abstraction  You could conceivably make this a coefficient or
factor but you end up with various equivalences (in the 70s of lines or
source to lines of object code or instructions).  People tried software
physics, McCabe measures, found that branching was the major cause of
complexity.

>Shannon information content is sort of a measure of how *surprising* the 
>code is.  I don't want to see a bunch of surprising ways to do the same 
>thing.  I'd rather see a single routine to do a single thing, and let 
>the surprise come in how well the various routines are fit together.

Hmmmm.
Too bad that Simon died.
His oft quoted Sciences of the Artificial's last chapter (6) was on the
architecture of complexity.  He pointed out that so far hierarchy has
been the only serious tool to deal with complexity.
Hopefully some readers had him as a prof and learned something from him.

Macros and libraries were fine in their time. Great.  But they fail to scale.
We need something better.

Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de> wrote:

>> There are instances, Szilard and the bomb, and the SR-71, where knowing
>> basic materials like stuff while seemingly trivial made critical 
>> differences in the final product (boron used in making graphite and
>> distilled not tap water used in finishing and cleaning Ti).  And I'd 
>> guess there were similar Cray stories.
>
>Asimov also wrote a nice little story, based on a society where knowledge
>and expertise is extremely fractioned and specialised (so that nobody has
>the holistic view, and the different "experts" do not allow themselves to
>critique their colleagues from a different field) and the biological
>properties of Beryllium.

     "Sucker Bait".

     Be fair.  The particular knowledge was quite old and had fallen
out of use.  It just happened that someone had read a book--an
obsolete information storage device no longer used--that described the
symptoms.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.

"Eugene Miya" <eugene@cse.ucsc.edu> wrote in message
news:3f01db01$1@news.ucsc.edu...

> I think a better analysis of the types of complexity would be better.
> I've never been a fan of line of code as a metric.  There are instances,
> Szilard and the bomb, and the SR-71, where knowing basic materials like
> stuff while seemingly trivial made critical differences in the final
> product (boron used in making graphite and distilled not tap water used
> in finishing and cleaning Ti).  And I'd guess there were similar Cray
> stories.

There is a story about the Cray-2.  When trying to figure out how to
distribute a 4ns (250MHz) clock throughout the system they came up with the
idea of making the whole box electrically resonant at that frequency.
While it should have been a good solution, it turned out that the logic
actually ran at 4.2ns, not 4.0ns. It took a lot of redesigning to get the
system to run at 4.2ns.

 (Note that while we have processors over a GHz these days, the external
clock is much lower, maybe still below 250MHz.  Also, it needs to be
distributed over a much smaller distance.)

-- glen

On 2 Jul 2003 09:44:45 -0800, eugene@cse.ucsc.edu (Eugene Miya) wrote:

>In article <ucm4gvor5eg0qfh3e00uv5agjsbf48of6v@4ax.com>,
>Robert Myers  <rmyers@rustuck.com> wrote:
>>On 1 Jul 2003 14:34:00 -0800, eugene@cse.ucsc.edu (Eugene Miya) wrote:

>
>>>>A paradigm already exists for scaling programs to arbitrarily large
>>>>sizes.  It's called a network.
>>>
>>>Huh?  What kind of network?
>>
>>I responded to the same question posed by Nick Maclaren in some detail
>>in this thread.
>>
>>What I described is a message-passing paradigm for stitching together
>>software that is common in clusters but I don't think is used for
>>routine programming.  I also gave a reasonably clear description of
>>why I think the model is, to all appearances, indefinitely
>>extensible.
>>
>>As I said in responding to Nick, I think Jan C. Vorbr�ggen got it
>>exactly right when he said that what is different about software is
>>that it is written in a strongly-coupled way.  A message-passing
>>paradigm is one way of strictly limiting the coupling and allowing for
>>complete monitoring of the interactions between separate program
>>modules.
>
>Message passing from the 60s to today is performance limited.
>This is a common criticism (e.g., call by reference vs. call by value)
>and it way COMMON blocks also got created.
>
The original claim was:

"If we don't find a different way of thinking about and creating
software, we will not be writing programs bigger than about 10 million
lines of code, no matter matter how fast, plentiful or exotic our
processors become."

so claiming that message passing is performance-limited doesn't fly as
an objection, because I have my choice of arbitrarily fast, plentiful,
and exotic processors to work with.

And I think this (along with the Forrest curve) really gets to the
heart of the matter.  If we've got power to burn, then let's burn it
building safer code.  If we build safer code, we will be able to build
more complex code.

In some primitive sense, the orignal proposition was literally
correct, because the (wrong) way that programmers are now thinking
about writing code is as if they were still working with an 8080 and
64K of memory, and that does need to change.

Looking over the entire thread, I'll drive my peg in the ground here:
except when taken in a way the author clearly did not intend, the
original proposition was not only wrong; it was fatuous.

RM

jmfbahciv@aol.com wrote:
> 
> In article <Xns93AC783292948gardnertlogicacom@158.234.29.254>,
>    Tom Gardner <gardnertSPAM@TRAPlogica.com> wrote:
> >nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in
> >news:bduadp$kp2$1@pegasus.csx.cam.ac.uk:
> >
> >>  It is trivial to get factors of thousands
> >> or even millions if you do that.  Yes, I really do mean that there
> >> are program and data generators that will turn (say) 1 KB into 1 GB,
> >> and not be totally stupid!
> >>
> >
> >I recently had some salesmen that thought it impressive
> >that their code generator had spat out 550.000 LOC of C++.
> >They didn't like it when I was unimpressed because, by
> >that "reasoning", my codegen could have spat
> >out 1,000,000 LOC.
> >
> >No, they didn't do anything to justify their desired
> >impression that 550KLOC was appropriate or beneficial :)
> 
> I bet they fall for all the Viagra spams, too.
> 
If you take Viagra, the source listing for your code
will be *two* inches thicker!!! How many LOC does that add???

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

Tim Shoppa wrote:
> 
>        [snip...]          [snip...]           [snip...]
> 
> In my day-to-day work I have extreme problems (not just with salesmen)
> dealing with machine generated code for which the generator has been
> lost/is no longer supported/is just plain broken.
> 
> Yes, code generators are a valuable tool.  But too often the generated
> code outlives the generator!
> 
And too often a "throw away" program is *not* thrown away well
enough. Someone will find the code, search out the author, and
demand explanations of how things were done.

As I heard it, programs whose source is 100 lines or more...
just don't get thrown away.

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

Nick Maclaren wrote:
> 
> In article <3F0287DE.71D1B539@mediasec.de>, Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de> writes:
> |> > There are instances, Szilard and the bomb, and the SR-71, where knowing
> |> > basic materials like stuff while seemingly trivial made critical
> |> > differences in the final product (boron used in making graphite and
> |> > distilled not tap water used in finishing and cleaning Ti).  And I'd
> |> > guess there were similar Cray stories.
> |>
> |> Asimov also wrote a nice little story, based on a society where knowledge
> |> and expertise is extremely fractioned and specialised (so that nobody has
> |> the holistic view, and the different "experts" do not allow themselves to
> |> critique their colleagues from a different field) and the biological
> |> properties of Beryllium.
> 
> God help me, he could be describing the present.
> 
Beep...beep...beep...beep...beep...

"This is windowless cubical XJ-341. In order to accomplish 
 my part of the project, I need more information about the 
 nature of the overall project."

Beep...beep...beep...beep...beep...

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

Nick Maclaren wrote:
> 
> In article <3F0287DE.71D1B539@mediasec.de>, Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de> writes:
> |> > There are instances, Szilard and the bomb, and the SR-71, where knowing
> |> > basic materials like stuff while seemingly trivial made critical
> |> > differences in the final product (boron used in making graphite and
> |> > distilled not tap water used in finishing and cleaning Ti).  And I'd
> |> > guess there were similar Cray stories.
> |>
> |> Asimov also wrote a nice little story, based on a society where knowledge
> |> and expertise is extremely fractioned and specialised (so that nobody has
> |> the holistic view, and the different "experts" do not allow themselves to
> |> critique their colleagues from a different field) and the biological
> |> properties of Beryllium.
> 
> God help me, he could be describing the present.
> 
I know a contract programmer who makes his money this way. He
goes into organizations and solves problems that fall between
what the several departments will claim responsibility for.

One of his jobs was compiling a list of changes that had to
be made to COBOL programs that ran on IBM mainframes...so that
they would run on Honeywell mainframes. (This was 20 or so 
years ago...but something that he still remembers fondly.)

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

Tom Gardner wrote:
> 
> nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in
> news:bduadp$kp2$1@pegasus.csx.cam.ac.uk:
> 
> >  It is trivial to get factors of thousands
> > or even millions if you do that.  Yes, I really do mean that there
> > are program and data generators that will turn (say) 1 KB into 1 GB,
> > and not be totally stupid!
> >
> 
> I recently had some salesmen that thought it impressive
> that their code generator had spat out 550.000 LOC of C++.
> They didn't like it when I was unimpressed because, by
> that "reasoning", my codegen could have spat
> out 1,000,000 LOC.
> 
> No, they didn't do anything to justify their desired
> impression that 550KLOC was appropriate or beneficial :)
>
I had a friend who programmed at NEC, and he is *not*
Japanese. He was showing some of the Japanese programmers
how they could accomplish some things more efficiently
and with fewer LOC. They just looked at him like he was
crazy. See, they were *required* to produce X number of
lines of code per day. Algorithms that produced less code
were counterproductive in their way of thinking...


--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

Joe Seigh wrote:
> 
> Stephen Sprunk wrote:
> >
> > > >Have you ever tried to report a problem to a large vendor that is
> > > >due SOLELY to the underlying computational assumptions of three or
> > > >more separately developed components being subtly incompatible?
> > > >I have.  Guess how far I got.
> >
> > I worked at such a vendor; my experience was that any _reproducible_ bug was
> > patched within a few days.  Unfortunately, most bugs reported were
> > never reproduced in a lab and quickly closed due to lack of information.
> >
> 
> The not reproducible is a major cop out.  I'm suprised that most vendors are
> allowed to get away with this excuse but apparently they do.
> 
> A lot of not reproducible are thread related and this goes a long way in
> explaining the sorry state of threaded programming.  You can have incompetent
> programmers write crap threaded code and get away with it because most of
> the bugs are "not reproducible".
> 
Okay, now I get to re-post "The Twelve Bugs of Christmas"!!!

-------

For the twelfth bug of Christmas, my manager said to me
  Tell them it's a feature
  Say it's not supported
  Change the documentation
  Blame it on the hardware
  Find a way around it
  Say they need an upgrade
  Reinstall the software
  Ask for a dump
  Run with the debugger
  Try to reproduce it
  Ask them how they did it and
  See if they can do it again.

-------

Well, that's the last verse...you can backwind it yourself, if you
want to sing the whole thing...

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

Craig A. Finseth wrote:

> In article <3F034861.6080707@ibi.com>,
> Edward Wolfgram  <Edward_Wolfgram@ibi.com> wrote:
> ...
>>10,000,000 lines of code-
>>
>>at 30 lines/day
>>at 240 days/year
>>at $100,000 year =
>>
>>$139,000,000
>>
>>About the cost of a 747.
> 
> The difference is that management expects the software to be delivered
> in 3 months instead of N years, makes major feature changes (read
> "additions") several times in that period, and doesn't want to
> increase head count to do the project.
> 
> But they are otherwise the same (:-).

That, and the fact that you can't stamp out copies of the 747 for fifty 
cents apiece once the design is finished and tested.

-- 
Roland Hutchinson              Will play viola da gamba for food.

NB mail to my.spamtrap [at] verizon.net is heavily filtered to
remove spam.  If your message looks like spam I may not see it.

On Wed, 02 Jul 2003 17:02:25 -0400
Edward Wolfgram <Edward_Wolfgram@ibi.com> wrote:

EW> 10,000,000 lines of code-
EW> 
EW> at 30 lines/day
EW> at 240 days/year
EW> at $100,000 year =
EW> 
EW> $139,000,000
EW> 
EW> About the cost of a 747.

	That's the cost of buying a 747 is it not ? (ie. running the
compiler, shipping the object and milking the customer). Now what was the
cost of developing the 747 ?

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

In article <E5MMa.1508$Ey6.822@rwcrnsc52.ops.asp.att.net>,
Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>"Eugene Miya" <eugene@cse.ucsc.edu> wrote in message
>news:3f01db01$1@news.ucsc.edu...
>> in finishing and cleaning Ti).  And I'd guess there were similar Cray
>> stories.
>
>There is a story about the Cray-2.  When trying to figure out how to
>distribute a 4ns (250MHz) clock throughout the system they came up with the
>idea of making the whole box electrically resonant at that frequency.
>While it should have been a good solution, it turned out that the logic
>actually ran at 4.2ns, not 4.0ns. It took a lot of redesigning to get the
	4.1 ns
>system to run at 4.2ns.

We were told that Seymour "agonized" over that 0.1 ns.  He really wanted
it to be 4.0 ns.  I recall seeing a memo, and it may have been published
in a paper somewhere.  "Agony" was mentioned by CRI guys.

BUT it was not as a simple as that.  It took 2 cycles to execute a
single instruction independent of instruction fetches.  The behavior
was difficult to debug inconsistent instruction execution.  That is what
I can tell you.  So some may attempt to argue 8.2 ns (X-MPs were still
9.5 ns at the time)

Gombosi, if you can still troll for him in c.s.s. will know more.
There are others, but I doubt you could get them out of lurking.

> (Note that while we have processors over a GHz these days, the external
>clock is much lower, maybe still below 250MHz.  Also, it needs to be
>distributed over a much smaller distance.)

It's really how many cycles a load/fetch is from memory.
There was a red covered manual NOFORN distribution on how the memory
was organized (Quadrants and banks and physical addressing).
It truly is an issue of memory bandwidth and not clock cycle.

In article <3F035E52.1040508@cavtel.net>,
jonah thomas <j2thomas@cavtel.net> writes:
|> 
|> Dealing with things like timing problems I'd expect rare hits to show up 
|> more often on large networks, and still be hard to reproduce.  But that 
|> might be a side issue.

No, it's an example of the minor increase in complexity due to size
that I was talking about.

|> When it's complexity of *behavior* you're talking about, then clearly 
|> simpler is easier.  Long action chains have places to fail than short 
|> chains.  Long branching chains have room for special cases that nobody 
|> thinks about because after all there are so many special cases possible, 
|> and you can't think of them all, and some of them are things that nobody 
|> in his right mind would want.

A worse problem is branching chains, where you can get paths that
cannot be reliably reproduced.  If one is taken one time in a
million, unpredictably, then it is quite likely to have an undetected
bug.  If your use then increases its probability to one time in
a thousand, you may go bananas where none of the other sites have
the problem.

|> Could you get any value from levels of abstraction?  If at one level you 
|> have messages that are strings of bits that go from sources to 
|> destinations, and the system does indeed send the right strings from the 
|> right sources to the right destinations, then the question becomes why 
|> the sources aren't sending message or sending wrong messages.  The 
|> *network* is OK, it's just some uses of it that are failing.

Yes and no.  That helps only if the intermediate levels have clean,
well-specified AND well-checked interfaces, so problems in a higher
level are very rarely caused by problems in a lower level.


Regards,
Nick Maclaren.

In article <20030702203222.3fc69ddc.steveo@eircom.net>, Steve O'Hara-Smith <steveo@eircom.net> writes:
|> On 1 Jul 2003 09:14:16 GMT
|> nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
|> 
|> NM> The fact that modern passenger aircraft don't crash as often as
|> NM> modern computer systems is not because they are simpler, but
|> NM> because traditional engineering discipline is used.
|> 
|> 	An important part of this is extensive modeling and prototyping
|> before the design, including production process, component specs and
|> tests, is finalised and production starts. Then certification tests and
|> changes. Then a large number of (as nearly as possible) identical units
|> are made and extensive performance reporting and analysis of every
|> incident happens.
|> 
|> 	I've probably missed several important steps and checks (it's been
|> a while since this was described to me) but the idea is clear. Lots of
|> careful design and specification and much testing before production.
|> 
|> 	It is rare IME for *any* of these to take place in software
|> development. When there is essentially one internal customer this is
|> perhaps not feasible (being on time and usable is sometimes far better
|> than being late and perfect). For software that sells in millions of
|> copies it should be well within scope to do a really good job of it.

It is.  One of the companies that does a relatively good job in the
"general purpose computing" arena is NAG (Numerical Algorithms Group),
and I keep badgering them to market their software engineering skills
harder.  They DON'T sell in millions of copies, either!

Another example was the version of CICS developed using the Z system.
They delivered some really impressive figures for reduction in the
number of problems encountered in the field - their first release was
comparably stable to most 'mature' products.

I have heard that the same is true for a fair number of embedded
software products.

The point about what you describe is that it is an investment and
not an 'overhead', in that you can recoup the expense in terms of
ongoing debugging and support costs.

But, as you say, it is rare :-(


Regards,
Nick Maclaren.

In article <3F033593.7060806@cavtel.net>,
   jonah thomas <j2thomas@cavtel.net> wrote:
>jmfbahciv@aol.com wrote:
>>    jonah thomas <j2thomas@cavtel.net> wrote:
>>>jmfbahciv@aol.com wrote:
>>>>   jonah thomas <j2thomas@cavtel.net> wrote:

<snip>

>> I watched bit gods work on "simple" networks. 
>> Anything having to do with comm (interaction with human fingers)
>> is complex, frustrating, and fraught with CATCH-22s and deadly 
>> embraces.  Google (I hope that works) for a post that talked 
>> about Bob Clements' IRMA bit (named for the gal who could
>> consistently type in such a way to reproduce the problem) in
>> TOPS-10.
>
>I'll google it.

IIRC, it was posted last half of 1995 or first part of 1996.
 <snip>

>>>At each level you can hope to treat the components of that level as 
>>>black boxes.  But when you make the hierarchy you've restrictrd the 
>>>communication to established channels.  This may degrade the performance 
>>>in the best case.
>
>> But the "components" of a network is not each computer.  Components of
>> a network are [fingers fumbling for words it doesn't have] the 
functions;
>> I wanted to type layers but that's not quite correct.
>
>I'll try -- in behavioral psychology you can get action chains where one 
>behavior triggers another (in the same or a different animal) and so a 
>complex interaction can result that no individual participant has 
>thought out.  Could the "components" of a network be like action chains? 

You're still thinking in "event, then effect".  It doesn't get that
simple if you have to deal with interrupts at any time in any place.
A timesharing OS deals with this.  Networks also have to deal with
"did you hear me? If you did, what did I say?" problems.  Electricity
is very slow.

>  The issue isn't the individual network nodes, each of which (in one 
>ideal case) behaves identically and predictably, 

But you see, this is an impossibility.  Electricity is very slow.
Everything is constrained by <c.  Networks imply humans.  There isn't
any way you can reproduce _exactly_ human interaction (I'm thinking
about timing and a computer's response to that timing).

> ..but the various 
>patterns of interaction?  I can see it would sometimes be useful to 
>think about the sytsem along those lines.

Not sometimes.  Most of the time.  Look at all the "kiddies" on-line
who think that newgroups are chat rooms and expect immediate response
time.

>
>>>>The fun is arranging things so that a CATCH-22 becomes a nested
>>>>black box within itself.  That's a lot of fun. :-)
>
>>>"Doctor, it hurts when I do this."
>>>"Then don't do that."
>
>> No.  A CATCH-22 is when it also hurts when you don't do that.
>
>If possible, avoid designing CATCH-22's into your system.

You can't avoid them when you've got a system that can be
interrupted.  You can't avoid them if you have a routine
that depends on the outcome of its last call.  Bootstrapping
gets real interesting if your input was based on your last output.
It gets really, really interesting if your input a time A is based
on the output of time A+n.

> ..  They are fun 
>but ultimately unrewarding when your intention is to get usable results.

Think about a magtape full of files.  Now your job is to put a
checksummed directory at BOT of the contents of that tape.
Note that a magtape can only be written from beginning to end.
How do you put a directory of the tape at BOT (beginning of tape)
when you haven't written the tape yet?

/BAH


Subtract a hundred and four for e-mail.

In article <3F03BE2E.6843DBA4@ev1.net>,
   Charles Richmond <richmond@ev1.net> wrote:
>jmfbahciv@aol.com wrote:
>> 
>> In article <Xns93AC783292948gardnertlogicacom@158.234.29.254>,
>>    Tom Gardner <gardnertSPAM@TRAPlogica.com> wrote:
>> >nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in
>> >news:bduadp$kp2$1@pegasus.csx.cam.ac.uk:
>> >
>> >>  It is trivial to get factors of thousands
>> >> or even millions if you do that.  Yes, I really do mean that there
>> >> are program and data generators that will turn (say) 1 KB into 1 GB,
>> >> and not be totally stupid!
>> >>
>> >
>> >I recently had some salesmen that thought it impressive
>> >that their code generator had spat out 550.000 LOC of C++.
>> >They didn't like it when I was unimpressed because, by
>> >that "reasoning", my codegen could have spat
>> >out 1,000,000 LOC.
>> >
>> >No, they didn't do anything to justify their desired
>> >impression that 550KLOC was appropriate or beneficial :)
>> 
>> I bet they fall for all the Viagra spams, too.
>> 
>If you take Viagra, the source listing for your code
>will be *two* inches thicker!!! How many LOC does that add???
>
A lot if it's a bit sprayer.

/BAH

Subtract a hundred and four for e-mail.

Charles Richmond wrote:
> Nick Maclaren wrote:
>>God help me, he could be describing the present.
>>
> I know a contract programmer who makes his money this way. He
> goes into organizations and solves problems that fall between
> what the several departments will claim responsibility for.

About half of all my 'fire-fighting/urgent' projects turn up this way:

Some new system straddles two or more departments, and it is impossible 
to determine who should have overall responsibility.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

> The particular knowledge was quite old and had fallen out of use.  

....which it shouldn't have. Hey, I worked as an undergraduate at CERN,
and listened in to discussion of the advantages and disadvantes of using
Beryllium for the beam pipe.

	Jan

In article <2118.313T2371T6625464@kltpzyxm.invalid>,
   "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote:
>In article <bdrcvp$4hr$1@pegasus.csx.cam.ac.uk> nmm1@cus.cam.ac.uk
>(Nick Maclaren) writes:
>
>>In article <2o12gvc6ishbpa20n8938rsae42s47vgbo@4ax.com>,
>>Robert Myers <rmyers@rustuck.com> writes:
>>
>>|> A paradigm already exists for scaling programs to arbitrarily large
>>|> sizes.  It's called a network.
>>
>>Yeah, right.  I was having run-ins with the "structured programming"
>>dogmatists back in the 1960s and 1970s on this one, and the common
>>errors have not changed.
>>
>>By splitting programs into functions of at most 20 lines long (yes,
>>seriously), you may be able to understand every function at a glance.
>>You will not, however, be able to understand their interactions.  So
>>you split the program into separate ones of at most 20 functions,
>>and can now understand every program.  But you will not be able to
>>understand the network of programs.  And so on.
>
>This is the fundamental failing of the Structured Programming
>zealots.  They didn't eliminate complexity; they just moved it
>from individual modules to the relationships between them.  

IMO, that immediately adds another layer of complexity.
When people put idiotic constraints on a routine such as
20 line or less, it's time to put the power button.

> ..My
>quip at the height of the religious wars was that Structured
>Programming represented the ultimate victory of the bureaucrats,
>who finally managed to infiltrate the programming world with their
>byzantine organizational techniques.
>
>I realize that some large applications are unavoidably complex.
>However, too much effort is being devoted to managing complexity
>when it should go towards minimizing the complexity that has to
>be dealt with in the first place.  Given the exponential nature
>of complexity, a little work would go a long way.
>
>I'm not holding my breath, though.  There are still many people
>who equate complexity with sophistication, and who will worship
>any package that flashes all sorts of intricate screens and has
>them clicking buttons left and right - even though it's crippling
>them in the process.

JMF was very proud that his program typed a dot on the TTY paper.
Not many people understood the sophistication, complexity or
man-centuries of work that went into that dot.

/BAH


Subtract a hundred and four for e-mail.

> He pointed out that so far hierarchy has been the only serious tool
> to deal with complexity.

I agree with him. Where we can build a hierarchy - e.g., in physics and 
chemistry - systems can be understood and built on multiple levels reasonably.
Where we don't - e.g., brain research - progress has been piecemeal, and
basically non-existent on the systems/subsystems level. (Of course, there
also is the problem that biologists are hunter/gatherers of facts and
dogmatists, which complicates things a lot.) But even the concepts or the
partitioning, as it were, are missing.

	Jan

Charles Richmond <richmond@ev1.net> wrote in message news:<3F03BEBC.C6E4890B@ev1.net>...
> Tim Shoppa wrote:
> > 
> >        [snip...]          [snip...]           [snip...]
> > 
> > In my day-to-day work I have extreme problems (not just with salesmen)
> > dealing with machine generated code for which the generator has been
> > lost/is no longer supported/is just plain broken.
> > 
> > Yes, code generators are a valuable tool.  But too often the generated
> > code outlives the generator!
> > 
> And too often a "throw away" program is *not* thrown away well
> enough. Someone will find the code, search out the author, and
> demand explanations of how things were done.
> 
> As I heard it, programs whose source is 100 lines or more...
> just don't get thrown away.

Some of the code generators that I've worked with have hundreds of thousands
of lines in the code generator source.  But they're used in such simplistic
ways that a 20-line Perl script could replicate all the functionality that's
actually used.

In the interest of reducing complexity I would be in favor of the short
script that did the same functionality... but others who manage complexity
insist that the COTS product is the right solution because we don't have to
count a single line of its source, nor the hundreds of hours put into
configuring the COTS product!

Tim.

In article <bdui3h$qs4$1@pegasus.csx.cam.ac.uk>,
Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
> I wouldn't bet on it.  It is now VERY hard for someone from area A
> (or even a generalist) to publish a result in area B in a 'technical'
> journal, let alone get taken seriously.  And computing is definitely
> one of those areas B!

Yeh, it would be so totally impossible for some unknown from a small country
like Finland to make an impact on the field.

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

jmfbahciv@aol.com wrote:
>    "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote:
>>(Nick Maclaren) writes:

>>>By splitting programs into functions of at most 20 lines long (yes,
>>>seriously), you may be able to understand every function at a glance.
>>>You will not, however, be able to understand their interactions.  So
>>>you split the program into separate ones of at most 20 functions,
>>>and can now understand every program.  But you will not be able to
>>>understand the network of programs.  And so on.

>>This is the fundamental failing of the Structured Programming
>>zealots.  They didn't eliminate complexity; they just moved it
>>from individual modules to the relationships between them.  

> IMO, that immediately adds another layer of complexity.
> When people put idiotic constraints on a routine such as
> 20 line or less, it's time to put the power button.

Any arbitrary contraint, arbitrarily obeyed, will do that.

3509 REM add A and B, put the result in C
3510 LET C = A + B
3519 REM send the value of C to the output
3520 PRINT C

A demand for documentation can produce this sort of thing, and yet 
completely undocumented code is not usually good either.

It's good to break programs up into pieces that make sense.  A bunch of 
small pieces that each make sense, called by small higher-level routines 
that each make sense, etc -- that's a good thing.  A 500-line program 
broken up into 30 20-line-or-less segments whose only purpose was to 
follow a rule, would be utterly stupid.

In article <20030702203222.3fc69ddc.steveo@eircom.net>,
Steve O'Hara-Smith  <steveo@eircom.net> wrote:
> 	It is rare IME for *any* of these to take place in software
> development.

Just out of curiosity...  what do you see as the analogous step in
software development for "a large number of (as nearly as possible)
identical units are made"?

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

In article <bec993c8.0307020917.4d4b0f5d@posting.google.com>,
Tim Shoppa <shoppa@trailing-edge.com> wrote:
> In my day-to-day work I have extreme problems (not just with salesmen)
> dealing with machine generated code for which the generator has been
> lost/is no longer supported/is just plain broken.  

> Yes, code generators are a valuable tool.  But too often the generated
> code outlives the generator!

I assume that's why Frank da Cruz included a parser generator in C-Kermit.

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

jonah thomas <j2thomas@cavtel.net> writes:

>It's good to break programs up into pieces that make sense.  A
>bunch of small pieces that each make sense, called by small
>higher-level routines that each make sense, etc -- that's a good
>thing.  A 500-line program broken up into 30 20-line-or-less
>segments whose only purpose was to follow a rule, would be utterly
>stupid.

I'd have used up the 20 lines just checking a few input parameters
for sensibility.

Typical program of mine is 80% error checking. If I'm feeling
especially paranoid, it's 90%.

Most other code I've seen simply trusts the inputs and never checks
return codes from functions. They simply accept that the data is
sane... so they only have up to 20% error checking... often; none.
There are lots of lines of code; plenty of comments that confuse;
not elucidate.

And I've dealt with all sort from structural design to banking
software. I've seen cheque numbers overflowing into amount fields;
and yk2 "years" of over 100 doing pretty much the same thing.
I've seen function results that are NAN being used for further
computation; without checking.
-- 
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ /  ASCII ribbon campaign | I'm a .signature virus!
 X   against HTML mail     | Copy me into your ~/.signature
/ \  and postings          | to help me spread!

Peter da Silva wrote:

> In article <20030702203222.3fc69ddc.steveo@eircom.net>,
> Steve O'Hara-Smith  <steveo@eircom.net> wrote:
>> It is rare IME for *any* of these to take place in software
>> development.
> 
> Just out of curiosity...  what do you see as the analogous step in
> software development for "a large number of (as nearly as possible)
> identical units are made"?

Component re-use. An oft-touted, but seldom-exercised, capability of
component-based software architectures. Well, hmm, if you count Unix shell
scripting as gluing together components, component re-use is a common thing...
but Unix shell components are rather limited (restricted to operating upon a
sequential input stream and a sequential output stream both of which are
comprised of text), and we all know that shell scripts gluing these components
together *never* have bugs :-).  

-- 
Eric Lee Green  mailto:eric@badtux.org
Unix/Linux/Storage Software Engineer needs job -- 
see http://badtux.org for resume


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

In article <be1akh$88e$1@jeeves.eng.abbnm.com>, peter@abbnm.com (Peter da Silva) writes:
|> In article <20030702203222.3fc69ddc.steveo@eircom.net>,
|> Steve O'Hara-Smith  <steveo@eircom.net> wrote:
|> > 	It is rare IME for *any* of these to take place in software
|> > development.
|> 
|> Just out of curiosity...  what do you see as the analogous step in
|> software development for "a large number of (as nearly as possible)
|> identical units are made"?

In my view, strong enforcement of programming style and conventions.
It doesn't matter WHAT they are, but a programmer should be able
to look at two sections of code and, if they look similar, they
should behave similarly.


Regards,
Nick Maclaren.

shoppa@trailing-edge.com (Tim Shoppa) wrote in
news:bec993c8.0307030455.18a1c944@posting.google.com: 

> Charles Richmond <richmond@ev1.net> wrote in message
> news:<3F03BEBC.C6E4890B@ev1.net>... 
>> Tim Shoppa wrote:
>> > 
>> >        [snip...]          [snip...]           [snip...]
>> > 
>> > In my day-to-day work I have extreme problems (not just with
>> > salesmen) dealing with machine generated code for which the
>> > generator has been lost/is no longer supported/is just plain
>> > broken. 
>> > 
>> > Yes, code generators are a valuable tool.  But too often the
>> > generated code outlives the generator!
>> > 
>> And too often a "throw away" program is *not* thrown away well
>> enough. Someone will find the code, search out the author, and
>> demand explanations of how things were done.
>> 
>> As I heard it, programs whose source is 100 lines or more...
>> just don't get thrown away.
> 
> Some of the code generators that I've worked with have hundreds of
> thousands of lines in the code generator source.  But they're used in
> such simplistic ways that a 20-line Perl script could replicate all
> the functionality that's actually used.
> 
> In the interest of reducing complexity I would be in favor of the
> short script that did the same functionality... but others who manage
> complexity insist that the COTS product is the right solution because
> we don't have to count a single line of its source, nor the hundreds
> of hours put into configuring the COTS product!

Nor teh hundreds of hours climbing the learning 
curve of what it is meant to do, how to use it, 
how to get around its foibles, ...

Sometimes there is a good reason for the 
"not invented here" syndrome :(

"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
news:f19af6fc.0307020520.383e94b9@posting.google.com...
> Eugene Miya wrote:
> >>" Aircraft carrier project--a naval project with 30 million parts (a
> >>submarine has only 8 million parts)."
> >
> > Are you attempting to equate a line of code to ship parts?
>
> Especially when the parts are all identical. How many nuts
> and bolts, screws and rivets of a certain kind are used? The
> complexity of such a project is more the number of different
> parts and the way they are arranged. It's all information theory:
> how much information does a single rivet bear if you
> make your ship out of thousands rectangular steel plates
> bend a bit and all bound together with hundreds rivets on each side?
>
But a computer program is made up of only two components, ones
and zeroes in about equal parts. All that is required it to sort
them into the correct order.

--Don
e-mail: it's not not, it's hot.

On Wed, 02 Jul 2003 17:02:25 -0400, Edward Wolfgram
<Edward_Wolfgram@ibi.com> wrote:

>
>10,000,000 lines of code-
>
>at 30 lines/day
>at 240 days/year
>at $100,000 year =
>
>$139,000,000
>
>About the cost of a 747.
>
>Edward Wolfgram
>

To put the comparison on a more apples-to-apples basis, the
usually-cited original development cost of the 747 is $1 billion, a
figure that cannot include the cost of developing the engine, because
the cost of developing an entirely new jumbo-jet class engine is at
least $1 billion.

I can't find reliable numbers for what would pass for the actual
development costs of the 747 in fixed dollars, but I will bet that
they significantly exceeded $1 billion in 2003 dollars.

As to the cost of developing a jumbo jet engine, Fortune gives some
good recent numbers and some interesting insight:

http://216.239.39.100/search?q=cache:DiNhst-9ibIJ:www.fortune.com/fortune/imt/0,15704,401273,00.html+%22jet+engine%22+billion++%22development+costs%22&hl=en&ie

"The 115B is not a completely new design. The first GE90s went into
service in 1995. But after spending some $2 billion developing them,
GE is putting as much as $600 million more into this version. And
that's just part of what GE's aircraft engine managers call the most
ambitious product and technology development program in their history.
At a time when the airlines, GE's principal customers, are nosediving
toward bankruptcy, trailing plumes of burning cash, the company has a
dozen new or updated engines under development. Outsiders might well
wonder whether GE has jettisoned common sense. But it doesn't have a
lot of choice. Engines, often sold at breakeven or at a loss, are not
where this business makes its money. They are a means to an end: parts
and service revenues, which will account for 40% of the business's
$10.6 billion in sales this year and possibly as much as two-thirds of
its $2.1 billion in operating profit."

RM

On Thu, 3 Jul 2003 13:21:21 +0000 (UTC)
peter@abbnm.com (Peter da Silva) wrote:

PDS> In article <20030702203222.3fc69ddc.steveo@eircom.net>,
PDS> Steve O'Hara-Smith  <steveo@eircom.net> wrote:
PDS> > 	It is rare IME for *any* of these to take place in software
PDS> > development.
PDS> 
PDS> Just out of curiosity...  what do you see as the analogous step in
PDS> software development for "a large number of (as nearly as possible)
PDS> identical units are made"?

	Shipping the product, for some products this translates to an
enormous number of identical units. What doesn't happen is much by the way
of incident analysis, nobody sends a team of crash site inspectors round
to determine the cause when something goes wrong.

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

On Thu, 03 Jul 2003 03:28:11 GMT
Charles Richmond <richmond@ev1.net> wrote:

CR> If you take Viagra, the source listing for your code
CR> will be *two* inches thicker!!! How many LOC does that add???

	Just send five lines of code to each of the addresses below and
you will soon receive more code than you can ever compile ,,,

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

> The original claim was:
> 
> "If we don't find a different way of thinking about and creating
> software, we will not be writing programs bigger than about 10 million
> lines of code, no matter matter how fast, plentiful or exotic our
> processors become."
> 
> so claiming that message passing is performance-limited doesn't fly as
> an objection, because I have my choice of arbitrarily fast, plentiful,
> and exotic processors to work with.
> 
> And I think this (along with the Forrest curve) really gets to the
> heart of the matter.  If we've got power to burn, then let's burn it
> building safer code.  If we build safer code, we will be able to build
> more complex code.
> 
> In some primitive sense, the orignal proposition was literally
> correct, because the (wrong) way that programmers are now thinking
> about writing code is as if they were still working with an 8080 and
> 64K of memory, and that does need to change.
> 
> ... 

Call it culture shock, but I continually shake my head at half the 
threads in this conference.  Some programmers have not and do not write 
code as if we were still working on an 8080- I and many others write as 
if we were *still working on an IBM S370*. Using a reliable operating 
system, where if you find a bug, it actually gets fixed by the vendor!

I feel like a grownup whose world has been taken over by a bunch of 
ignorant children, who's idea of reality is akin to Peter Pan's Never 
Never Land!

Real Machines, Real Operating Systems, and yes, Real Programmers still 
exist in the MF world!   :)

Edward Wolfgram

On Thu, 03 Jul 2003 07:58:07 -0700, Eric Lee Green <eric@badtux.org> wrote:

>Component re-use. An oft-touted, but seldom-exercised, capability of
>component-based software architectures.

Comes natural to us Forth-ers...whenever you're writing a word (routine)
that looks useful you try to make it as general as possible with re-use
in mind.   That's part of the Oberon philosophy too - a component, once
compiled, is available to all applications.

-- 
Cheers,
Stan Barr     stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)

The future was never like this!

In article <3f0445c3_6@corp.newsgroups.com>,
Eric Lee Green  <eric@badtux.org> wrote:
> Peter da Silva wrote:
> > In article <20030702203222.3fc69ddc.steveo@eircom.net>,
> > Steve O'Hara-Smith  <steveo@eircom.net> wrote:
> >> It is rare IME for *any* of these to take place in software
> >> development.

> > Just out of curiosity...  what do you see as the analogous step in
> > software development for "a large number of (as nearly as possible)
> > identical units are made"?

> Component re-use.

Preach on, brother! But that's something that you want happening early in
the cycle rather than late, because you have to design for re-use if you're
going to re-use code.

> An oft-touted, but seldom-exercised, capability of
> component-based software architectures. Well, hmm, if you count Unix shell
> scripting as gluing together components, component re-use is a common thing...

I wish it were. I've seen too many scripts like this:

while read line
do
  case $line in 
    *something*) echo $line | sed 's/this/that/'
	;;
    *somethingelse*) echo blahblah
	;;
  esac
done < $file

instead of something like

sed -n \
    -e '/something/s/this/that/p' \
    -e '/somethingelse/s/.*/blahblah/p' \
    < "$file"

> but Unix shell components are rather limited (restricted to operating upon a
> sequential input stream and a sequential output stream both of which are
> comprised of text), and we all know that shell scripts gluing these components
> together *never* have bugs :-).  

The former can be an issue, though the more complex the interface the harder
it is to glue. It's easier to build up a rich generaly-applicable component
toolkit in Scheme than Java. The latter, well, every line of code is a
potential bug, one reason you want to cut down the number of lines.

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

In article <bec993c8.0307030455.18a1c944@posting.google.com>,
Tim Shoppa <shoppa@trailing-edge.com> wrote:
> In the interest of reducing complexity I would be in favor of the short
> script that did the same functionality... but others who manage complexity
> insist that the COTS product is the right solution because we don't have to
> count a single line of its source, nor the hundreds of hours put into
> configuring the COTS product!

"Hey, $APPLICATION is really useful. Can you put it on $SERVER."

"By the way, we need $APPLICATION to do $STUFF..."

"I'm sure you're tired of my having to come to you to make changes to
 $APPLICATION all the time, why don't we use $PRODUCT instead."

"We've bought $PRODUCT, and we needed to hire $NEWGUY to do $OTHERTHING, and
 he's familiar with $PRODUCT. Can you set up a server to run it on."

"$OTHERGUY doesn't have time to support $PRODUCT, so we hired $CONTRACTOR
 to make the changes we need."

"$CONTRACTOR says we really need a couple more servers for $PRODUCT for the
 database and for the test version."

"$PRODUCT has a new version, but we're still making changes to the old one,
 we need another server to test it on."

"People are complaining about $PRODUCT, can you see if you can speed it up?"

"I know you're tired of me asking about $PRODUCT, but we really need a bigger
 server for the new version and that should solve the speed problems."

"$CONTRACTOR needs help with the performance, could you have a look?"

"$MANAGER just approved the upgrade for $PRODUCT, can you find room for
 two more big servers?"

"Yeh, I know it's taking a lot of time, but isn't it better than having
 to make changes to $APPLICATION all the time?"

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

In article <5EDMa.59$I8.472@rwcrnsc53>,
Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>I think, then, that you have to look at the actual complexity of the data.
>A million digits of 0 has no complexity, while a million digits of pi could
>be considered to have complexity.  Though those million digits could be
>generated by a ten line program, so should be considered to have ten lines
>of complexity?   As above, there is some dependence on the compiler.

I realize that this is a generalization, but you have to distinguish
the mathematical 0, the additivity identity, from machine representations.

Funny thing, I just came from a talk given last week by a former
coworker noted for pi.  PLUG: A book on experimental mathematics
(2 vols.) will be coming out in Sept.  BUY THIS BOOK (Bailey)!

2 things strike my memory:
55. A LISP programmer knows the value of everything, but the cost of nothing.

And K&P's: "Do nothing gracefully."

While by char strings, you can add digits to 0 just by concatentation,
from an experimental perspective those are orders of magnitude (factors).
You aren't just saying something about 1 digit, you are saying something
about 10 (base 10 or arbitrary base), this is how it works computing
digits of pi, too.

But these are characterizable (qualitatively: random [e.g., each digit of pi
has a 10% chance of occurance] or constant [0 the next digit]).
Harder, and real complexity, would be something like chaos theory and say
Feigenbaum's constant or something (I'm not into that field, but I think
we should look around a bit).

On Thu, 03 Jul 2003 14:36:21 -0400, Edward Wolfgram
<Edward_Wolfgram@ibi.com> wrote:

>
>Call it culture shock, but I continually shake my head at half the 
>threads in this conference.  Some programmers have not and do not write 
>code as if we were still working on an 8080- I and many others write as 
>if we were *still working on an IBM S370*. Using a reliable operating 
>system, where if you find a bug, it actually gets fixed by the vendor!
>
>I feel like a grownup whose world has been taken over by a bunch of 
>ignorant children, who's idea of reality is akin to Peter Pan's Never 
>Never Land!
>
>Real Machines, Real Operating Systems, and yes, Real Programmers still 
>exist in the MF world!   :)
>
>
In January, I posted an excerpt from an article by Nicholas
Negroponte, "Creating a Culture of Ideas" 
in the February, 2003 issue of Technology Review:

"Innovation is inefficient. More often than not, it is undisciplined, 
contrarian, and iconoclastic; and it nourishes itself with confusion
and contradiction. In short, being innovative flies in the face of
what almost all parents want for their children, most CEOs want for
their companies, and heads of states want for their countries. And
innovative people are a pain in the ass."

http://www.technologyreview.com/articles/negroponte0203.asp

I was mockingly apologetic in posting it to comp.arch then, but I am
reposting it now without apology.

Innovation knows little of age, gender, culture, nationality and
class.  It can be affected by education and experience, but it is
nearly as often affected negatively as positively.

But, you are sputtering, what has this to do with my post?  It falls
to those with education and experience the thankless task of taming
all that energy and turning it into something safe and useful.

If you want something to calm you down about what gets posted to
comp.*, pay a visit to slashdot.org.  After you've finished railing
about how the world has gone to the dogs, think about how much someone
like you has to contribute in a world so full of eager and reckless
energy, and think about how much can be accomplished by communicating
with those full of that energy rather than by condemning them.  They
might have some worthwhile ideas, too. :-).

RM

In article <rl67gvsbq95jlbvufskemk42u1eg7ptnpg@4ax.com>,
Robert Myers  <rmyers@rustuck.com> wrote:
> so claiming that message passing is performance-limited doesn't fly as
> an objection, because I have my choice of arbitrarily fast, plentiful,
> and exotic processors to work with.

Indeed, and there have been other changes in the software design that have
added orders of magnitude of overhead elsewhere in the meantime.

The PDP-11 I worked on in 1980 was fairly slow, but the speed of commands
was comparable to a modest machine running a descendent of the same OS today,
for tasks that weren't computationally intensive.

Part of that is due to the fact that storage hasn't gotten as fast as
processors. But it has sped up quite a lot.

Mostly we're doing a lot more now.

On the PDP-11 the largest programs couldn't have more than 64k of code, and
programs that were close to that were considered big and expensive. Now, a
program might have a that much code just making calls to L11N and I18N
routines, let alone the libraries themselves.

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

In article <3f046e3a$1@news.ucsc.edu>, Eugene Miya <eugene@cse.ucsc.edu> wrote:
>In article <3F044C5E.5020702@cisco.com>,
>J Ahlstrom  <jahlstro@cisco.com> wrote:
>>Eugene Miya wrote:
>>> Message passing from the 60s to today is performance limited.
>>> This is a common criticism (e.g., call by reference vs. call by value)
>>
>>Gerry Weinberg* said (paraphrased)
>>    If it doesn't have to be correct,
>>    I can make it arbitrarily fast.
>
>Oh I had this discussion with my ex-officemate George about thermonuclear
>device development in the 60s and 70s on 6600s and 7600 (machines
>lacking parity).  And in fact they didn't care about correctness.
>They only have to get 2-3 decimal digits of speed/accuracy and
>orders of magnitude (I should have raised more fizzles with him as
>there were quite a few).  From their point of view only academics cared
>about correctness.  Things a little different now.

I recognise the syndrome :-(

>This has never been my view, but I realize the performance-
>functionality balance.  You only have to out run the other guy
>when it comes to bears.

That is true, but the thing I have failed to get across to a lot of
people who claim that is that needing only 2-3 digits of accuracy
is fine, IF you have reason to believe that the failure mode will
be a moderate loss of accuracy.  However, in general, the failure mode
can also be plausible looking but completely bogus results.  

I once did have someone who had given me an earful on this one come
with a problem which, when we resolved it, indicated that he had
indeed been getting completely bogus results.  He then claimed that
there was no chance of him accepting such results as genuine - at
that point, I gave up on him.


Regards,
Nick Maclaren.

In article <be1thv$p9c$2@jeeves.eng.abbnm.com>,
Peter da Silva <peter@abbnm.com> wrote:
>
>> It doesn't matter WHAT they are, but a programmer should be able
>> to look at two sections of code and, if they look similar, they
>> should behave similarly.
>
>When I look at two sections of code and see that they look similar I
>tend to ask myself whether this code should perhaps be reorganised so
>that there's only one such section.

Always a good question, but the answer is often "no".  It is very
common for merging to triple the complexity, because the sections
are similar but with pervasive differences.


Regards,
Nick Maclaren.

On Tue, 01 Jul 2003 10:44:32 -0400, jonah thomas <j2thomas@cavtel.net>
wrote:

>
>To the extent that you can solve software problems by using simple 
>components connected simply in hierarchies (and this doesn't solve 
>everything)

This is, indeed, the achilles heel of encapsulation.  The circumstance
inevitably arises when something higher up in the hierarchy needs to
know something known only to entities that might be much deeper in the
hierarchy.  Even leaving hierarchies out of it, the circumstance will
inevitably arise when one black box needs to know something that
another black box isn't prepared to divulge.

That's when the fun begins.  Interfaces are broken, hierarchies are
scrambled, and, before you know it, you might just as well have
skipped c++ and written the whole thing in c to begin with.

That's why like Orson Welles muttering "Rosebud" on his deathbead in
Citizen Kane, I left the answer vaguely at: "Networks."

Call me simple-minded if you like, but the fact that the internet
works seems like strong evidence for the possibility of building very
robust software systems that are extremely tolerant of inconsistency,
failure, intentional disruption, and error.

I used to call memory compromises "Rocks landing from the moon."  Not
very clever, perhaps, but that's what they felt like, and I was
forever discovering rocks landing from the moon, whether created by me
or by someone else.

On the internet, rocks never land from the moon.  They always come
from somewhere.  Not only that, but the rocks are always labelled.
Systems for detecting and discarding malformed messages are not
perfect, but they get better all the time.

If a URL gets a request it can't respond to, the internet doesn't
crash.  You get a message saying the information you wanted isn't
available in the form that you asked for it.  To make the information
available, the webmaster doesn't have to change the interface in a way
that breaks everything else if he so chooses.

If you need to find something and don't know where it is, all you have
to do is ask google.  Google can't find everything, but it can find
alot.  Google sometimes finds too much, but humans and search agents
get better all the time at using it to unearth the most unlikely
things.

Systems for preventing, trapping, and analyzing suspicious or unwanted
communications aren't perfect, but they get better all the time.

Sophisticated tools already exist for writing software on a
peer-to-peer or client-server model.  While my network is connected to
the internet, security makes distributed computing very complicated.
If I unplug it from the internet, I could easily write, compile, and
test a program spread across my intranet without ever once bringing
all the pieces together.

Programs that interact peer-to-peer or client-server, don't of course,
have to be on different machines, and there are probably better ways
of dealing with internal program communication than the network tools
that currently exist, but to start programming this way *today* you
wouldn't need to invent anything.

Slow?  Maybe.  Inefficient?  Maybe.  But the question wasn't about
speed or efficiency, it was about the possiblity of dealing with
complexity.

RM

Nick Maclaren wrote:

> That is true, but the thing I have failed to get across to a lot of
> people who claim that is that needing only 2-3 digits of accuracy
> is fine, IF you have reason to believe that the failure mode will
> be a moderate loss of accuracy.  However, in general, the failure mode
> can also be plausible looking but completely bogus results.  

Eugene was talking about thermonuclear device development.

So the failure mode is either moderate loss of accuracy or complete blow up.

Now why can't that happen in the program itself, instead of the device 
that's build according to the specs computed by said program ?

I know that in weather forecasting you *cannot* have completely bogus 
results, because the PDE integrator that's the heart of the thing will 
have blown up completely before it starts getting out of hand.

To prevent segmentation faults due to addressing arrays out of bounds, 
we added two very simple checks at the end of every time step:

1. Wind speed does not exceed the speed of sound.

2. Pressure tendency > 10 hPa / hour at the surface is bogus.

Ta Da - problem solved.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
<Snip>
> A worse problem is branching chains, where you can get paths that
> cannot be reliably reproduced.  If one is taken one time in a
> million, unpredictably, then it is quite likely to have an undetected
> bug.  If your use then increases its probability to one time in
> a thousand, you may go bananas where none of the other sites have
> the problem.
<Snip>

"Once in a million happens several times a day around here." Once in
10^27 might cause such problems.

-- 
Walter It is difficult to get a man to understand something," wrote
Upton Sinclair, "when his salary depends upon his not understanding it."
Walter

Robert Myers <rmyers@rustuck.com> wrote:

> On Wed, 02 Jul 2003 17:02:25 -0400, Edward Wolfgram
> <Edward_Wolfgram@ibi.com> wrote:
> 
> >
> >10,000,000 lines of code-
> >
> >at 30 lines/day
> >at 240 days/year
> >at $100,000 year =
> >
> >$139,000,000
> >
> >About the cost of a 747.
> >
> >Edward Wolfgram
> >
> 
> To put the comparison on a more apples-to-apples basis, the
> usually-cited original development cost of the 747 is $1 billion, a
> figure that cannot include the cost of developing the engine, because
> the cost of developing an entirely new jumbo-jet class engine is at
> least $1 billion.
> 
> I can't find reliable numbers for what would pass for the actual
> development costs of the 747 in fixed dollars, but I will bet that
> they significantly exceeded $1 billion in 2003 dollars.
> 
> As to the cost of developing a jumbo jet engine, Fortune gives some
> good recent numbers and some interesting insight:
> 
> 
http://216.239.39.100/search?q=cache:DiNhst-9ibIJ:www.fortune.com/fortun
e/imt/0,15704,401273,00.html+%22jet+engine%22+billion++%22development+co
sts%22&hl=en&ie
> 
> "The 115B is not a completely new design. The first GE90s went into
> service in 1995. But after spending some $2 billion developing them,
> GE is putting as much as $600 million more into this version. And
> that's just part of what GE's aircraft engine managers call the most
> ambitious product and technology development program in their history.
> At a time when the airlines, GE's principal customers, are nosediving
> toward bankruptcy, trailing plumes of burning cash, the company has a
> dozen new or updated engines under development. Outsiders might well
> wonder whether GE has jettisoned common sense. But it doesn't have a
> lot of choice. Engines, often sold at breakeven or at a loss, are not
> where this business makes its money. They are a means to an end: parts
> and service revenues, which will account for 40% of the business's
> $10.6 billion in sales this year and possibly as much as two-thirds of
> its $2.1 billion in operating profit."
> 
> RM

My goodness, what a major upscale of the give away the razor and gouge
on the blades play.

-- 
Walter It is difficult to get a man to understand something," wrote
Upton Sinclair, "when his salary depends upon his not understanding it."
Walter

In article <1219gvs9hnjs4f5pjqv7ep0urhhhjg0j9n@4ax.com>,
Robert Myers  <rmyers@rustuck.com> wrote:
> That's when the fun begins.  Interfaces are broken, hierarchies are
> scrambled, and, before you know it, you might just as well have
> skipped c++ and written the whole thing in c to begin with.

That's why it's so important to find the right way to factor the code, and
how throwing out 55,000 lines of code and keeping 5,000 can be progress.

Contrariwise, when you come up with a factoring that really works well over
a long period of time, you want to think really hard about whether you
really need to change it.

And if you're always having problems with a particular division of labour,
then maybe it's a good idea to change how you're doing it.

The UNIX programming model of things stuck together with file descriptors
and later with sockets works pretty well. Sometimes it doesn't, but it
works more often than it doesn't, and you can work on other interfaces
without breaking it and end up with new ones... so you keep sockets and
mmap and don't keep multiplexed files.

Putting URL resolution in the operating system, however, has proven less
of a good idea. Even if the Internet is robust.

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

jonah thomas wrote:
> 
>       [snip...]          [snip...]          [snip...]
> 
> Any arbitrary contraint, arbitrarily obeyed, will do that.
> 
> 3509 REM add A and B, put the result in C
> 3510 LET C = A + B
> 3519 REM send the value of C to the output
> 3520 PRINT C
> 
> A demand for documentation can produce this sort of thing, and yet
> completely undocumented code is not usually good either.
> 
So what you want is literate documentation. Documentation that
actually carries meaning...and describes the purpose of what is
done in the program.

So what LOC's desire to quantify...is "meaningful" lines of code.
But LOC leaves out this quality issue entirely...because it is
very hard to put a number to this. Thus, the LOC metric is just
as useless as the comments in the above program.  IMHO.

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

Bernd Felsche wrote:
> 
>        [snip...]          [snip...]          [snip...]
> 
> Most other code I've seen simply trusts the inputs and never checks
> return codes from functions. They simply accept that the data is
> sane... so they only have up to 20% error checking... often; none.
> There are lots of lines of code; plenty of comments that confuse;
> not elucidate.
> 
> And I've dealt with all sort from structural design to banking
> software. I've seen cheque numbers overflowing into amount fields;
> and yk2 "years" of over 100 doing pretty much the same thing.
> I've seen function results that are NAN being used for further
> computation; without checking.
> 
I've seen people with moles so big...they have moles of their own.

I had the flu, and the croop, and the whooping-cough, and I can't
count the times that I've had a cold...and a sore throat. *Not*
to mention all the times that I cut my fingers on a sardine can...

I've seen managers make decisions based on metrics that are worthless.

"I've seen so many things that I ain't never seen before.
 Don't turn on the lights...'cause I don't want to see no more."

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

J Ahlstrom wrote:
> 
>        [snip...]          [snip...]          [snip...]
> 
> *Gerald Weinberg's Psychology of Computer Programming
> has the story of a programmer who was flown in to help debug
> a troubled program. After several days, he concluded the situation was
> hopeless, but on the flight home he realized what the problem was.
> 
> When he was trying to convince the original programmers,
> the original creator asked,
>      "And how long does your program take?"
> 
> "About 10 seconds per input."
> 
> "Aha! But my program takes only one second per input." The veteran
> leaned back satisified that he had stumped the upstart.
> 
> "But your program doesn't work.
> If mine doesn't have to work, I can make it
> run instantly and take up no memory."
>
Like the man who wanted to buy a car. He went to a dealer
and ask the price of a particular model.

The dealer said:  "I'll sell you this one for $50,000."

The man said:  "But the dealer down the street sells the
same car for only $30,000."

The dealer:  "Then why don't you buy the car from him???"

The man:  "He does *not* have any in stock."

The dealer:  "Well, when I don't have them in stock, I
sell them for $20,000."

-----

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

Don Chiasson wrote:
> 
>        [snip...]          [snip...]          [snip...]
> >
> But a computer program is made up of only two components, ones
> and zeroes in about equal parts. All that is required it to sort
> them into the correct order.
> 
But which comes first...the one or the zero???   ;-)

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

On Thu, 3 Jul 2003 22:21:51 +0000 (UTC), peter@abbnm.com (Peter da
Silva) wrote:

>
>Putting URL resolution in the operating system, however, has proven less
>of a good idea. Even if the Internet is robust.

I was using the operation of the internet as a counterexample by
construction that the proposition that started this thread is false.
To do that, I felt that I had to wave my hands at least a little bit
to indicate why I think the things that make the internet work have
relevance to everyday programming.  I was not, by any means,
suggesting that URL resolution or any of the other mechanism of the
internet be subsumed into an operating system!

There are existing systems, like CORBA, that seem to provide all the
functionality that is needed for high-level encapsulation.

Nevertheless, I think the internet is a powerful metaphor whose
usefulness exceeds demonstrating that the premise of this thread is
false.  There is, for example, no MAIN program on the internet.

The idea that grabs me the most is that, as long as you can find
servers and get them to respond, you can get as much usefulness out of
the internet as is relevant to you, even if whole swaths of the
internet are down or most servers produce pages filled with useless
nonsense.

RM

Robert Myers wrote:
> In January, I posted an excerpt from an article by Nicholas
> Negroponte, "Creating a Culture of Ideas"
> in the February, 2003 issue of Technology Review:
> http://www.technologyreview.com/articles/negroponte0203.asp
> 

  http://paul.rutgers.edu/~dnicules/text/innovation_in_america.html

is another less restricted place to read this article.

On Thu, 03 Jul 03 08:56:54 GMT, jmfbahciv@aol.com wrote:

<snip<
>Think about a magtape full of files.  Now your job is to put a
>checksummed directory at BOT of the contents of that tape.
>Note that a magtape can only be written from beginning to end.
Not all.
>How do you put a directory of the tape at BOT (beginning of tape)
>when you haven't written the tape yet?

For most 9-track systems, it is possible to to that. If you leave
sufficient space.  Also, some 9-track drives have a block edit
feature.  Read the block, backspace, WriteEdit.

Some backup program that I have used, used to rewind the tape an write
an index at the front.  I think it used an 8mm exabyte drive.


-- 
Arargh at [drop the 'http://www.' from ->] http://www.arargh.com
Basic Compiler Samples Page: http://www.arargh.com/basic/basic.html

To reply by email, change the domain name, and remove the garbage.

On Thu, 03 Jul 2003 18:23:20 -0500, Larry__Weiss <lfw@airmail.net>
wrote:

>Robert Myers wrote:
>> In January, I posted an excerpt from an article by Nicholas
>> Negroponte, "Creating a Culture of Ideas"
>> in the February, 2003 issue of Technology Review:
>> http://www.technologyreview.com/articles/negroponte0203.asp
>> 
>
>  http://paul.rutgers.edu/~dnicules/text/innovation_in_america.html
>
>is another less restricted place to read this article.

Thanks so much.  When I posted the first time, the full text was
available to everyone from the link I provided, and the full article
does a much better job of responding to Edward Wolfgram's post than
the excerpt I provided.

RM

Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de> wrote:

>> The particular knowledge was quite old and had fallen out of use.  
>
>...which it shouldn't have. Hey, I worked as an undergraduate at CERN,
>and listened in to discussion of the advantages and disadvantes of using
>Beryllium for the beam pipe.

     I can not speak for whether it was reasonable in actuality, but
the story presented it in a believable manner.  One of the characters
theorised that the toxicity problem was run into early, solved by
using other materials, and then the data was lost.  No one could think
of a current use of Be.  There were a few cases where they thought it
was used in earlier technology but discontinued, but they did not know
why.

     That is how formerly-valuable data can be lost.  I believe that
scientists had to redevelop the technology behind the creation of some
Stone Age tools.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.

J Ahlstrom <jahlstro@cisco.com> wrote:

[snip]

>Gerry Weinberg* said (paraphrased)
>    If it doesn't have to be correct,
>    I can make it arbitrarily fast.
>
>JKA
>
>*Gerald Weinberg's Psychology of Computer Programming
>has the story of a programmer who was flown in to help debug
>a troubled program. After several days, he concluded the situation was
>hopeless, but on the flight home he realized what the problem was.

[snip]

>"But your program doesn't work.
>If mine doesn't have to work, I can make it
>run instantly and take up no memory."

     That story is also related in "Code Complete".

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.

Steve O'Hara-Smith <steveo@eircom.net> wrote:

>On Thu, 03 Jul 2003 03:28:11 GMT
>Charles Richmond <richmond@ev1.net> wrote:
>
>CR> If you take Viagra, the source listing for your code
>CR> will be *two* inches thicker!!! How many LOC does that add???

     A 12" thick box could be, what, 3500 pages?  Assuming that and 60
lines per page gives 35,000 +/-.

>	Just send five lines of code to each of the addresses below and
>you will soon receive more code than you can ever compile ,,,

     What?  No statement about it being more satisfying?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.

ararghNOSPAM@NOT.AT.enteract.com wrote:
> On Thu, 03 Jul 03 08:56:54 GMT, jmfbahciv@aol.com wrote: 
> <snip<
>>Think about a magtape full of files.  Now your job is to put a
>>checksummed directory at BOT of the contents of that tape.
>>Note that a magtape can only be written from beginning to end.
> Not all.

Not most, nowdays. Of modern SCSI tape drives, the only one that doesn't have
partition support is the Quantum DLT family. The rest allow you to divide the
tape into at least two partitions, one of which can be placed at the beginning
of the tape for your directory if so desired. 

>>How do you put a directory of the tape at BOT (beginning of tape)
>>when you haven't written the tape yet?
> 
> For most 9-track systems, it is possible to to that. If you leave
> sufficient space.  Also, some 9-track drives have a block edit
> feature.  Read the block, backspace, WriteEdit.
> 
> Some backup program that I have used, used to rewind the tape an write
> an index at the front.  I think it used an 8mm exabyte drive.

Modern SCSI tape drives use partitions to do this. Each partition can only be
written beginning to end, but you can switch between them. I considered using
the partitioning support for a backup program that I architected, but DLT was
very popular at the time and it was not feasible to do so.

Disclaimer: I'm the guy who added full partitioning support to the Linux tape
driver... there's three different "standards" that have been adopted (two DAT
"standards", and the "real" standard), and it was a pain in the rear to make
the code smart enough to recognize which "standard" it was talking to. But the
partitioning ioctl only allows two partitions (some tape drives support more
than that), a minor limitation, really, considering that DLT doesn't do it at
all.  

-- 
Eric Lee Green  mailto:eric@badtux.org
Unix/Linux/Storage Software Engineer needs job -- 
see http://badtux.org for resume


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

In article <3F049817.7070701@moene.indiv.nluug.nl>,
Toon Moene <toon@moene.indiv.nluug.nl> writes:
|> Nick Maclaren wrote:
|> 
|> > That is true, but the thing I have failed to get across to a lot of
|> > people who claim that is that needing only 2-3 digits of accuracy
|> > is fine, IF you have reason to believe that the failure mode will
|> > be a moderate loss of accuracy.  However, in general, the failure mode
|> > can also be plausible looking but completely bogus results.  
|> 
|> Eugene was talking about thermonuclear device development.
|> 
|> So the failure mode is either moderate loss of accuracy or complete blow up.

That is the failure mode of the device, not the program.

|> Now why can't that happen in the program itself, instead of the device 
|> that's build according to the specs computed by said program ?

It can.  But I wasn't referring to that.

|> I know that in weather forecasting you *cannot* have completely bogus 
|> results, because the PDE integrator that's the heart of the thing will 
|> have blown up completely before it starts getting out of hand.

Oh, come off it!  You aren't THAT naive!

|> To prevent segmentation faults due to addressing arrays out of bounds, 
|> we added two very simple checks at the end of every time step:
|> 
|> 1. Wind speed does not exceed the speed of sound.
|> 
|> 2. Pressure tendency > 10 hPa / hour at the surface is bogus.
|> 
|> Ta Da - problem solved.

I am NOT TALKING about segmentation faults and similar - I am
talking about numerics.


If a numerical calculation goes completely haywire, the most common
failure mode is SIGFPE on systems that trap it and complete chaos
on ones that don't.  The second most common is results that are
'obviously' bogus.  But the third is to produce results that LOOK
OK, but actually are self-consistent, incorrect and misleading.

When doing RESEARCH (i.e. you don't already know the answer), the
last one is the threat.  Sometimes you can cross-check, but computers
are increasingly being used for analyses where you can't do the
experiment.  Ouch.

This problem is made worse by the cases where the test data give
adequate stability (i.e. 2-3 digits), but the 'real' data are
larger and trip into the nonsense result domain.  I have seen that
happen, and in cases where the result looked plausible.

This is why some people favour interval arithmetic, others favour
using a variety of arithmetics, and yet others favour relying less
on computers and more on numerical analysts.  None of those is an
adequate solution.


Regards,
Nick Maclaren.

In article <20030702200719.495063aa.steveo@eircom.net>,
   Steve O'Hara-Smith <steveo@eircom.net> wrote:
>On Wed, 02 Jul 2003 12:36:00 GMT
>Joe Seigh <jseigh_01@xemaps.com> wrote:
>
>JS> The not reproducible is a major cop out.  I'm suprised that most
>JS> vendors are allowed to get away with this excuse but apparently they
>JS> do.
>
>	It's really hard to fix something when you cannot make it go
>wrong, it's even harder to know if you have fixed it.

That last one aged everybody.  All you might be able to do is
verify it went away.  Of course, nothing verifies that another
bug now exists.


/BAH

Subtract a hundred and four for e-mail.

In article <3F042C3E.5020909@cavtel.net>,
   jonah thomas <j2thomas@cavtel.net> wrote:
>jmfbahciv@aol.com wrote:
>>    "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote:
>>>(Nick Maclaren) writes:
>
>>>>By splitting programs into functions of at most 20 lines long (yes,
>>>>seriously), you may be able to understand every function at a glance.
>>>>You will not, however, be able to understand their interactions.  So
>>>>you split the program into separate ones of at most 20 functions,
>>>>and can now understand every program.  But you will not be able to
>>>>understand the network of programs.  And so on.
>
>>>This is the fundamental failing of the Structured Programming
>>>zealots.  They didn't eliminate complexity; they just moved it
>>>from individual modules to the relationships between them.  
>
>> IMO, that immediately adds another layer of complexity.
>> When people put idiotic constraints on a routine such as
>> 20 line or less, it's time to put the power button.
>
>Any arbitrary contraint, arbitrarily obeyed, will do that.
>
>3509 REM add A and B, put the result in C
>3510 LET C = A + B
>3519 REM send the value of C to the output
>3520 PRINT C
>
>A demand for documentation can produce this sort of thing, and yet 
>completely undocumented code is not usually good either.
>
>It's good to break programs up into pieces that make sense.  A bunch of 
>small pieces that each make sense, called by small higher-level routines 
>that each make sense, etc -- that's a good thing.  A 500-line program 
>broken up into 30 20-line-or-less segments whose only purpose was to 
>follow a rule, would be utterly stupid.

I'm not a good programmer.  However, the only time I made a 
piece of code a subroutine was when I needed the code more than
twice.  I can debug two copied of a piece of code twice without
fucking up.  When it gets to debugging the same code three times,
I get bored and dump it into a subroutine call.  

And I don't care how small or how big that subroutine is.  If
it's a piece of code that requires me to understand computer
arithmetic once, it goes into a subroutine because arithmetic
is a "guy thing".  IOW, I don't do it well so I would rather
only do it once and be done with it.

I can't think of any other reason to mush code into a subroutine
other than minimizing debugging and testing.  This line number
thing is making me throw up [barfing emoticon runs to the bathroom].
I can't believe that anybody even thought of it.  Huff...huff...huff.

/BAH


Subtract a hundred and four for e-mail.

In article <t7e1eb.g75.ln@innovative.iinet.net.au>,
   Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
>jonah thomas <j2thomas@cavtel.net> writes:
>
>>It's good to break programs up into pieces that make sense.  A
>>bunch of small pieces that each make sense, called by small
>>higher-level routines that each make sense, etc -- that's a good
>>thing.  A 500-line program broken up into 30 20-line-or-less
>>segments whose only purpose was to follow a rule, would be utterly
>>stupid.
>
>I'd have used up the 20 lines just checking a few input parameters
>for sensibility.
>
>Typical program of mine is 80% error checking. If I'm feeling
>especially paranoid, it's 90%.
>
>Most other code I've seen simply trusts the inputs and never checks
>return codes from functions. They simply accept that the data is
>sane... so they only have up to 20% error checking... often; none.

Where the sanity checking is done is a part of the original design
decision...isn't it?  Let me see if I can write this clearly...I'm
having trouble getting it from my head to my fingers.

The sanity check has to be one consistently on either one side or
the other.  (I'm talking about one product now.)  The calling
procedures is one of the first things that has to be designed before
any other design takes place.  

/BAH

<snip>

Subtract a hundred and four for e-mail.

In article <3F04C7C1.D1EB1980@ev1.net>,
   Charles Richmond <richmond@ev1.net> wrote:
>jmfbahciv@aol.com wrote:
>> 
>>       [snip...]         [snip...]         [snip...]
>> 
>> JMF was very proud that his program typed a dot on the TTY paper.
>> Not many people understood the sophistication, complexity or
>> man-centuries of work that went into that dot.
>> 
>It's like the birth and death dates on a tombstone. The dash
>that separates the two dates...repesents the entire life of
>the person. It all sounds very "Zen"...

Unless you write a hint on the tombstone.  If I have any
say about what goes on mine, it will have the words:
I finally finished something.

/BAH


Subtract a hundred and four for e-mail.

In article <3F0477A5.8060101@ibi.com>,
   Edward Wolfgram <Edward_Wolfgram@ibi.com> wrote:
>> The original claim was:
>> 
>> "If we don't find a different way of thinking about and creating
>> software, we will not be writing programs bigger than about 10 million
>> lines of code, no matter matter how fast, plentiful or exotic our
>> processors become."
>> 
>> so claiming that message passing is performance-limited doesn't fly as
>> an objection, because I have my choice of arbitrarily fast, plentiful,
>> and exotic processors to work with.
>> 
>> And I think this (along with the Forrest curve) really gets to the
>> heart of the matter.  If we've got power to burn, then let's burn it
>> building safer code.  If we build safer code, we will be able to build
>> more complex code.
>> 
>> In some primitive sense, the orignal proposition was literally
>> correct, because the (wrong) way that programmers are now thinking
>> about writing code is as if they were still working with an 8080 and
>> 64K of memory, and that does need to change.
>> 
>> ... 
>
>Call it culture shock, but I continually shake my head at half the 
>threads in this conference.  Some programmers have not and do not write 
>code as if we were still working on an 8080- I and many others write as 
>if we were *still working on an IBM S370*. 

That's not culture shock; culture shock is asking a CompUSA about
plugging into a 386 and the guy not knowing what you're talking about.

> ..Using a reliable operating 
>system, where if you find a bug, it actually gets fixed by the vendor!

Bingo!  When I started doing this newsgroup thing, my goal became
to spread the word that an OS is not supposed to die nor cause you
to have to restore the system.

>
>I feel like a grownup whose world has been taken over by a bunch of 
>ignorant children, who's idea of reality is akin to Peter Pan's Never 
>Never Land!

That's the reason I post to a.f.c.  Teaching the kiddies.  If someone
doesn't know it exists, they may never know how to make it.
>
>Real Machines, Real Operating Systems, and yes, Real Programmers still 
>exist in the MF world!   :)

If we're a dying breed, we had better get started propogating those
bits.

/BAH

Subtract a hundred and four for e-mail.

In article <g0b3eb.ebu1.ln@acer>,
Morten Reistad <mrr@reistad.priv.no> writes:
|> 
|> I see that "message passing" is back to buzzword status again. In a sense
|> the Internet uses a lot of "message passing"; but we got beyond the
|> buzzwords and made a real implementation around 20 years ago. It is
|> called IP. 

From the point of view of dealing with complexity, IP is an example
of a REALLY BAD message passing protocol.  Its faults are legion,
but the crippling error is the lack of support for diagnostics.
And that is a design and not an implementation issue.


Regards,
Nick Maclaren.

In article <3F056B13.1020506@cavtel.net>,
   jonah thomas <j2thomas@cavtel.net> wrote:
>jmfbahciv@aol.com wrote:
>
>> I'm not a good programmer.  However, the only time I made a 
>> piece of code a subroutine was when I needed the code more than
>> twice.  I can debug two copied of a piece of code twice without
>> fucking up.  When it gets to debugging the same code three times,
>> I get bored and dump it into a subroutine call.  
>
>If you do the same thing twice, and somebody else winds up maintaining 
>it, there's a strong chance that sometime later they'll change one copy 
>and not the other. 

Yes, that's good.

> .. That might half-way fix something, or it might just 
>make them diverge.  So then when a third guy comes in, he *can't* put 
>them together because they're different and for all he knows they're 
>subtly different and it would turn into a mess.  So he's stuck with two 
>versions that will keep on diverging, and every time he makes a change 
>in one copy he *ought* to think about whether the other copy needs it or 
>not, but there's a strong chance he won't notice.

And you can play this game until each and every instruction of a
program is a subroutine.  There are logical steps to a progem; that's
why I mourn the disfavor of teaching flow charts in school.

>Of course the other side of that is that you can make one routine and 
>call it twice, and then when the first guy sees he needs a change for 
>one source and not the other he adds a flag to the input and does a 
>conditional inside it, and after awhile you have one mess with lots of 
>conditionals.

No, NO, NO! NO!!!!!!  That's not how you do that!!!!  If he sees
he needs a slight modification to a subroutine, he 

1. copies it and makes it inline code
2. copies it, does the mods, and makes it another subroutine that
called a different name.

>There's no way you can make sure somebody else doesn't mess it up.  The 
>most you can do is make it easy for them to see what you've done.
>
>> And I don't care how small or how big that subroutine is.  If
>> it's a piece of code that requires me to understand computer
>> arithmetic once, it goes into a subroutine because arithmetic
>> is a "guy thing".  IOW, I don't do it well so I would rather
>> only do it once and be done with it.
>
>> I can't think of any other reason to mush code into a subroutine
>> other than minimizing debugging and testing.  
>
>That's an important enough reason for me.  Test the simplest subroutines 
>first to make sure they do what you said they would.  Then test the 
>short routines that call them. 

Man, you're still hung up on numbers.

> .. Then test the short routines that call 
>those.  Testing isn't everything but it's enough worth doing to make it 
>worth breaking things into little pieces.

You can't do this if your programming style is top down.  And testing
is never a reason (I haven't about this statement enough) to
break things up into itsy bitsy pieces of code.

Hint:  Testing does not equal debugging.

/BAH


Subtract a hundred and four for e-mail.

In article <3f056161.2880040@news.ocis.net>,
   genew@mail.ocis.net (Gene Wirchenko) wrote:
>jmfbahciv@aol.com wrote:
>
>[snip]
>
>>Unless you write a hint on the tombstone.  If I have any
>>say about what goes on mine, it will have the words:
>>I finally finished something.
>
>     Oh, you will have a say.  Whether you will be able to do proper
>project management on it is another story.

<GRIN>   That would be the ultimate irony; my comment about 
finishing never getting finished.  A double layer of humor.

/BAH

Subtract a hundred and four for e-mail.

In article <6isagvsn6l05i3jcj373jkr5v8sb6akmdv@4ax.com>,
   Robert Myers <rmyers@rustuck.com> wrote:
>On Fri, 4 Jul 2003 09:40:00 +0200, Morten Reistad
><mrr@reistad.priv.no> wrote:
>
>>
>>This is where I came up with an example or two. The basic code-size
>>of what we normally call "u*ix"; either BSD plus utilities og Linux
>>plus GNU; plus X; starts at around 15 MIO lines of code.
>>
>>This is a baseline. With 'u*ix' you start from there. And it is
>>sufficiently close and integrated to be called "a program", although
>>most of it actually has two competing implementations.
>>
>>I would give this baseline an *excellent* bill of health. I cannot 
>>see that it poses any major impediment on other closely integrated
>>systems software at all. The total amount of code on a "fully installed"
>>machine is around 50 mio lines of code, and it works pretty well as
>>a unit.
>>
>Agreed.
>
>>>> so claiming that message passing is performance-limited doesn't fly as
>>>> an objection, because I have my choice of arbitrarily fast, plentiful,
>>>> and exotic processors to work with.
>>>> 
>>>> And I think this (along with the Forrest curve) really gets to the
>>>> heart of the matter.  If we've got power to burn, then let's burn it
>>>> building safer code.  If we build safer code, we will be able to build
>>>> more complex code.
>>
>>Writing purposefully inefficient code is not a solution. Java has
>>so far been a huge disapointment for me; the project coming from
>>that corner is just en endless series of slow bloat that is even
>>fuller of bugs than the C they were replacing.  
>>
>"Writing purposefully inefficient code" is a very strange distortion
>of what I proposed.  If we have processor power to burn, then we have
>more time to do sanity checks and we can limit ourselves to structured
>pathways for control and data, even though they might not be the most
>efficient.

Not if you need the results of the computation yesterday.  
Not if the problem isn't computable.

>
>You can write good code in any language you want, and you can write
>bad code in any language you want.  Someone whose preference is to
>write in assembler and who is disciplined and competent can write
>transparent, safe, and easily debugged code in assembler.  Writing in
>Java makes certain tasks and certain kinds of abstraction much easier
>and helps with portability, but it doesn't necessarily make the code
>any safer or even any more readable.
>
>>I see that "message passing" is back to buzzword status again. In a sense
>>the Internet uses a lot of "message passing"; but we got beyond the
>>buzzwords and made a real implementation around 20 years ago. It is
>>called IP. 
>>
>>Using this at the right place is a good idea. But this is not new.
>>
>There may be lots of things that aren't attractive about my thinking
>and posting style, but you can always count on one thing: I don't let
>anyone else do my thinking for me. 

That's too bad.  You apparently need to learn some things.

> .. If I am using "buzzwords", it is
>because I am already idiosyncratic enough in how I think and approach
>problems, and if people are currently using a term to describe a
>particular process that I find attractive, I think I should use that
>term to talk about it, rather than avoiding the term simply because it
>is a buzzword.
>
>The whole point of what I have had to say on this subject is that we
>already know how to most of what needs to be done and that we don't
>have to invent anything new.

Uh-oh.  [emoticon starts to hand out the Kim-Wipes]
>
>On the other hand, styles of programming are changing in important and
>positive ways, and I don't find being stuck in a mainframe mentality
>to be particularly attractive, productive, or helpful.

Being "stuck" in a mainframe mentality is better than being struck
dumb by PCitis.

<snip>

>>>Real Machines, Real Operating Systems, and yes, Real Programmers still 
>>>exist in the MF world!   :)
>>
>>And we can still program in FORTRAN!
>>
>
>I hope that not everyone reading this diatribe thinks that all
>competent FORTRAN programmers are so smug. 

They have a right to be smug; those coders did amazing things and
still are.

> .. Personally, I hated IBM
>machines and IBM operating systems.  I cannot remember one single
>thing about IBM JCL because it was the klutziest, most
>counter-intuitive batch system I ever used.
>
>Everyone needs to vent once in a while, but using terms like
>"buzzword-correct script kiddies" puts you right into the slashdot
>posting style, only in a different age group.

Here's a Kim-Wipe, kid.  You've got snot running out of your nose.

/BAH

Subtract a hundred and four for e-mail.

Nick Maclaren wrote:

> This is why some people favour interval arithmetic, others favour
> using a variety of arithmetics, and yet others favour relying less
> on computers and more on numerical analysts.  None of those is an
> adequate solution.

Would you explain in a little more detail, or point to a link or two? 
This is interesting.

My guess is that interval arithmetic would be inadequate because done 
the obvious way it leads to a combinatorial explosion, and the various 
simplifications give trouble because the results aren't uniform across 
distributions.

Numerical analysts are expensive.

What if you assigned a probability distribution to each input, and then 
randomised the data over multiple runs?  The distribution of answers 
would give some sense of how good a result you should expect from the 
precision of the initial data, and numerical problems would have more 
chance to show up.

The immediate problem I see with that is that you could get stable wrong 
answers, where very small effects are supposed to have a big difference 
but get lost instead.  But when very small effects are vitally 
important, what's the chance that the data is measured precisely enough 
to track them, anyway?  If that sort of thing is a concern I don't see 
any way except numerical analysis to find out that there's a serious 
problem, unless it showed up by changing the inputs.

Is there some fundamental problem I've missed here?  Or is it just that 
my perspective is skewed?

jmfbahciv@aol.com wrote:

[snip]

>Unless you write a hint on the tombstone.  If I have any
>say about what goes on mine, it will have the words:
>I finally finished something.

     Oh, you will have a say.  Whether you will be able to do proper
project management on it is another story.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.

jmfbahciv@aol.com wrote:

> I'm not a good programmer.  However, the only time I made a 
> piece of code a subroutine was when I needed the code more than
> twice.  I can debug two copied of a piece of code twice without
> fucking up.  When it gets to debugging the same code three times,
> I get bored and dump it into a subroutine call.  

If you do the same thing twice, and somebody else winds up maintaining 
it, there's a strong chance that sometime later they'll change one copy 
and not the other.  That might half-way fix something, or it might just 
make them diverge.  So then when a third guy comes in, he *can't* put 
them together because they're different and for all he knows they're 
subtly different and it would turn into a mess.  So he's stuck with two 
versions that will keep on diverging, and every time he makes a change 
in one copy he *ought* to think about whether the other copy needs it or 
not, but there's a strong chance he won't notice.

Of course the other side of that is that you can make one routine and 
call it twice, and then when the first guy sees he needs a change for 
one source and not the other he adds a flag to the input and does a 
conditional inside it, and after awhile you have one mess with lots of 
conditionals.

There's no way you can make sure somebody else doesn't mess it up.  The 
most you can do is make it easy for them to see what you've done.

> And I don't care how small or how big that subroutine is.  If
> it's a piece of code that requires me to understand computer
> arithmetic once, it goes into a subroutine because arithmetic
> is a "guy thing".  IOW, I don't do it well so I would rather
> only do it once and be done with it.

> I can't think of any other reason to mush code into a subroutine
> other than minimizing debugging and testing.  

That's an important enough reason for me.  Test the simplest subroutines 
first to make sure they do what you said they would.  Then test the 
short routines that call them.  Then test the short routines that call 
those.  Testing isn't everything but it's enough worth doing to make it 
worth breaking things into little pieces.

On Fri, 4 Jul 2003 09:40:00 +0200, Morten Reistad
<mrr@reistad.priv.no> wrote:

>
>This is where I came up with an example or two. The basic code-size
>of what we normally call "u*ix"; either BSD plus utilities og Linux
>plus GNU; plus X; starts at around 15 MIO lines of code.
>
>This is a baseline. With 'u*ix' you start from there. And it is
>sufficiently close and integrated to be called "a program", although
>most of it actually has two competing implementations.
>
>I would give this baseline an *excellent* bill of health. I cannot 
>see that it poses any major impediment on other closely integrated
>systems software at all. The total amount of code on a "fully installed"
>machine is around 50 mio lines of code, and it works pretty well as
>a unit.
>
Agreed.

>>> so claiming that message passing is performance-limited doesn't fly as
>>> an objection, because I have my choice of arbitrarily fast, plentiful,
>>> and exotic processors to work with.
>>> 
>>> And I think this (along with the Forrest curve) really gets to the
>>> heart of the matter.  If we've got power to burn, then let's burn it
>>> building safer code.  If we build safer code, we will be able to build
>>> more complex code.
>
>Writing purposefully inefficient code is not a solution. Java has
>so far been a huge disapointment for me; the project coming from
>that corner is just en endless series of slow bloat that is even
>fuller of bugs than the C they were replacing.  
>
"Writing purposefully inefficient code" is a very strange distortion
of what I proposed.  If we have processor power to burn, then we have
more time to do sanity checks and we can limit ourselves to structured
pathways for control and data, even though they might not be the most
efficient.

You can write good code in any language you want, and you can write
bad code in any language you want.  Someone whose preference is to
write in assembler and who is disciplined and competent can write
transparent, safe, and easily debugged code in assembler.  Writing in
Java makes certain tasks and certain kinds of abstraction much easier
and helps with portability, but it doesn't necessarily make the code
any safer or even any more readable.

>I see that "message passing" is back to buzzword status again. In a sense
>the Internet uses a lot of "message passing"; but we got beyond the
>buzzwords and made a real implementation around 20 years ago. It is
>called IP. 
>
>Using this at the right place is a good idea. But this is not new.
>
There may be lots of things that aren't attractive about my thinking
and posting style, but you can always count on one thing: I don't let
anyone else do my thinking for me.  If I am using "buzzwords", it is
because I am already idiosyncratic enough in how I think and approach
problems, and if people are currently using a term to describe a
particular process that I find attractive, I think I should use that
term to talk about it, rather than avoiding the term simply because it
is a buzzword.

The whole point of what I have had to say on this subject is that we
already know how to most of what needs to be done and that we don't
have to invent anything new.

On the other hand, styles of programming are changing in important and
positive ways, and I don't find being stuck in a mainframe mentality
to be particularly attractive, productive, or helpful.

<snip>

>
>>Call it culture shock, but I continually shake my head at half the 
>>threads in this conference.  Some programmers have not and do not write 
>>code as if we were still working on an 8080- I and many others write as 
>>if we were *still working on an IBM S370*. Using a reliable operating 
>>system, where if you find a bug, it actually gets fixed by the vendor!
>>
>>I feel like a grownup whose world has been taken over by a bunch of 
>>ignorant children, who's idea of reality is akin to Peter Pan's Never 
>>Never Land!
>
>I tend to view these newsgroups as a holdout where the world remains
>a little saner. But I concur with the sentiment. 
>
>In my PPOE I had responsability for taking over web-stuff that was
>moved to the ISP to run in production there. This stuff was almost
>exclusively developed by PHB's running a lot of buzzword-correct 
>script kiddies. Lots of Java, databases and huge stuff. This was
>in the middle of the dotcom boom.
>
>Around 3/4ths of these projects never got out of development because
>the software couldn't run without handholding. Failed elementary
>stability and load tests with flying colours. So even if the 
>business cases had been solid (most weren't) they were doomed
>anyhow.
>
>>Real Machines, Real Operating Systems, and yes, Real Programmers still 
>>exist in the MF world!   :)
>
>And we can still program in FORTRAN!
>

I hope that not everyone reading this diatribe thinks that all
competent FORTRAN programmers are so smug.  Personally, I hated IBM
machines and IBM operating systems.  I cannot remember one single
thing about IBM JCL because it was the klutziest, most
counter-intuitive batch system I ever used.

Everyone needs to vent once in a while, but using terms like
"buzzword-correct script kiddies" puts you right into the slashdot
posting style, only in a different age group.

RM

jmfbahciv@aol.com wrote:
>    jonah thomas <j2thomas@cavtel.net> wrote:

>>If you do the same thing twice, and somebody else winds up maintaining 
>>it, there's a strong chance that sometime later they'll change one copy 
>>and not the other. 

> Yes, that's good.

It may mean you didn't break the routine down into small enough pieces.

>>.. That might half-way fix something, or it might just 
>>make them diverge.  So then when a third guy comes in, he *can't* put 
>>them together because they're different and for all he knows they're 
>>subtly different and it would turn into a mess.  So he's stuck with two 
>>versions that will keep on diverging, and every time he makes a change 
>>in one copy he *ought* to think about whether the other copy needs it or 
>>not, but there's a strong chance he won't notice.

> And you can play this game until each and every instruction of a
> program is a subroutine.  There are logical steps to a progem; that's
> why I mourn the disfavor of teaching flow charts in school.

Even when you have a system that supports subroutines with little 
overhead, it seldom makes sense to have subroutines with fewer than two 
instructions.  Seven is better.  And you may want to turn small routines 
into macros.  Primitive hard-to-use languages may make it so tedious to 
factor that it's better to find some other way.  But the general rule 
is, make each subroutine do exactly one thing.  Where "one thing" is one 
thing in your mind.

There's nothing wrong with flowcharting with subroutines.

check_inputs
if( ROI_positive) guess_price_rise else check_tax_advantage then
maybe_sell_now

Your branches and loops will look cleaner.

>>Of course the other side of that is that you can make one routine and 
>>call it twice, and then when the first guy sees he needs a change for 
>>one source and not the other he adds a flag to the input and does a 
>>conditional inside it, and after awhile you have one mess with lots of 
>>conditionals.

> No, NO, NO! NO!!!!!!  That's not how you do that!!!!  If he sees
> he needs a slight modification to a subroutine, he 

Of course it's wrong.  No matter how you do it the other guy might do it 
wrong.

> 1. copies it and makes it inline code
> 2. copies it, does the mods, and makes it another subroutine that
> called a different name.

3.  Break it into routines that each do one thing.  Re-use most of them 
in both new routines.  Done well it will be clearer what's going on and 
there will be less repeated code that might need to be changed twice. 
Done badly you get an unmaintainable mess, with any of our three approaches.

>>>I can't think of any other reason to mush code into a subroutine
>>>other than minimizing debugging and testing.  

>>That's an important enough reason for me.  Test the simplest subroutines 
>>first to make sure they do what you said they would.  Then test the 
>>short routines that call them. 

> Man, you're still hung up on numbers.

>>.. Then test the short routines that call 
>>those.  Testing isn't everything but it's enough worth doing to make it 
>>worth breaking things into little pieces.

> You can't do this if your programming style is top down.  

Why not?  Top down, you break the problem into pieces that each do one 
thing.

repeat: get_allowable_input process_data present_results ;

Not this general, but at the level you're thinking at your top.  Then 
you break each one down into smaller routines.  If you have a good 
top-down style you'll wind up with low-level routines you can code and 
it will be all good.

> And testing
> is never a reason (I haven't about this statement enough) to
> break things up into itsy bitsy pieces of code.

> Hint:  Testing does not equal debugging.

It's early in the morning and this reminded me of an old joke.
A man went to the mosque to pray, and he noticed that a known thief was 
praying beside him.  So he didn't take off his shoes.  The thief told 
him, "Prayers with shoes on do not abide."  The man ignored that.  The 
thief again intoned, "Prayers said with shoes on do not abide!"  The 
third time, the man replied, "No, they don't.  But perhaps at least the 
shoes will abide."

Testing cannot prove that your code is correct.  But it can show that 
your code does what you thought you told it to, which is at least 
something.  And the quicker you get that settled the better.

In article <3F05675D.1060006@cavtel.net>, jonah thomas <j2thomas@cavtel.net> writes:
|> Nick Maclaren wrote:
|> 
|> > This is why some people favour interval arithmetic, others favour
|> > using a variety of arithmetics, and yet others favour relying less
|> > on computers and more on numerical analysts.  None of those is an
|> > adequate solution.
|> 
|> Would you explain in a little more detail, or point to a link or two? 
|> This is interesting.

You seem to understand the issue!  It is always worth looking at
Kahan's papers on the subject - try a Web search.

|> My guess is that interval arithmetic would be inadequate because done 
|> the obvious way it leads to a combinatorial explosion, and the various 
|> simplifications give trouble because the results aren't uniform across 
|> distributions.

Yes, except that the uniformity isn't an issue when dealing only
with worst possible cases.

|> Numerical analysts are expensive.

And scarce.  And it takes time to analyse a program, even when it
is possible.

|> What if you assigned a probability distribution to each input, and then 
|> randomised the data over multiple runs?  The distribution of answers 
|> would give some sense of how good a result you should expect from the 
|> precision of the initial data, and numerical problems would have more 
|> chance to show up.

See Kahan :-)  That is a good way of picking up input-dependent
problems, but you need more in general.  You can use probabilistic
rounding, which is better, but Kahan correctly points out it isn't
perfect.  I think he maligns it, though.

|> The immediate problem I see with that is that you could get stable wrong 
|> answers, where very small effects are supposed to have a big difference 
|> but get lost instead.  But when very small effects are vitally 
|> important, what's the chance that the data is measured precisely enough 
|> to track them, anyway?  If that sort of thing is a concern I don't see 
|> any way except numerical analysis to find out that there's a serious 
|> problem, unless it showed up by changing the inputs.

The main problem is numerical instability (now often called chaotic
behaviour).  You can end up with results that contain little or no
information, but merely tell you the attractors and which ones the
input selects.

|> Is there some fundamental problem I've missed here?  Or is it just that 
|> my perspective is skewed?

A bit of the latter.  You could track down some things on numerical
instability problems for more information.


Regards,
Nick Maclaren.

jmfbahciv@aol.com wrote:
>    jonah thomas <j2thomas@cavtel.net> wrote:
>>jmfbahciv@aol.com wrote:
>>>   jonah thomas <j2thomas@cavtel.net> wrote:

>>>>If you do the same thing twice, and somebody else winds up maintaining 
>>>>it, there's a strong chance that sometime later they'll change one copy 
>>>>and not the other. 

>>>Yes, that's good.

>>It may mean you didn't break the routine down into small enough pieces.

> [emoticon begins to hit head against brick wall so things feel better]
> I'm going to forego the crude analogy.  Take a cake recipe that has
> 10 ingredients.  If I do what you suggest, then I bake each ingredient
> separately and should expect an edible cake when at the end of the
> day.  

Measure each ingredient separately, then add it to the mix.
Combine them first, then bake them.
You don't need to put each ingredient into the cakepan when it's already 
in the hot oven.  Separate the steps.

There's nothing wrong with a cookbook explaining how to measure in one 
section and how to grease a cake pan somewhere else.  A recipe that 
refers to standard techniques on other pages, has subroutines.

>>There's nothing wrong with flowcharting with subroutines.

> NOOOOOOOO!!!!!!

>>check_inputs
>>if( ROI_positive) guess_price_rise else check_tax_advantage then
>>maybe_sell_now
>
>>Your branches and loops will look cleaner.

> You use your variable names as comments?

I use subroutine names as comments.  I left the other comments out of 
those three lines, of course.  Also I left out idiosyncratic 
parameter-passing stuff.

>>Not this general, but at the level you're thinking at your top.  Then 
>>you break each one down into smaller routines.  If you have a good 
>>top-down style you'll wind up with low-level routines you can code and 
>>it will be all good.

> It is possible we are talking past each other about the same thing.
> It is possible; I ain't betting on it.  

> Is this how apps-flavored guys do their designs?

It varies every which way.  For simple things I go bottom-up.  When the 
user interface looks stable I like to do that first and put in stubs, 
then I have a demo very early to pacify people who might need pacifying. 
   A demo is nice because as you get functionality you can add it in and 
they can see results.  With something a bit complex I start at the top 
and the bottom and work toward the middle, but when the core of it looks 
extra clear and the drivers don't look like a problem I'll start in the 
middle and work my way out.

If there are actual specifications that look usable I try to code to 
match them.  I try to code the things that are obvious spec failures 
first so I have examples to pass back to show them why there's a problem.

And if I'm getting micromanaged I do whatever the boss says.

>>Testing cannot prove that your code is correct.  But it can show that 
>>your code does what you thought you told it to, which is at least 
>>something.  And the quicker you get that settled the better.

> I think you may have potential.  I know I don't have the patience...
> nor the tact... to explore it.

Thank you.  I get the impression you're somebody famous, I hope you 
don't mind that I never heard of jmfbahciv.  ;)

Nick Maclaren wrote:

> The main problem is numerical instability (now often called chaotic
> behaviour).  You can end up with results that contain little or no
> information, but merely tell you the attractors and which ones the
> input selects.

If your model is correct and you get numerical instability, how often 
will you get numerical instability in the correct solution?

If the real life problem heads for attractors too, the best you can hope 
for is to get the attractors more-or-less right and get some sort of 
distribution about which ones you'll get attracted to.  Right?

So the ones that could be improved are the ones where your code is 
unstable but the reality it's supposed to model is not....

In article <3F058E43.8040000@cavtel.net>,
jonah thomas <j2thomas@cavtel.net> writes:
|> Nick Maclaren wrote:
|> 
|> > The main problem is numerical instability (now often called chaotic
|> > behaviour).  You can end up with results that contain little or no
|> > information, but merely tell you the attractors and which ones the
|> > input selects.
|> 
|> If your model is correct and you get numerical instability, how often 
|> will you get numerical instability in the correct solution?

You mean that the system is chaotic?  It depends on the method
you are using and the problem, but a model is very often unstable
even when the problem is not chaotic.

|> If the real life problem heads for attractors too, the best you can hope 
|> for is to get the attractors more-or-less right and get some sort of 
|> distribution about which ones you'll get attracted to.  Right?

Because you are modelling a physical system and not mimicking
it, the attractors will be different.

|> So the ones that could be improved are the ones where your code is 
|> unstable but the reality it's supposed to model is not....

No.  That is one cause.  The other is described above.


Regards,
Nick Maclaren.

In article <3f051141_6@corp.newsgroups.com>,
Eric Lee Green  <eric@badtux.org> wrote:
> Modern SCSI tape drives use partitions to do this. Each partition can only be
> written beginning to end, but you can switch between them. I considered using
> the partitioning support for a backup program that I architected, but DLT was
> very popular at the time and it was not feasible to do so.

I imagine that forcing customers to buy a new tape drive just to use your
program would put you at a competitive disadvantage. :)

I've had customers reluctant to upgrade from DDS2 just because their file
systems had gone from megabytes to gigabytes.

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

In article <g0b3eb.ebu1.ln@acer>, Morten Reistad  <mrr@reistad.priv.no> wrote:
> This is a baseline. With 'u*ix' you start from there. And it is
> sufficiently close and integrated to be called "a program", although
> most of it actually has two competing implementations.

Actually I think the point is that it's *not* sufficiently close and
integrated to call it a program. You can pull substantial chunks out of
it and the remainder still does useful work. You can test and debug parts
of it in isolation and you don't have to worry about a change in "ls"
breaking "cat".

It's not comparable to a 747 or an aircraft carrier, but rather to a fleet
of dissimilar aircraft and ships operating together. There's a lot more
parts in the Enterprise, its complement of aircraft, and the ships in convoy
with it than in the Enterprise alone... and it acts together as a unit...
but you wouldn't call it an analog of a "program" in this kind of discussion.

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

jmfbahciv@aol.com writes:

>In article <t7e1eb.g75.ln@innovative.iinet.net.au>,
>   Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
>>jonah thomas <j2thomas@cavtel.net> writes:
>>>It's good to break programs up into pieces that make sense.  A
>>>bunch of small pieces that each make sense, called by small
>>>higher-level routines that each make sense, etc -- that's a good
>>>thing.  A 500-line program broken up into 30 20-line-or-less
>>>segments whose only purpose was to follow a rule, would be utterly
>>>stupid.

>>I'd have used up the 20 lines just checking a few input parameters
>>for sensibility.

>>Typical program of mine is 80% error checking. If I'm feeling
>>especially paranoid, it's 90%.

>>Most other code I've seen simply trusts the inputs and never checks
>>return codes from functions. They simply accept that the data is
>>sane... so they only have up to 20% error checking... often; none.

>Where the sanity checking is done is a part of the original design
>decision...isn't it?  Let me see if I can write this clearly...I'm

What's this "design decision" thing? The bulk of software festers
from bits of code apparently hacked together between beers. Any bugs
are "fixed" by band-aids applied by ignorant minions later in the
product life cycle.

>having trouble getting it from my head to my fingers.

>The sanity check has to be one consistently on either one side or
>the other.  (I'm talking about one product now.)  The calling
>procedures is one of the first things that has to be designed before
>any other design takes place.  

The called procedure/function must "know" its own limitations and is
therefore the most logical place to do input validation. A procedure
may also encounter errors and needs to signal those to the caller.
If the caller ignores the error condition or is unable to determine
that there was an "internal" error and continues, then at the very
least it's wasting computing cycles building garbage.

If you ever wonder why you get odd error messages unrelated to the
real problem, then it's because something hasn't been checking for
error conditions; usually "impossible" ones. As a result, you do
lots of processing with erroneous data which can result in further
data corruption down the line should the data be stored in a shared
or re-usable resource.

Procedures that do sanity checking on the returned values from
functions, in addition to checking error conditions, are typical of
paran^Wrobust programming. The checks are often simple such as
cross-checking relationships in an RDBMS; sometimes they're
complicated like verifying that end conditions are satisfied in
structural analysis.

It's no longer only experts and professionals using highly technical
or business critical software; it's people who seldom understand the
consequences of the data with which they're presented.
-- 
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ /  ASCII ribbon campaign | I'm a .signature virus!
 X   against HTML mail     | Copy me into your ~/.signature
/ \  and postings          | to help me spread!

In article <6isagvsn6l05i3jcj373jkr5v8sb6akmdv@4ax.com>
rmyers@rustuck.com (Robert Myers) writes:

>On Fri, 4 Jul 2003 09:40:00 +0200, Morten Reistad
><mrr@reistad.priv.no> wrote:
>
>>Writing purposefully inefficient code is not a solution. Java has
>>so far been a huge disapointment for me; the project coming from
>>that corner is just en endless series of slow bloat that is even
>>fuller of bugs than the C they were replacing.
>
>"Writing purposefully inefficient code" is a very strange distortion
>of what I proposed.  If we have processor power to burn, then we have
>more time to do sanity checks and we can limit ourselves to structured
>pathways for control and data, even though they might not be the most
>efficient.

I think the point here is not that we shouldn't use all that extra
CPU power for these things.  Rather, we're complaining that it's
_not_ being used there, but instead being squandered on eye candy
and rampant featuritis - all of which only gets in the way, no
matter how much the lusers love it.

>The whole point of what I have had to say on this subject is that we
>already know how to most of what needs to be done and that we don't
>have to invent anything new.

True.  This is why we're so wary of those who advocate change for its
own sake.  Excessive use of buzzwords is a pretty reliable warning
sign that you're dealing with such people, and that's why we get so
suspicious when we see too many buzzwords being used.

>On the other hand, styles of programming are changing in important and
>positive ways, and I don't find being stuck in a mainframe mentality
>to be particularly attractive, productive, or helpful.

Being stuck in it, no.  But having an appreciation for the mainframe
mindset can give us insight into how things got the way the are.
"Those who forget history are doomed to repeat it."  In addition,
there are still many applications where the mainframe mentality is
the best way to do it, or at the very least is a valuable addition
to one's toolkit.

>I hope that not everyone reading this diatribe thinks that all
>competent FORTRAN programmers are so smug.  Personally, I hated IBM
>machines and IBM operating systems.  I cannot remember one single
>thing about IBM JCL because it was the klutziest, most
>counter-intuitive batch system I ever used.

Without denying what you're saying (except for your crack about
Morten being a smug FORTRAN programmer, which IMHO he definitely
is not), at least JCL worked.  Sort of, anyway - it's easy to
look back with 30 years of hindsight and see how it could have
been done better, but we didn't have that luxury back then.
For what it was meant to accomplish, I'd much rather be writing
JCL than trying to coax a Windows box to do the same thing.

>Everyone needs to vent once in a while, but using terms like
>"buzzword-correct script kiddies" puts you right into the slashdot
>posting style, only in a different age group.

Aw, give him a break.  In this age of content-free Web sites and
systems that are 1000 times as powerful as those we grew up on
while getting in the way of useful work, there's nothing wrong
with this kind of venting.  Especially since there are many PHBs
out there who really are "buzzword-correct script kiddies" to the
exclusion of all else, and who are doing the industry a lot of harm.

--
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

Nick Maclaren wrote:

> In article <3F049817.7070701@moene.indiv.nluug.nl>,
> Toon Moene <toon@moene.indiv.nluug.nl> writes:

> |> I know that in weather forecasting you *cannot* have completely bogus 
> |> results, because the PDE integrator that's the heart of the thing will 
> |> have blown up completely before it starts getting out of hand.
> 
> Oh, come off it!  You aren't THAT naive!

Note that in an initial value problem, every intermediate state is also 
an initial value (of the remaining forecast).

Given the fact that even slightly disturbed model states, when used as 
an initial state, will lead to a blow up of the integration means that 
you cannot get arbitrary bogus results.

You can get wrong results (even so wrong that they are useless as a 
weather forecast), but they're not *bogus* - they are still valid 
representations of possible atmospheric states.

> |> To prevent segmentation faults due to addressing arrays out of bounds, 
> |> we added two very simple checks at the end of every time step:
> |> 
> |> 1. Wind speed does not exceed the speed of sound.
> |> 
> |> 2. Pressure tendency > 10 hPa / hour at the surface is bogus.
> |> 
> |> Ta Da - problem solved.
> 
> I am NOT TALKING about segmentation faults and similar - I am
> talking about numerics.

The segmentation fault is but an example.  What I showed you was that 
there are two simple tests in weather forecasting that prevent your 
model to reach a *bogus* result, as opposed to one that's wrong, but 
possible.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

In article <3F05CCF2.7040309@moene.indiv.nluug.nl>,
Toon Moene  <toon@moene.indiv.nluug.nl> wrote:
>Nick Maclaren wrote:
>
>> In article <3F049817.7070701@moene.indiv.nluug.nl>,
>> Toon Moene <toon@moene.indiv.nluug.nl> writes:
>
>> |> I know that in weather forecasting you *cannot* have completely bogus 
>> |> results, because the PDE integrator that's the heart of the thing will 
>> |> have blown up completely before it starts getting out of hand.
>> 
>> Oh, come off it!  You aren't THAT naive!
>
>Note that in an initial value problem, every intermediate state is also 
>an initial value (of the remaining forecast).
>
>Given the fact that even slightly disturbed model states, when used as 
>an initial state, will lead to a blow up of the integration means that 
>you cannot get arbitrary bogus results.
>
>You can get wrong results (even so wrong that they are useless as a 
>weather forecast), but they're not *bogus* - they are still valid 
>representations of possible atmospheric states.

I will try once more.

That is seriously wrong, for two reasons.  Let us talk in terms of
chaotic systems and attractors.

The 'true' weather system has one set, and almost all states will
be one of them (subject to the usual weebling).

The atmospheric model used in the computer is an APPROXIMATION to
the true weather system, and is likely to have a very different set
of attractors.  Just as a small change in initial conditions can
make a huge change in the result in a chaotic system, a small
change in the system can make a huge difference in the attractors.
So you have no a priori reason to believe that the computer model
will settle down to a plausible atmospheric scenario.

Exactly the same is true for the instantiation (i.e. using computer
arithmetic).  The finiteness of the representation and details of
the arithmetic can change the attractors out of all recognition.
This has been known since certainly the 1950s, perhaps the 1930s,
and Kahan and others give examples.  In fact, it is a classic
(probably insoluble) problem in numerical analysis.


Regards,
Nick Maclaren.

In article <3F05EB2E.2090704@moene.indiv.nluug.nl>,
Toon Moene  <toon@moene.indiv.nluug.nl> wrote:
>
>Ah, I see where you and I got in a mix-up.
>
>Of course I agree that "I have no *a priori* reason" to believe that the 
>computer model will settle down to a plausible atmospheric scenario".
>
>However, I do have an *a posteriori* reason to believe so, namely our 10 
>years of verification data (four 48 hour forecasts per day over 10 years 
>is 14600 cases).

That sounds like a reasonable amount of evidence :-)  No guarantee
that it will continue if you apply your model to a significantly
different scenario, of course ....


Regards,
Nick Maclaren.

In article <6isagvsn6l05i3jcj373jkr5v8sb6akmdv@4ax.com>,
Robert Myers  <rmyers@rustuck.com> wrote:
>On Fri, 4 Jul 2003 09:40:00 +0200, Morten Reistad
><mrr@reistad.priv.no> wrote:


I set followup-to to alt.folklore.computers, where this discussion
belongs. If the style has offended any of the others you can relax
now and go back to the regularly scheduled program

>>>> so claiming that message passing is performance-limited doesn't fly as
>>>> an objection, because I have my choice of arbitrarily fast, plentiful,
>>>> and exotic processors to work with.
>>>> 
>>>> And I think this (along with the Forrest curve) really gets to the
>>>> heart of the matter.  If we've got power to burn, then let's burn it
>>>> building safer code.  If we build safer code, we will be able to build
>>>> more complex code.
>>
>>Writing purposefully inefficient code is not a solution. Java has
>>so far been a huge disapointment for me; the project coming from
>>that corner is just en endless series of slow bloat that is even
>>fuller of bugs than the C they were replacing.  
>>
>"Writing purposefully inefficient code" is a very strange distortion
>of what I proposed.  If we have processor power to burn, then we have
>more time to do sanity checks and we can limit ourselves to structured
>pathways for control and data, even though they might not be the most
>efficient.
>
>You can write good code in any language you want, and you can write
>bad code in any language you want.  Someone whose preference is to
>write in assembler and who is disciplined and competent can write
>transparent, safe, and easily debugged code in assembler.  Writing in
>Java makes certain tasks and certain kinds of abstraction much easier
>and helps with portability, but it doesn't necessarily make the code
>any safer or even any more readable.

There may still be hope in Java code once the programmers settle
down and do it right; a second generation effect or something.
For the time being I only observe this from the outside.  

I had reasonable high hopes to Java, but have so far been pretty
disappointed by the actual results. Java is now half a decade old; 
counting the years in active deployment; and the language is still
not settled either.   

I would love to be proven wrong here. 

>>I see that "message passing" is back to buzzword status again. In a sense
>>the Internet uses a lot of "message passing"; but we got beyond the
>>buzzwords and made a real implementation around 20 years ago. It is
>>called IP. 
>>
>>Using this at the right place is a good idea. But this is not new.
>>
>There may be lots of things that aren't attractive about my thinking
>and posting style, but you can always count on one thing: I don't let
>anyone else do my thinking for me.  If I am using "buzzwords", it is
>because I am already idiosyncratic enough in how I think and approach
>problems, and if people are currently using a term to describe a
>particular process that I find attractive, I think I should use that
>term to talk about it, rather than avoiding the term simply because it
>is a buzzword.

You were one on several posters coming up with message passing recently.
I think I see a trend here. Message passing was a huge buzzword around
a decade ago, and many people had to fight the outgrowths of this.

>The whole point of what I have had to say on this subject is that we
>already know how to most of what needs to be done and that we don't
>have to invent anything new.
>
>On the other hand, styles of programming are changing in important and
>positive ways, and I don't find being stuck in a mainframe mentality
>to be particularly attractive, productive, or helpful.

There are good things to the "old style"; and there are bad ones.
Those who are not aware of this history is doomed to make the same
mistakes again.

Reporting, documenting and fixing bugs is one of those traditions we seem to 
be losing.  

><snip>
>
>>
>>>Call it culture shock, but I continually shake my head at half the 
>>>threads in this conference.  Some programmers have not and do not write 
>>>code as if we were still working on an 8080- I and many others write as 
>>>if we were *still working on an IBM S370*. Using a reliable operating 
>>>system, where if you find a bug, it actually gets fixed by the vendor!
>>>
>>>I feel like a grownup whose world has been taken over by a bunch of 
>>>ignorant children, who's idea of reality is akin to Peter Pan's Never 
>>>Never Land!
>>
>>I tend to view these newsgroups as a holdout where the world remains
>>a little saner. But I concur with the sentiment. 
>>
>>In my PPOE I had responsability for taking over web-stuff that was
>>moved to the ISP to run in production there. This stuff was almost
>>exclusively developed by PHB's running a lot of buzzword-correct 
>>script kiddies. Lots of Java, databases and huge stuff. This was
>>in the middle of the dotcom boom.
>>
>>Around 3/4ths of these projects never got out of development because
>>the software couldn't run without handholding. Failed elementary
>>stability and load tests with flying colours. So even if the 
>>business cases had been solid (most weren't) they were doomed
>>anyhow.
>>
>>>Real Machines, Real Operating Systems, and yes, Real Programmers still 
>>>exist in the MF world!   :)
>>
>>And we can still program in FORTRAN!
>>
>
>I hope that not everyone reading this diatribe thinks that all
>competent FORTRAN programmers are so smug.  Personally, I hated IBM
>machines and IBM operating systems.  I cannot remember one single
>thing about IBM JCL because it was the klutziest, most
>counter-intuitive batch system I ever used.

It is almost two decades since I did a large project in Fortran.
But I could still program in that language if I had to. 

And the mainframes in question never ran JCL, nor were they made
by IBM. But they were mainframes, all right. They even had
Four More Bits.

>Everyone needs to vent once in a while, but using terms like
>"buzzword-correct script kiddies" puts you right into the slashdot
>posting style, only in a different age group.

You should have been at a large ISP delivering hosting and housing
services during the dotcom boom. I still think "buzzzword correct
script kiddies" is a pretty correct description of a significant
section of the people implementing these wild dotcom ideas. 

Not many of these outfits exist anymore. 

There seemed to be a unholy union between these programmer types
and harebrained young "executives" in flashy shuits. 

-- mrr

"The only intuitive interface is the nipple"

-- 
#!/usr/bin/perl
$/="%\n";chomp(@_=<>);print$_[rand$.]

Peter da Silva, just another Perl poseur.

Robert Myers <rmyers@rustuck.com> writes:

> In the the linux-on-the-desktop model, very *same* desktop is to be
> used by kernel developers and by people doing data entry.  Stating it
> that way indicates that there is probably something fundamentally
> wrong with the one-size-fits-all strategy, but it's a model that's
> been imposed on linux by Windows, and getting out of that model won't
> be easy.

And here you've put your finger on the single biggest obstacle facing
Linux right now.  Microsoft is not imposing anything on Linux; it is
the Linux development community that have collectively imposed this
model on themselves.  Now that Microsoft software is becoming
reasonably reliable (at least until they release Longhorn), what
selling point will Linux have?

Charlton

jmfbahciv@aol.com writes:

> Bingo!  When I started doing this newsgroup thing, my goal became
> to spread the word that an OS is not supposed to die nor cause you
> to have to restore the system.

Amen!  Preach on, sister BAH!

Yesterday morning, I decided to install Nethack on my Mac laptop.  By
the time I needed to leave for work, it hadn't finished compiling, so
I told it to sleep and stuffed it in my backpack.  At lunch, a
friend wanted to show me some JPGs of plans for improvements he wanted
to make to his house, so I pulled out the Mac and woke it up.  It
merrily continued compiling, as if it had never been asleep.

"What's it doing?" my friend asked.

"Compiling Nethack," I replied.

"You can put it to sleep in the middle of a compile, and it just picks
up afterwards?  No crashing, no hanging, no screwups?" he asked,
amazed.

This is a man who has been working with computers for over 20 years.
It's sad that he was so amazed at something that's been well within
our collective technical grasp for some time now....

Charlton

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> In article <3F04D94B.9A9AD005@computer.org> JOATnospamMON@computer.org
> (Sam Yorko) writes:
> 
> >"Computer people are paid massive amounts of money to cary on
> >productive conversations with inanimate objects."
> 
> This sounds very much like a definition of a computer programmer
> that I once read: "Red-eyed mumbling mammal capable of conversing
> with inanimate objects."

"Let's get this straight, you expect me to give orders to inanimite
object and expect me to be _sane_ too?


-- 
Walter It is difficult to get a man to understand something," wrote
Upton Sinclair, "when his salary depends upon his not understanding it."
Walter

In article <bdu5f5$glj$1@pegasus.csx.cam.ac.uk>, Nick Maclaren wrote:

>|> Asimov also wrote a nice little story, based on a society where knowledge
>|> and expertise is extremely fractioned and specialised (so that nobody has
>|> the holistic view, and the different "experts" do not allow themselves to
>|> critique their colleagues from a different field) and the biological
>|> properties of Beryllium.
> 
> God help me, he could be describing the present.

Like many sci-fi writers, he was.

The failure of the Galactic Empire was drawn right out of his own very
local observations.

-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

On Fri, 4 Jul 2003 22:44:32 -0400, proto@panix.com (Walter Bushell)
wrote:

>Robert Myers <rmyers@rustuck.com> wrote:
><Snip>
>> The people with
>> checkbooks aren't going to pay for anarchy, anyway.
>> 
>> RM
>
>They paid for the development of Mircrosoft Windows, Word and Lookout!,
>pretty much anarchistic programs, have you contemplated the intrernal
>format of Word Documents lately not to mention the viral spreading
>properties of Word and Lookout!, for example.

If we move the discussion to the snot-nosed brat from Redmond and his
heavy-handed sidekick, Steve, things will rapidly get out of hand, if
they haven't already.

The tangent we are now off on was started by what I regarded as a
pretty heavy-handed and self-righteous condemnation of "ignorant
children" by a "grownup".  As I perceive the world, it is lazy-minded
"grownups" who have funded Micro$loth and children of all ages who
have successfully created their own much more attractive never-never
land that is the only viable alternative to it.

Windows XP is actually a pretty reliable and attractive operating
system, but, as far as I am concerned, only a fool would process email
using Outlook and allow IP to be stored in any of Microsoft's
deliberately obfuscated file formats.  It sounds like Longhorn is
going to do some interesting things, and I don't doubt that Linux will
be quick to pick up on whatever seems worthwhile.

For reasons that I have defended ad nauseum in Linux newsgroups, I do
my development on Linux boxes and pretty much everything else on a
Windows XP box loaded with firewalls and virus checkers.  I don't use
Microsoft Office, Internet Explorer, Outlook, or Outlook Express for
the same reasons that caused you to post.

It's a complicated world.  Them and us mentalities make it easier to
navigate all that complication, but taxonomies like "PC vs.
Mainframe", "Microsoft vs. Everybody Else", "Old vs. Young",
"Experienced vs. Inexperienced", and so on and so on and so on rarely
pay off in the long run.

RM


 

In article <bdrcvp$4hr$1@pegasus.csx.cam.ac.uk>, Nick Maclaren wrote:

> Because it is less well engineered.  Also, do you know how many
> such military engineering systems have significant and even major
> components that are decommissioned before they are got to work in
> the field?

I'm not sure its all that better engineered.

The parts in a carrier are also mostly fairly simple and well
understood.  We've been doing the majority of it for a long time now.
Even the "new" stuff is refinement and changes in very old knowledge.

> By splitting programs into functions of at most 20 lines long (yes,
> seriously), you may be able to understand every function at a glance.
> You will not, however, be able to understand their interactions.  So
> you split the program into separate ones of at most 20 functions,
> and can now understand every program.  But you will not be able to
> understand the network of programs.  And so on.

Thank you!

I have railed about this since college.

A Navy guildeline we got for working on a submarine had all these rules
about how long functions could be and so on.  To actually write software
that worked, you basically had to throw that book away.  Not that all of
it was bad ideas, but much of it was simply impossible to do.

I wish I had a copy of those notes.  A lot of people would get a chuckle
out of it.

I had a coworker once who put each of his C functions in a separate
file, no large ones, with a separate header file for each.  It drove me
nuts and seriously cramped your ability to understand the whole program.

-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

In article <bdre26$56m$1@pegasus.csx.cam.ac.uk>, Nick Maclaren wrote:

>|> No.  Because you don't have high-level screws.  10 million lines of mostly
>|> flat-line code broken into pieces that interact very little with each
>|> other would be a lot easier to understand than 10 million typical lines.
> 
> I suggest learning a little more about the design of such systems.
> Your point is correct, but your viewpoint of their problems is
> overly simplistic.

No, he's spot-on.

The vast majority of those millions of parts in a carrier (or any large
ship) are basic physical components we've known for a long time.

Much of the advanced work in ship design is in knowledge of materials,
and design work, not the parts.

What *is* a lot like software is the management of all those parts.
They are far more disciplined about it than the software industry.  Of
course, software is a lot different than driving rivets and welding.



-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

In article <bdrjd8$a4i$1@pegasus.csx.cam.ac.uk>, Nick Maclaren wrote:

> The fact that modern passenger aircraft don't crash as often as
> modern computer systems is not because they are simpler, but
> because traditional engineering discipline is used.

Think for a moment about a modern airport launching aircraft as many
times per day as a computer launches programs.

I know, that's not your point, but it stuck me that if you really push
this analogy, it comes up in favor of software.


-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

In article <20030703194616.4f3b23a2.steveo@eircom.net>, Steve
O'Hara-Smith wrote:

> 	Just send five lines of code to each of the addresses below and
> you will soon receive more code than you can ever compile ,,,

You know... someone has got to try this.


    "Write code for the last specification in the list, and pass the
     remaining spec to five programmers you know."

:)



-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Charlton Wilbur wrote:
> Robert Myers <rmyers@rustuck.com> writes:
> 
> 
>>In the the linux-on-the-desktop model, very *same* desktop is to be
>>used by kernel developers and by people doing data entry.  Stating it
>>that way indicates that there is probably something fundamentally
>>wrong with the one-size-fits-all strategy, but it's a model that's
>>been imposed on linux by Windows, and getting out of that model won't
>>be easy.
> 
> 
> And here you've put your finger on the single biggest obstacle facing
> Linux right now.  Microsoft is not imposing anything on Linux; it is
> the Linux development community that have collectively imposed this
> model on themselves.  Now that Microsoft software is becoming
> reasonably reliable (at least until they release Longhorn), what
> selling point will Linux have?
> 

There's more to it than reliability, there's the contract conditions.

Have you read the license agreement for MS stuff?
It gives them the right to do anything they like, and it gives you 
nothing. If you have obligations in respect of confidentiality of 
personal information, then what do you say to the people when MS, quite 
legally according to the contract you have accepted, copy that 
information and use it for their own purposes? If your machine supports 
critical life-support equipment, or controls a process which pollutes 
the countryside if it fails, can you afford to give MS the right to poke 
at it whenever they want when the chances are they will introduce bugs?

I heard a talk by a lawyer last week. He had moved his firm totally off 
MS products. He told MS why, and they said "but we wouldn't ever do 
that", so he said, "In that case let's remove the nasty bits from the 
agreement", and they said "No".

--brian

-- 
Brian Boutel
Wellington New Zealand


Note the NOSPAM

>>>>> On 3 Jul 2003 11:10:25 -0800, Eugene Miya ("Eugene") writes:
 Eugene> 2 things strike my memory:
 Eugene> 55. A LISP programmer knows the value of everything, but the cost of nothing.

Please note that this is a joke.  (And at the time it was written, 
Lisp on the PDP-10 generated faster numeric code than DEC FORTRAN,
so it wasn't true, even then.  Also, Lisp has changed alot in the
25-30 years since the joke.)

On Fri, 4 Jul 2003 21:42:57 +0000 (UTC)
peter@abbnm.com (Peter da Silva) wrote:

PDS> "The only intuitive interface is the nipple"

	intuitive != instinctive.

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

On Fri, 04 Jul 2003 15:39:54 -0400
Robert Myers <rmyers@rustuck.com> wrote:

RM> In the the linux-on-the-desktop model, very *same* desktop is to be
RM> used by kernel developers and by people doing data entry.  Stating it
RM> that way indicates that there is probably something fundamentally
RM> wrong with the one-size-fits-all strategy, but it's a model that's
RM> been imposed on linux by Windows, and getting out of that model won't
RM> be easy.

	I'm confused surely one of the strengths of linux is that you
can escape the one size fits all user interfaces and use whatever you
like.

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

On Tue, 01 Jul 2003 13:54:51 -0400, Paul Wallich <pw@panix.com> wrote:

>As someone else pointed out, We don't really seem to be willing to pay 
>the price, either in time or money, that it would cost to implement such 
>a system. And the IT industry fights tooth and nail against any efforts 
>to impose the kind of liability incentives that are standard for more 
>rigorous forms of engineering.

And for good reason. If a plane crashes it kills people; if a word
processor crashes, it mildly annoys people. It would be daft to hold
the latter to the same standards as the former.

Where software is used for safety-critical tasks, higher standards are
indeed used, and to good effect; disasters caused by software failure
are AFAIK rarer than those caused by hardware failure.

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace

wallacethinmintr@eircom.net (Russell Wallace) writes:

> On Tue, 01 Jul 2003 13:54:51 -0400, Paul Wallich <pw@panix.com> wrote:
> 
> >As someone else pointed out, We don't really seem to be willing to pay 
> >the price, either in time or money, that it would cost to implement such 
> >a system. And the IT industry fights tooth and nail against any efforts 
> >to impose the kind of liability incentives that are standard for more 
> >rigorous forms of engineering.
> 
> And for good reason. If a plane crashes it kills people; if a word
> processor crashes, it mildly annoys people. It would be daft to hold
> the latter to the same standards as the former.

If a car breaks down, it may just be mildly annoying (you're stuck
somewhere). Even the electronics industry, which delivers the
components to build your beloved computers, take back faulty
components and pay for damages. 

I utterly disagree with your viewpoint.


--Kai

In article <3F058CF6.6080806@cavtel.net>,
   jonah thomas <j2thomas@cavtel.net> wrote:
>jmfbahciv@aol.com wrote:
>>    jonah thomas <j2thomas@cavtel.net> wrote:
<snip>

>> I think you may have potential.  I know I don't have the patience...
>> nor the tact... to explore it.
>
>Thank you.  I get the impression you're somebody famous, 

Nah, I'm not famous; I've just got a big mouth and had the privilege
of working with bit gods.

> ..I hope you 
>don't mind that I never heard of jmfbahciv.  ;)
>
Nope.  Don't mind at all.  The work done under JMF is well known
in a niche of the computing world.  I did more of the background
work that didn't require initials on it.

/BAH

Subtract a hundred and four for e-mail.

In article <c394eb.boc.ln@innovative.iinet.net.au>,
   Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
>jmfbahciv@aol.com writes:
>
>>In article <t7e1eb.g75.ln@innovative.iinet.net.au>,
>>   Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
>>>jonah thomas <j2thomas@cavtel.net> writes:
>>>>It's good to break programs up into pieces that make sense.  A
>>>>bunch of small pieces that each make sense, called by small
>>>>higher-level routines that each make sense, etc -- that's a good
>>>>thing.  A 500-line program broken up into 30 20-line-or-less
>>>>segments whose only purpose was to follow a rule, would be utterly
>>>>stupid.
>
>>>I'd have used up the 20 lines just checking a few input parameters
>>>for sensibility.
>
>>>Typical program of mine is 80% error checking. If I'm feeling
>>>especially paranoid, it's 90%.
>
>>>Most other code I've seen simply trusts the inputs and never checks
>>>return codes from functions. They simply accept that the data is
>>>sane... so they only have up to 20% error checking... often; none.
>
>>Where the sanity checking is done is a part of the original design
>>decision...isn't it?  Let me see if I can write this clearly...I'm
>
>What's this "design decision" thing?

<GRIN>  shhhh!  Not in front of the children. ;-)


> .. The bulk of software festers
>from bits of code apparently hacked together between beers.

<ahem>  The design is found on those napkins that the beer
mugs were supposed to set upon.

> .. Any bugs
>are "fixed" by band-aids applied by ignorant minions later in the
>product life cycle.
>
>>having trouble getting it from my head to my fingers.
>
>>The sanity check has to be one consistently on either one side or
>>the other.  (I'm talking about one product now.)  The calling
>>procedures is one of the first things that has to be designed before
>>any other design takes place.  
>
>The called procedure/function must "know" its own limitations and is
>therefore the most logical place to do input validation. A procedure
>may also encounter errors and needs to signal those to the caller.
>If the caller ignores the error condition or is unable to determine
>that there was an "internal" error and continues, then at the very
>least it's wasting computing cycles building garbage.
>
>If you ever wonder why you get odd error messages unrelated to the
>real problem, then it's because something hasn't been checking for
>error conditions; usually "impossible" ones. As a result, you do
>lots of processing with erroneous data which can result in further
>data corruption down the line should the data be stored in a shared
>or re-usable resource.
>
>Procedures that do sanity checking on the returned values from
>functions, in addition to checking error conditions, are typical of
>paran^Wrobust programming. The checks are often simple such as
>cross-checking relationships in an RDBMS; sometimes they're
>complicated like verifying that end conditions are satisfied in
>structural analysis.
>
>It's no longer only experts and professionals using highly technical
>or business critical software; it's people who seldom understand the
>consequences of the data with which they're presented.


All valid points.  I'm not disagreeing.  I'm thinking more about
designs (acutally, the conversations I overheard between CDO and
LSS about GALAXY keep popping into my head) such as who saves the
stack and how much; which are temp registers and don't have to
be saved among calls; which are to be used for the push down list;
naming conventions so that a glance can tell the viewer if the
variable is global, local, bit definition, word definition, locaction,
a value.  Things like that.  I realize that this is all PDP-10 
specific but I still can't put what I'm thinking about into ASCII
English so examples will have to do.

These decisions are crucial if you have more than one person
on an entire product (which I think rare these days).

/BAH

Subtract a hundred and four for e-mail.

In article <1fxl961.x2aon8uy5nd7N%proto@panix.com>,
   proto@panix.com (Walter Bushell) wrote:
>Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> In article <3F04D94B.9A9AD005@computer.org> JOATnospamMON@computer.org
>> (Sam Yorko) writes:
>> 
>> >"Computer people are paid massive amounts of money to cary on
>> >productive conversations with inanimate objects."
>> 
>> This sounds very much like a definition of a computer programmer
>> that I once read: "Red-eyed mumbling mammal capable of conversing
>> with inanimate objects."
>
>"Let's get this straight, you expect me to give orders to inanimite
>object and expect me to be _sane_ too?

But that's exactly how I keep sane!  It's dealing with people that
drives me crazy.

/BAH

Subtract a hundred and four for e-mail.

On Sat, 05 Jul 2003 07:35:11 GMT, Kai Harrekilde-Petersen
<khp@harrekilde.dk> wrote:

>If a car breaks down, it may just be mildly annoying (you're stuck
>somewhere). Even the electronics industry, which delivers the
>components to build your beloved computers, take back faulty
>components and pay for damages. 

Try going to a hard disk manufacturer and saying "The hard disk I
bought from you went poof, I had $100,000 worth of data on it and I
didn't bother making backups, I want $100,000 off you" and see how far
you get.

>I utterly disagree with your viewpoint.

So you want most of the world's programmers to lose their jobs, the
remainder to have to work for big companies and spend a large chunk of
their days filling out forms to prove they've followed this and that
procedure, and the cost of software to the end user to increase by a
large factor?

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace

On Sat, 5 Jul 2003 09:21:48 +0200, Steve O'Hara-Smith
<steveo@eircom.net> wrote:

>On Fri, 04 Jul 2003 15:39:54 -0400
>Robert Myers <rmyers@rustuck.com> wrote:
>
>RM> In the the linux-on-the-desktop model, very *same* desktop is to be
>RM> used by kernel developers and by people doing data entry.  Stating it
>RM> that way indicates that there is probably something fundamentally
>RM> wrong with the one-size-fits-all strategy, but it's a model that's
>RM> been imposed on linux by Windows, and getting out of that model won't
>RM> be easy.
>
>	I'm confused surely one of the strengths of linux is that you
>can escape the one size fits all user interfaces and use whatever you
>like.

Theory: You can do whatever you want.

Practice: You can do whatever you want, but using anything but what
comes with the distribution consumes resources.

Just as Microsoft has no particular incentive to make it easy to avoid
the use of Outlook Express and Internet Explorer, those who package
and distribute Linux distributions have no particular incentive to
make it easy to drop a third party desktop onto their distribution.

RM

On Sat, 05 Jul 2003 11:32:15 GMT, Kai Harrekilde-Petersen
<khp@harrekilde.dk> wrote:

>IBM had an error in DB2 which cost Danske Bank about a weeks downtime.
>Since Danske Bank handles approximately 50% of all money going in and
>out of Denmark, the incident caused bit of a hickup
>(http://www.danskebank.com/ITreport).
>
>Guess what, IBM have been asked to cover the loss of Danske Bank's
>customers.  And as far as I know, they are going to cough up.

That's not terribly unreasonable given that DB2 is designed and
marketed for exactly that type of high-end, mission-critical
commercial operation, and has an appropriate price tag and
accompanying service contracts. It's an example of a vendor accepting
liability for software faults _in proportion to the software's cost
and intended use_.

What I'm arguing against is the crazy notion that everyone should be
forced to use software engineered to that reliability level for all
purposes, including word processing and reading Usenet.

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace

Russell Wallace wrote:

> So you want most of the world's programmers to lose their jobs, the

That might be a good thing

> remainder to have to work for big companies and spend a large chunk of
> their days filling out forms to prove they've followed this and that
> procedure, and the cost of software to the end user to increase by a
> large factor?

No, that would be bad.

Here's a peculiar thought.  I read something from an economist 
discussing airbags for cars.  He claimed that it was the wrong approach 
for reducing accident deaths.  He said that if instead cars were 
required to have long sharp spikes sticking out of the dashboard that 
were practically guaranteed to kill drivers who had a front-end 
collision, that there would be many many fewer accidents.  Drivers would 
have a strong incentive to pay attention and to make sure by whatever 
method that they wouldn't hit things.

If people *knew* that they were using an operating system where any 
application error was likely to crash the system and destroy unrelated 
data on disk, they wouldn't accept buggy software.  When some new 
product came out and a user crashed it, he'd immediately announce it to 
the world.  The company would deny the bug existed and also within 24 
hours would have an update that they promised would fix the problem.  Te 
second time it happened, sales would drop to nothing.

Time-to-market would slow dramatically.  The first-to-market with buggy 
code would be destroying their reputation, not pre-empting market share. 
  Various methods that we already know how to do would get used, because 
that's what would be valued.  Time-to-market would still be valuable, 
but not at the expense of correctness.  "A software engineer is somebody 
who can do in two months what any damn fool can do in a year."

Clearly, Microsoft Windows should have been a very valuable resource but 
the advertising was mis-handled and so we didn't get the benefits.


People accept a certain level of automobile accidents.  When the cars 
and the roads get safer then people drive faster to compensate. 
Similarly, people accept a certain level of error in software.  We can't 
expect commercial software to get more robust until that becomes a 
priority for buyers of commercial software.

According to Russell Wallace <wallacethinmintr@eircom.net>:
> It occurs to me to wonder: is there another industry in which it's
> commonplace for workers to refer to customers as "losers" (with or
> without misspelling) and to regard their liking of the industry's
> products as an indication of stupidity? The sex and illegal drugs
> industries would be the two obvious possibilities that come to mind;
> are there others?

Many retail outlets refer to customers as "mugs."  The motor trade
often describes them as "victims."  A better question might be, is
there any industry which does _not_ refer to customers in a derogatory
manner?

Chris.
-- 
"If the world was an orange it would be like much too small, y'know?" Neil, '84
  Currently playing: random early '80s radio stuff
  http://www.chrishedley.com - assorted stuff, inc my genealogy.     Gan canny!

Peter da Silva wrote:
> 
> "The only intuitive interface is the nipple"
> 
Would that be the "user device from heaven", as adverse
to the "user device from hell"???

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

jonah thomas wrote:
> 
>         [snip...]         [snip...]         [snip...]
>
> You're at the mercy of those who went before and that's just how it is.
> 
Isn't that the way *everything* is in life??? We are always at
the mercy of those who came before us. Heck, we are all so dependent
on society, that we are all at the mercy of what is happening now,
for the most part.

I do understand your point, however, that smaller programs are
tractable, and the largest ones are pretty much intractable.

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

In article <3f068b93.988029869@news.eircom.net>,
Russell Wallace <wallacethinmintr@eircom.net> wrote:
> Try going to a hard disk manufacturer and saying "The hard disk I
> bought from you went poof, I had $100,000 worth of data on it and I
> didn't bother making backups, I want $100,000 off you" and see how far
> you get.

"The car I bought from you failed when I was trying to jump a creek in
it, my medical bills were $100,000, I want $100,000 off you".

-- 
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate.  All
these things will be lost in time, like chalk-paintings in the rain.   `-_-'
Time for your nap.  | Peter da Silva | Har du kramat din varg, idag?    'U`

In article <vdbdgvg9lcnrkrug67cg0167d92455hiju@4ax.com>,
Robert Myers  <rmyers@rustuck.com> wrote:
> Practice: You can do whatever you want, but using anything but what
> comes with the distribution consumes resources.

That's easy to fix, actually. It just takes making the decision in the
distribution to spend a week or so, once, in writing the software to do
it. Usually it takes small changes in two or three files, then logging in
again, to switch from one user interface to another. There's hooks in
most login managers that will actually make the changes if the distro
just provides a couple of startup scripts for the different interfaces.

The only problem is that they only ever seem to come with a couple of
scripts, and documentation on how these scripts work is missing or hard
to find, and they're only provided for the software developer's two favorite
window managers and shells.

> Just as Microsoft has no particular incentive to make it easy to avoid
> the use of Outlook Express and Internet Explorer, those who package
> and distribute Linux distributions have no particular incentive to
> make it easy to drop a third party desktop onto their distribution.

See, actually, it is easy. It's just different for each distro or each
desktop. There's no equivalent of Linus Torvalds saying "every version of
Linux will support /etc/desktops.d, and every desktop will install its
startup script into there".

-- 
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate.  All
these things will be lost in time, like chalk-paintings in the rain.   `-_-'
Time for your nap.  | Peter da Silva | Har du kramat din varg, idag?    'U`

On Sat, 5 Jul 2003 14:45:46 +0100
cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) wrote:

CH> A better question might be, is
CH> there any industry which does _not_ refer to customers in a derogatory
CH> manner?

	Grace Brothers ?

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

On Sat, 05 Jul 2003 09:06:20 -0700, Lars Poulsen
<lars@beagle-ears.com> wrote:

>Robert Myers wrote:
>> I really don't see the massive damage done by the "buzzword-correct
>> script kiddies" that you seem to see.  There are *so* many computers
>> and *so* much bandwidth, that there is room for everybody, as far as I
>> can see.  I'd rather err on the side of encouraging anarchy than on
>> the side of encouraging a stifling orthodoxy.  The people with
>> checkbooks aren't going to pay for anarchy, anyway.
>
>I see lots of people with (smallish) checkbooks that are willing
>to pay for "buzzword-correct script kiddies" or Microsoft-trained
>consultants to install and adapt business software that is glitzy
>dysfunctional junk. In fact, that is ALL they will pay for.
>Meanwhile people who know better are having trouble finding jobs;
>remember Gene Wirchenko's tale of being turned down for a repair/
>upgrade job because he suggested the state of the system before
>the change should be inventoried, documented and critiqued in
>order to derive requirements for the upgrade?
>

We agree on the existence of the phenomenon, but we disagree on the
explanation for the phenomenon.  Much of what you are complaining
about is explored at length, and with humor, in Dilbert cartoons.  It
is a world of the brain-dead or worse, and "buzzword-correct script
kiddies" wouldn't make it past the front desk.

Microsoft-trained consultants might, but don't necessarily assume that
people don't know what they're buying.  They know that what they're
buying has been dumbed down to a level so that it can be defended in a
Dilbert world.  They aren't *interested* in the best solution.  They
are interested in staying employed.

RM

In article <u5udgvcem2b2hiisu0uhfnjp57a409flj9@4ax.com>,
Robert Myers  <rmyers@rustuck.com> wrote:
> On Sat, 5 Jul 2003 15:48:32 +0000 (UTC), peter@abbnm.com (Peter da
> Silva) wrote:
> >See, actually, it is easy. It's just different for each distro or each
> >desktop. There's no equivalent of Linus Torvalds saying "every version of
> >Linux will support /etc/desktops.d, and every desktop will install its
> >startup script into there".

> I tinker, but I tinker resourcefully.  Tinkering with RedHat gnome is
> something I just don't want to do, even though I'd like to try out
> Ximian.

That's why the company putting the distribution together needs to do more
than saying "OK, we'll allow you to use Sawfish or Enlightenment", they need
to have a standard hook for this kind of thing.

It's really not like IE and Microsoft. Microsoft has a business reason to
push you to use IE. They go to extra effort to disable the normal install
and remove APIs for IE: they have a standard "install an application so the
window manager knows about it" mechanism, and THAT is the bit that Linux
is really missing.

-- 
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate.  All
these things will be lost in time, like chalk-paintings in the rain.   `-_-'
Time for your nap.  | Peter da Silva | Har du kramat din varg, idag?    'U`

In article <EIGNa.288$X33.34663567@newssvr14.news.prodigy.com>,
Andy Glew <andy-glew@sbcglobal.net> wrote:
>"Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote in message
>news:bduo0b$rj9$1$8302bc10@news.demon.co.uk...
>> Joe Seigh wrote:
>> >
>> > The not reproducible is a major cop out.  I'm suprised that most
>> > vendors are allowed to get away with this excuse but apparently they
>> > do.
>>
>> I am not a lawyer, but if someone had me up in court and failed to
>> produce evidence, I'd be more than a bit miffed if I was convicted.
>
>Non reproducible bugs happen (e.g.are intrinsic or CPUs like IA 64).
>Conscientious companies keep records of such bugs.

Yes, indeed.  I spend 70% of my debugging time on non-reproducible
bugs - see below.

>Simply saying that a buy is non reproducible
>without having a database recording non-reproducible "sightings"
> is negligent and does not conform to the reasonable standards
> that should be required of a company in this industry.

Agreed.

>Saying that "I have never head of a buy like this before"
>is meaningless, anecdotal hearsay without some evidence
>that the company tracks such things.

Yes.  I get really pissed off when I get told that and either know
that similar effects have been reported by other people or discover
later that is the case.  This is regrettably common :-(

And, similarly, I spend 70% of my debugging time on bugs "that have
not been seen before".  I don't mind too much when it is true.


Regards,
Nick Maclaren.

On Sat, 5 Jul 2003 15:52:22 +0000 (UTC), peter@abbnm.com (Peter da
Silva) wrote:

>Pretty much any service industry I can think of. Ask a chef about
>McDonalds some time. And I know my auto mechanic must think I'm a
>total loser by now.

Heh, fair enough, so it's not peculiar to our industry then.

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace

Lars Poulsen <lars@beagle-ears.com> wrote:

>Robert Myers wrote:
>> I really don't see the massive damage done by the "buzzword-correct
>> script kiddies" that you seem to see.  There are *so* many computers
>> and *so* much bandwidth, that there is room for everybody, as far as I
>> can see.  I'd rather err on the side of encouraging anarchy than on
>> the side of encouraging a stifling orthodoxy.  The people with
>> checkbooks aren't going to pay for anarchy, anyway.
>
>I see lots of people with (smallish) checkbooks that are willing
>to pay for "buzzword-correct script kiddies" or Microsoft-trained
>consultants to install and adapt business software that is glitzy
>dysfunctional junk. In fact, that is ALL they will pay for.
>Meanwhile people who know better are having trouble finding jobs;
>remember Gene Wirchenko's tale of being turned down for a repair/
>upgrade job because he suggested the state of the system before
>the change should be inventoried, documented and critiqued in
>order to derive requirements for the upgrade?

     They just advertised in the local paper for someone to do the
work.  I wonder if I will find out the end to the story.

>I think this can be characterized as "massive damage". But clearly,
>this is not an isue of fact, but of opinion, an which people may
>honestly differ.


Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.

On Sat, 05 Jul 2003 07:45:57 -0400
Robert Myers <rmyers@rustuck.com> wrote:

RM> Practice: You can do whatever you want, but using anything but what
RM> comes with the distribution consumes resources.

	All of those hundreds of Linux distributions are like that now ?
I suppose that's what comes of trying to compete with MS ware instead of
just being an OS.

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

In article <3F06FD3A.C8E42C2D@ev1.net>,
   Charles Richmond <richmond@ev1.net> wrote:
>Peter da Silva wrote:
>> 
>> "The only intuitive interface is the nipple"
>> 
>Would that be the "user device from heaven", as adverse
>to the "user device from hell"???
>
This must be a "guy thing".

/BAH

Subtract a hundred and four for e-mail.

In article <be7elv$3e4$1@pegasus.csx.cam.ac.uk>,
   nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>In article <EIGNa.288$X33.34663567@newssvr14.news.prodigy.com>,
>Andy Glew <andy-glew@sbcglobal.net> wrote:
>>"Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote in message
>>news:bduo0b$rj9$1$8302bc10@news.demon.co.uk...
>>> Joe Seigh wrote:
>>> >
>>> > The not reproducible is a major cop out.  I'm suprised that most
>>> > vendors are allowed to get away with this excuse but apparently they
>>> > do.
>>>
>>> I am not a lawyer, but if someone had me up in court and failed to
>>> produce evidence, I'd be more than a bit miffed if I was convicted.
>>
>>Non reproducible bugs happen (e.g.are intrinsic or CPUs like IA 64).
>>Conscientious companies keep records of such bugs.
>
>Yes, indeed.  I spend 70% of my debugging time on non-reproducible
>bugs - see below.
>
>>Simply saying that a buy is non reproducible
>>without having a database recording non-reproducible "sightings"
>> is negligent and does not conform to the reasonable standards
>> that should be required of a company in this industry.
>
>Agreed.
>
>>Saying that "I have never head of a buy like this before"
>>is meaningless, anecdotal hearsay without some evidence
>>that the company tracks such things.
>
>Yes.  I get really pissed off when I get told that and either know
>that similar effects have been reported by other people or discover
>later that is the case.  This is regrettably common :-(
>
>And, similarly, I spend 70% of my debugging time on bugs "that have
>not been seen before".  I don't mind too much when it is true.

How would you keep track of them?  The way we did it was somebody
remembered.  I'm not talking about reports of bugs that exhibit the
same symptom (e.g., a particular crash like an IME).  I'm talking
about bugs that appear in all kinds of dress.

In our neck of the biz, it took a human to connect two seemingly
different bugs as being the same bug.  Some days, it took a human
to figure out that a particular one-line fix would also fix that
other annoying bug if another line was added.  

You guys have been talking about bugs as if they were isolated 
and independent of each other.  I'm just bringing up the point
that some aren't.

/BAH

Subtract a hundred and four for e-mail.

In article <FIGNa.289$X33.34663567@newssvr14.news.prodigy.com>,
   "Andy Glew" <andy-glew@sbcglobal.net> wrote:
>> This is the fundamental failing of the Structured Programming
>> zealots.  They didn't eliminate complexity; they just moved it
>> from individual modules to the relationships between them.
>
>My view is that structured programming
>emphasized top down design,
>resulting in little code reuse

I don't call that top-down.

>because they always wanted to design
>slightly different low level and mid-level modules

How many ways can you convert from ASCII to SIXBIT?
About the only difference is having the variable names differ.

/BAH


Subtract a hundred and four for e-mail.

In article <avf5eb.e9h.ln@escape.shannon.net>, Charles Shannon Hendrix
<shannon@news.widomaker.com> writes
>The failure of the Galactic Empire was drawn right out of his own very
>local observations.

He wrote somewhere that it resulted from his reading Gibbon: "The
Decline and Fall of the Roman Empire".

-- 
Ken Moore
ken@mooremusic.org.uk
Web site: http://www.mooremusic.org.uk/
I reject emails > 300k automatically: warn me beforehand if you want to send one

Russell Wallace wrote:
> 
>         [snip...]         [snip...]         [snip...]
> 
> Some years ago my fridge packed it in, the pump just quietly stopped
> working. (Annoyingly, it was a few months out of warranty at the time.
> The quote for a repair was close to the cost of a new fridge so I
> didn't bother getting it repaired.)
> 
> If I'd been storing scarce and vital medical supplies in it at the
> time, presumably lives could have been lost. But the blame wouldn't
> rest with the manufacturer, it would rest with my criminal negligence
> in using ordinary consumer products for safety-critical tasks. I
> assume hospitals use better equipment for storing medical supplies. I
> also assume nobody would be stupid enough to demand I pay for
> safety-rated refrigeration equipment when all I want to put in it is
> milk and frozen pizza. I wish I could make those assumptions in the
> software industry.
> 
But it seems that "it works most of the time" is good enough
even for the space shuttle. I have *no* churlish objections
to saving money...but some are so damn interested in saving
a few cents here and there, that safety and reliability of
systems are often compromised. IMHO.

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

In article <be912k$82p$1@pegasus.csx.cam.ac.uk>,
   nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>In article <be8t1q$1go$2@bob.news.rcn.net>,  <jmfbahciv@aol.com> wrote:
>>>>Saying that "I have never head of a buy like this before"
>>>>is meaningless, anecdotal hearsay without some evidence
>>>>that the company tracks such things.
>>>
>>>Yes.  I get really pissed off when I get told that and either know
>>>that similar effects have been reported by other people or discover
>>>later that is the case.  This is regrettably common :-(
>>>
>>>And, similarly, I spend 70% of my debugging time on bugs "that have
>>>not been seen before".  I don't mind too much when it is true.
>>
>>How would you keep track of them?  The way we did it was somebody
>>remembered.  I'm not talking about reports of bugs that exhibit the
>>same symptom (e.g., a particular crash like an IME).  I'm talking
>>about bugs that appear in all kinds of dress.
>>
>>In our neck of the biz, it took a human to connect two seemingly
>>different bugs as being the same bug.  Some days, it took a human
>>to figure out that a particular one-line fix would also fix that
>>other annoying bug if another line was added.  
>>
>>You guys have been talking about bugs as if they were isolated 
>>and independent of each other.  I'm just bringing up the point
>>that some aren't.
>
>Add to my "70%"s, the fact that 70% of my time is spent on such bugs!
>
>This has been a solved problem for over 60 years.  It was empirically
>solved a couple of millennia ago (in the context of medicine) and
>statistics put it on a sound basis.
>
>What you do is to track "syndromes".  You keep a database of factors
>and symptoms, with an indication of the reliability of the data.
>You then match the factors and symptoms of the unknown problem
>against the data you have, and come out with a probabilistic ranking.
>Very simple, very easy and very effective.

yes, I know.  I'm talking about the specs of the data that is
under the heading "factors".  We used keywords.  You can sort on
them but they sure didn't reflect any kind of reality with a
one-to-one mapping from keyword to specific bug.

>
>The key here is that you MUST have human experts in the loop, to
>deal with new syndromes and MUCH MORE IMPORTANTLY suprious matches.
>This isn't hard to achieve, if you ensure that both the experts and
>the initial advisors use the same database and search engine.  Its
>been done many times, and it works.

I know it's been done before; we called it the SIRS data base.
My point is that it didn't work very well w.r.t. those stats
that you were talking about.  Anything could Ill mem ref.
Sorting all bugs using that keyword doesn't contain very interesting
data.

/BAH

Subtract a hundred and four for e-mail.

In article <1rd6gnq5eb.fsf@glesvat.ifi.uio.no>,
   Kjetil Torgrim Homme <kjetilho@yksi.ifi.uio.no> wrote:
>[Robert Myers]:
>>
>>   On 2 Jul 2003 09:44:45 -0800, eugene@cse.ucsc.edu (Eugene Miya) wrote:
>>   
>>   >I would hold with the academic (Brooks) line that the degree of
>>   >complexity exceeds anything so far known in the physical realm.
>>   
>>   I've had a second look at Brooks ('No Silver Bullet'), and a third,
>>   and a fourth, and I'm not impressed, to put it mildly.
>>   
>>   I could tear his article apart line by line, but my objection
>>   comes down to this: anything you can do in software you should be
>>   able to do in silicon and vice versa.  The division between
>>   hardware and software exists only in Brook's mind, and the
>>   perpetuation of this fundamental error is made possible only by
>>   the semantic ambiguity of languages, like c, that are commonly
>>   used to write software.
>
>"No Silver Bullet" doesn't concern itself with the success of hardware
>design at all.  turning software into hardware is not one of the
>suggested silver bullets.
>
>do we have any indication that hardware development is more efficient
>than software development, anyhow?  if so, one reason could be that
>the hardware design can be chosen on pure technical merits -- no
>business logic or similarily arbitrary customer requirements to worry
>about.

This [rated on purely technical merits] is what is wrong with
hardware development (and has been for years).  Not having 
the customer in mind sucks rocks.  Note that the definition 
of a customer of a CPU designer is the OS developer.

/BAH

Subtract a hundred and four for e-mail.

In article <be8t1q$1go$2@bob.news.rcn.net>,  <jmfbahciv@aol.com> wrote:
>>>Saying that "I have never head of a buy like this before"
>>>is meaningless, anecdotal hearsay without some evidence
>>>that the company tracks such things.
>>
>>Yes.  I get really pissed off when I get told that and either know
>>that similar effects have been reported by other people or discover
>>later that is the case.  This is regrettably common :-(
>>
>>And, similarly, I spend 70% of my debugging time on bugs "that have
>>not been seen before".  I don't mind too much when it is true.
>
>How would you keep track of them?  The way we did it was somebody
>remembered.  I'm not talking about reports of bugs that exhibit the
>same symptom (e.g., a particular crash like an IME).  I'm talking
>about bugs that appear in all kinds of dress.
>
>In our neck of the biz, it took a human to connect two seemingly
>different bugs as being the same bug.  Some days, it took a human
>to figure out that a particular one-line fix would also fix that
>other annoying bug if another line was added.  
>
>You guys have been talking about bugs as if they were isolated 
>and independent of each other.  I'm just bringing up the point
>that some aren't.

Add to my "70%"s, the fact that 70% of my time is spent on such bugs!

This has been a solved problem for over 60 years.  It was empirically
solved a couple of millennia ago (in the context of medicine) and
statistics put it on a sound basis.

What you do is to track "syndromes".  You keep a database of factors
and symptoms, with an indication of the reliability of the data.
You then match the factors and symptoms of the unknown problem
against the data you have, and come out with a probabilistic ranking.
Very simple, very easy and very effective.

The key here is that you MUST have human experts in the loop, to
deal with new syndromes and MUCH MORE IMPORTANTLY suprious matches.
This isn't hard to achieve, if you ensure that both the experts and
the initial advisors use the same database and search engine.  Its
been done many times, and it works.


Regards,
Nick Maclaren.

[Charles Richmond]:
>
>   [jmfbahciv@aol.com]:
>   > [Charles Richmond]:
>   > > [Peter da Silva]:
>   > > > "The only intuitive interface is the nipple"
>   > >
>   > > Would that be the "user device from heaven", as adverse to the
>   > > "user device from hell"???
>   > 
>   > This must be a "guy thing".
>
>   Excuse me. Every baby that I know of...gained sustenance at one
>   time or another...through a nipple...regardless of gender. And
>   they all seemed satisfied.

did you ever see a baby that didn't need to be _taught_ how to use the
nipple?

-- 
Kjetil T.			|  read and make up your own mind
				|  http://www.cactus48.com/truth.html

wallacethinmintr@eircom.net (Russell Wallace) writes:

[liability for software vendors:]

> What I'm arguing against is the crazy notion that everyone should be
> forced to use software engineered to that reliability level for all
> purposes, including word processing and reading Usenet.

How much lower than today's standards can you get? - right now, the
average EULA basically says "Bend over, grease up. We've run with your
money, and there's nothing you can do to stop us from doing that":
IANAL, but the standard clause of denial of "merchantability and
fitness for a particular purpose" says just that to me.

Regards,


Kai

On Sun, 06 Jul 2003 09:30:30 GMT, Charles Richmond <richmond@ev1.net>
wrote:

>But it seems that "it works most of the time" is good enough
>even for the space shuttle.

And after the loss of fourteen lives and two spacecraft worth a couple
of billion dollars each, I'd imagine the people who made the relevant
decisions are regretting them.

>I have *no* churlish objections
>to saving money...but some are so damn interested in saving
>a few cents here and there, that safety and reliability of
>systems are often compromised. IMHO.

Well you're right, they are. My point being that this is acceptable in
consumer-grade systems whose failure is a mere nuisance; the
appropriate standards where failure could shut down your business or
put lives at risk are completely different.

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace

According to Steve O'Hara-Smith  <steveo@eircom.net>:
> On Sat, 5 Jul 2003 14:45:46 +0100
> cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) wrote:
> 
> CH> A better question might be, is
> CH> there any industry which does _not_ refer to customers in a derogatory
> CH> manner?
> 
> 	Grace Brothers ?

They're probably the spiritual ancestors of the "suits you, sir!"
tailors on The Fast Show.  So, no.

Chris.
-- 
"If the world was an orange it would be like much too small, y'know?" Neil, '84
  Currently playing: random early '80s radio stuff
  http://www.chrishedley.com - assorted stuff, inc my genealogy.     Gan canny!

In article <be9244$6e1$7@bob.news.rcn.net>,  <jmfbahciv@aol.com> wrote:
[ Re: tracking unrepeatable or variable problems. ]
>>
>>What you do is to track "syndromes".  You keep a database of factors
>>and symptoms, with an indication of the reliability of the data.
>>You then match the factors and symptoms of the unknown problem
>>against the data you have, and come out with a probabilistic ranking.
>>Very simple, very easy and very effective.
>
>yes, I know.  I'm talking about the specs of the data that is
>under the heading "factors".  We used keywords.  You can sort on
>them but they sure didn't reflect any kind of reality with a
>one-to-one mapping from keyword to specific bug.

Well, of course not.  Why should they?  They don't need to.  The
combination merely needs to have a significant association, in
the information theoretic (a.k.a. statistical) sense.  All very
elementary - to a statistician!

>>The key here is that you MUST have human experts in the loop, to
>>deal with new syndromes and MUCH MORE IMPORTANTLY suprious matches.
>>This isn't hard to achieve, if you ensure that both the experts and
>>the initial advisors use the same database and search engine.  Its
>>been done many times, and it works.
>
>I know it's been done before; we called it the SIRS data base.
>My point is that it didn't work very well w.r.t. those stats
>that you were talking about.  Anything could Ill mem ref.
>Sorting all bugs using that keyword doesn't contain very interesting
>data.

Sigh.  The SIRS database had a well-justified reputation for being
a thoroughly bad approach to the problem.  You could do a HELL of
a lot better, and quite a few people did.

In particular, you DO NOT search like that.  You ensure that there
are MULTIPLE search terms, and accumulate the INFORMATION that they
provide.  A ubiquitous symptom like SIGSEGV invariably counts
low on its own, for the obvious information theoretic reasons.


Regards,
Nick Maclaren.

On Sun, 06 Jul 03 08:13:46 GMT
jmfbahciv@aol.com wrote:

JC> How many ways can you convert from ASCII to SIXBIT?
JC> About the only difference is having the variable names differ.

	There's the one that takes two pointers (and coredumps on overflow),
the one that takes a pointer to ASCII and returns allocated storage, the
one that takes a pointer to ASCII and returns a static array (error on
overflow but repeat calls overwrite). Each has a variants that take
sizes for the ASCII or terminates on NULLs. If you have the wrong
headers some turn into macros. Then there are the three written by temps
that just get it wrong, and the one you didn't spot because it looked like
something completely different.

	I forgot to mention the ones that just differ in the order of the
arguments.

	It's not that there's good reason for the variations, just that
if you set a bunch of people top level designing similar systems (or
just different bits of one big system) then there will be this kind
of duplication because the common bits don't get seen together.

-- 
C:>WIN                                      |     Directable Mirrors
The computer obeys and wins.                |A Better Way To Focus The Sun
You lose and Bill collects.                 |  licenses available - see:
                                            |   http://www.sohara.org/

On Sun, 06 Jul 2003 13:08:28 +0200, Kjetil Torgrim Homme
<kjetilho@yksi.ifi.uio.no> wrote:

>
>"No Silver Bullet" doesn't concern itself with the success of hardware
>design at all. <snip>
>
It doesn't?  _Vide_:

"Not only are there no silver bullets now in view, the very nature of
software makes it unlikely that there will be any--no inventions that
will do for software productivity, reliability, and simplicity what
electronics, transistors, and large-scale integration did for computer
hardware."

"We cannot expect ever to see two fold gains every two years."

"First, one must observe that the anomaly is not that software
progress is so slow, but that computer hardware progress is so fast.
No other technology since civilization began has seen six orders of
magnitude in performance-price gain in 30 years. In no other
technology can one choose to take the gain in either improved
performance or in reduced costs. These gains flow from the
transformation of computer manufacture from an assembly industry into
a process industry."

He then goes into a fugue state where he muses incoherently on why
software development should be any different.  His musings include the
flat-out ludicrous:

"Software systems have orders-of-magnitude more states than computers
do."

How, exactly, does a software system get into any state at all without
the aid of a computer?  And if the software is in some state the
computer can't be in, I want to examine the computers Brooks has been
using.

He gets close to the actual explanation:

"We still make syntax errors, to be sure; but they are fuzz compared
with the conceptual errors in most systems."

but fails to observe that it is the imprecision of computer languages
that allows us to construct software that doesn't necessarily map
unambiguously into hardware, and the point gets lost in his own
conceptual fuzz.

>do we have any indication that hardware development is more efficient
>than software development, anyhow?

Brooks seems to think so.

>if so, one reason could be that
>the hardware design can be chosen on pure technical merits -- no
>business logic or similarily arbitrary customer requirements to worry
>about.
>

At one point, comp.arch got off onto a gab fest about everybody's
favorite computer language.  I gave up trying to follow it.  Software
engineers invent new languages the way some people send e-mails.

At every step, they invite new semantic confusion and never once stop
to worry about the formal consequences of what they are doing.
Hardware design might suffer from a similar madness but for one thing:
at the end of the day you have to cut metal.  That's why there are so
few hardware design languages and why their formal properties are so
much more closely scrutinized.  Formal errors in hardware design
languages tend to make themselves painfully apparent, with or without
the help of someone who understands the predicate calculus.

>(did you read "``No Silver Bullet'' refired", btw?)

No, but I will try to find it.  I try to keep my mind open.

RM

"Robert Myers" <rmyers@rustuck.com> wrote in message
news:5hgggv0r0p4ib34hjm191dosf8pk8a10qs@4ax.com...
[SNIP]

> At every step, they invite new semantic confusion and never once stop
> to worry about the formal consequences of what they are doing.

That's not true for all... There are a number of very
tidy languages that have clear semantics out there...
It's just that most people dismiss them and fire up
a C compiler instead because it's what they know or
what every one else uses.

Cheers,
Rupert

In article <bduor2$392$1@pegasus.csx.cam.ac.uk>, Nick Maclaren wrote:

>|> I have very little experience of software outside the PC mass-market.
>|> Is this something that I'd find in other kinds of computer system?
> 
> Rarely, but it used to more common.

Some software still does this on a regular basis.

For some reason we seem to mostly do it for communications software, as
if it were the only type to benefit from logging.

> What the system COULD do is to provide some decent tools for such
> diagnosis - such as being able to log all signals, with source,
> destination and properties.  HP-UX certainly used to be able to
> do a lot of this, under the name of auditing.  And most mainframes
> could, of course.

One problem though, is that software is now much more complex.

Just following a trace of Netscape, for example, would take a long time,
and its hard to break up into a team effort.

Have you looked at a program trace of some current software?

It may well take man YEARS to trace some software.

I'm not against doing it, but there are some logistical reasons for its
absence.  They rather fly blind than try to tackle the problem from that
end.

-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

In article <bdvemq$lir$1@pegasus.csx.cam.ac.uk>, Nick Maclaren wrote:

> But I don't know what jmfbahciv is on about.  Simple networks ARE
> easier to fix than complex ones - MUCH easier.  Small ones are
> also easier than large ones, but it is a minor effect (with the
> difficulty going up perhaps as the logarithm).

Yes, but I disagree on the part about simple != small, at least in terms
of their effect on difficulty.

Large networks are also harder to deal with than small ones.


-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

[Robert Myers]:
>
>   [Kjetil Torgrim Homme]:
>   > "No Silver Bullet" doesn't concern itself with the success of
>   > hardware design at all.
>
>   It doesn't?  _Vide_:
>   
>   "Not only are there no silver bullets now in view, the very nature
>   of software makes it unlikely that there will be any--no
>   inventions that will do for software productivity, reliability,
>   and simplicity what electronics, transistors, and large-scale
>   integration did for computer hardware."

the building blocks improved, not the circuit layouts (well, certainly
not by an order of magnitude).  the cores of the CPUs haven't grown
that much, either.  duplicating functional units and making caches
larger and access wider is where the transistor budget goes.

>   "We cannot expect ever to see two fold gains every two years."
>   
>   "First, one must observe that the anomaly is not that software
>   progress is so slow, but that computer hardware progress is so
>   fast.  No other technology since civilization began has seen six
>   orders of magnitude in performance-price gain in 30 years. In no
>   other technology can one choose to take the gain in either
>   improved performance or in reduced costs. These gains flow from
>   the transformation of computer manufacture from an assembly
>   industry into a process industry."

process improvements, not improvements in how to design.

>   He then goes into a fugue state where he muses incoherently on why
>   software development should be any different.  His musings include the
>   flat-out ludicrous:
>   
>   "Software systems have orders-of-magnitude more states than
>   computers do."

I noticed that, too ;-)

>   How, exactly, does a software system get into any state at all
>   without the aid of a computer?  And if the software is in some
>   state the computer can't be in, I want to examine the computers
>   Brooks has been using.

the system is more than the computer.  he may be thinking of human and
other system interactions.

>   He gets close to the actual explanation:
>   
>   "We still make syntax errors, to be sure; but they are fuzz
>   compared with the conceptual errors in most systems."
>   
>   but fails to observe that it is the imprecision of computer
>   languages that allows us to construct software that doesn't
>   necessarily map unambiguously into hardware, and the point gets
>   lost in his own conceptual fuzz.

do you really think so?  sounds like a straight-jacket to me -- the
language gets too intimately connected to the hardware.  imprecision
is necessary for abstraction.  when I say (in Ruby)

  collection.each {|e| e.display}

I don't have to know if collection is an array, a linked list, a hash.
I don't have to know what kind of objects are in the collection.  I
don't have to know what output device is hooked up as default.

worrying about exactly how my code maps onto hardware doesn't seem
useful.

>   > do we have any indication that hardware development is more
>   > efficient than software development, anyhow?
>   
>   Brooks seems to think so.

I don't agree.

>   At one point, comp.arch got off onto a gab fest about everybody's
>   favorite computer language.  I gave up trying to follow it.
>   Software engineers invent new languages the way some people send
>   e-mails.

domain specific languages are a very successful technique for managing
complexity, so these are plentiful.  general purpose languages much
less so.

>   > (did you read "``No Silver Bullet'' refired", btw?)
>   
>   No, but I will try to find it.  I try to keep my mind open.

it's in the anniversary edition of "The Mythical Manmonth".

-- 
Kjetil T.			|  read and make up your own mind
				|  http://www.cactus48.com/truth.html

"Charles Richmond" <richmond@ev1.net> wrote in message
news:3F080798.73D84486@ev1.net...
> Russell Wallace wrote:
> >
> >         [snip...]         [snip...]         [snip...]
> >
> > Some years ago my fridge packed it in, the pump just quietly stopped
> > working. (Annoyingly, it was a few months out of warranty at the time.
> > The quote for a repair was close to the cost of a new fridge so I
> > didn't bother getting it repaired.)
> >
> > If I'd been storing scarce and vital medical supplies in it at the
> > time, presumably lives could have been lost. But the blame wouldn't
> > rest with the manufacturer, it would rest with my criminal negligence
> > in using ordinary consumer products for safety-critical tasks. I
> > assume hospitals use better equipment for storing medical supplies. I
> > also assume nobody would be stupid enough to demand I pay for
> > safety-rated refrigeration equipment when all I want to put in it is
> > milk and frozen pizza. I wish I could make those assumptions in the
> > software industry.
> >
> But it seems that "it works most of the time" is good enough
> even for the space shuttle. I have *no* churlish objections
> to saving money...but some are so damn interested in saving
> a few cents here and there, that safety and reliability of
> systems are often compromised. IMHO.


This is usually the point at which someone mentions "Therac-25" ...
.... but I don't want to do that.

-- 

   ...  Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net

On Sun, 06 Jul 2003 19:08:53 +0200, Kjetil Torgrim Homme
<kjetilho@yksi.ifi.uio.no> wrote:

>[Robert Myers]:
>>
>>   [Kjetil Torgrim Homme]:
<snip>

>
>>   He gets close to the actual explanation:
>>   
>>   "We still make syntax errors, to be sure; but they are fuzz
>>   compared with the conceptual errors in most systems."
>>   
>>   but fails to observe that it is the imprecision of computer
>>   languages that allows us to construct software that doesn't
>>   necessarily map unambiguously into hardware, and the point gets
>>   lost in his own conceptual fuzz.
>
>do you really think so?  sounds like a straight-jacket to me -- the
>language gets too intimately connected to the hardware.  imprecision
>is necessary for abstraction.

I don't *think* you mean that last sentence in the way that I
literally read it, but let's just tuck that thought away without
confronting it.

A mind as modest as mine has room for only a few very big ideas, but
here is one of them, and I learned it long before I knew how to do
anything really useful with it:

The only way to rid a method, theory, statement, or analysis of hidden
assumptions is to reduce it to a string of ones and zeroes that can be
formally manipulated by well-defined rules to adduce other needed
results.

This is roughly the agenda of Whitehead et.al., and it has known
limitations, but I am extremely suspicious of any other way of
proceeding.

My understanding of theoretical computer science is at such a
primitive stage that there may be less restrictive ways of achieving
my goal than insisting that everything be unambiguously realizable in
hardware, but it is the easiest condition for me to state.

If there has to be a human in the loop for the analysis to proceed, I
am suspicious.  A program by itself conveys meaning only if it is
semantically unambiguous.  If the meaning of the program depends on
the compiler, on the machine it runs on, and especially on who is
reading it, then the program has no meaning, as far as I am concerned.
The easiest way for me to ensure that none of those things are
required is to say: "Show me the hardware."  I am open, even eager,
for other suggestions.

> when I say (in Ruby)
>
>  collection.each {|e| e.display}
>
>I don't have to know if collection is an array, a linked list, a hash.
>I don't have to know what kind of objects are in the collection.  I
>don't have to know what output device is hooked up as default.
>

Ruby looks like a gorgeous language.  I'd probably learn how to use
it, except that I don't understand the languages I already "know".

RM

In article <be12he$npi$1@bob.news.rcn.net>, jmfbahciv@aol.com wrote:

> Think about a magtape full of files.  Now your job is to put a
> checksummed directory at BOT of the contents of that tape.
> Note that a magtape can only be written from beginning to end.
> How do you put a directory of the tape at BOT (beginning of tape)
> when you haven't written the tape yet?

That's not a hard problem.

dump on UNIX does this, has for many years.

You read the files to back up, and do those calculations before the
actual dump.  Trivial.

You can even do it with nothing more than dd and tar.


-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

In article <r0fggvkb9890d2d60b8g5ghvkmc6phk6q9@4ax.com>,
Robert Myers  <rmyers@rustuck.com> wrote:
>On 6 Jul 2003 11:27:16 GMT, nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>
>>What you do is to track "syndromes".  You keep a database of factors
>>and symptoms, with an indication of the reliability of the data.
>>You then match the factors and symptoms of the unknown problem
>>against the data you have, and come out with a probabilistic ranking.
>>Very simple, very easy and very effective.
>>
>>The key here is that you MUST have human experts in the loop, to
>>deal with new syndromes and MUCH MORE IMPORTANTLY suprious matches.
>>This isn't hard to achieve, if you ensure that both the experts and
>>the initial advisors use the same database and search engine.  Its
>>been done many times, and it works.
>>
>*Very* nice suggestion.  I don't think it will ever happen.

You mean that you don't think that it will ever happen again?

>At some level human beings think something or other they don't quite
>understand, perhaps even a "divine creator",  put together the human
>body, and thus they are reasonably humble in diagnosing what goes
>wrong with it.
>
>People who build computers and write software for them suffer from the
>delusion that because they have created said items, they understand
>them.  The first step toward addressing the problem that bedevils you
>in this respect would be for the divine creators of computers to admit
>that, like most human beings, they don't really understand all the
>ramifications of what they are doing.

By this definition, I am not human :-)

>And don't forget, Nick, when in this mode you, too, are a "luser".

Forget it?  When I am reminded of it many times a day?


Regards,
Nick Maclaren.

[Robert Myers]:
>
>   [Kjetil Torgrim Homme]:
>   > do you really think so?  sounds like a straight-jacket to me --
>   > the language gets too intimately connected to the hardware.
>   > imprecision is necessary for abstraction.
>   
>   I don't *think* you mean that last sentence in the way that I
>   literally read it, but let's just tuck that thought away without
>   confronting it.

to clarify:

during coding, the meaning of the code is loose, or open-ended.  the
library code I write can be passed objects of unknown classes as long
as they conform to the API.  and if not now, then such a use may
happen a couple of years from now.

during execution, all the additional modules are known and linked into
the program, and the exact meaning of the code can be traced out
either by a human or a computer.

>   A mind as modest as mine has room for only a few very big ideas,
>   but here is one of them, and I learned it long before I knew how
>   to do anything really useful with it:
>   
>   The only way to rid a method, theory, statement, or analysis of
>   hidden assumptions is to reduce it to a string of ones and zeroes
>   that can be formally manipulated by well-defined rules to adduce
>   other needed results.

how is this string of ones and zeroes related to the hardware?  the
transformation is too big an idea for my mind :-).  it seems to me
you'll bump into that pesky Halting Problem.

-- 
Kjetil T.			|  read and make up your own mind
				|  http://www.cactus48.com/truth.html

On 6 Jul 2003 19:04:22 GMT, nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:

>In article <r0fggvkb9890d2d60b8g5ghvkmc6phk6q9@4ax.com>,
>Robert Myers  <rmyers@rustuck.com> wrote:

>>*Very* nice suggestion.  I don't think it will ever happen.
>
>You mean that you don't think that it will ever happen again?
>
I took your post to mean that it had been done in the area of medical
diagnosis and not in the area of computers.  If it has been done in
the area of computers, some links or search suggestions would be nice.

There *must* be software that someone like the CDC uses for this
purpose.  Wonder what it looks like?

I might also point out that, each time a medical researcher identifies
a new syndrome, his chances of career advancement and high honors
increase tremendously.  Each time a computer analyst identifies a new
syndrome, his chances of being swept off to the unemployment lines
increase tremendously.

RM

Russell Wallace wrote:

> On Sat, 5 Jul 2003 15:52:22 +0000 (UTC), peter@abbnm.com (Peter da
> Silva) wrote:
> 
>>Pretty much any service industry I can think of. Ask a chef about
>>McDonalds some time. And I know my auto mechanic must think I'm a
>>total loser by now.
> 
> Heh, fair enough, so it's not peculiar to our industry then.

What *is* interesting, though, is working in a branch of science that 
everybody knows he's gonna do better than the experts.

Weather forecasting.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

In article <3F087880.5020003@moene.indiv.nluug.nl>,
Toon Moene  <toon@moene.indiv.nluug.nl> wrote:
>Russell Wallace wrote:
>
>> On Sat, 5 Jul 2003 15:52:22 +0000 (UTC), peter@abbnm.com (Peter da
>> Silva) wrote:
>> 
>>>Pretty much any service industry I can think of. Ask a chef about
>>>McDonalds some time. And I know my auto mechanic must think I'm a
>>>total loser by now.
>> 
>> Heh, fair enough, so it's not peculiar to our industry then.
>
>What *is* interesting, though, is working in a branch of science that 
>everybody knows he's gonna do better than the experts.
>
>Weather forecasting.

Well, that was true until c. 1960.  "The same as yesterday" was
better than almost every computer model :-)


Regards,
Nick Maclaren.

On Sun, 06 Jul 03 08:13:46 GMT in alt.folklore.computers,
jmfbahciv@aol.com wrote:

>In article <FIGNa.289$X33.34663567@newssvr14.news.prodigy.com>,
>   "Andy Glew" <andy-glew@sbcglobal.net> wrote:
>>> This is the fundamental failing of the Structured Programming
>>> zealots.  They didn't eliminate complexity; they just moved it
>>> from individual modules to the relationships between them.
>>
>>My view is that structured programming
>>emphasized top down design,
>>resulting in little code reuse
>
>I don't call that top-down.
>
>>because they always wanted to design
>>slightly different low level and mid-level modules

Those people forgot that routines should also be functional and
layered, so that upper level code handles abstract concerns, and
the lower level code only handles the details, but generically.
Their code is often such a mish-mash of abstract concerns and
housekeeping detail that it's hard to see what a chunk of code is
actually trying to achieve.

>How many ways can you convert from ASCII to SIXBIT?
>About the only difference is having the variable names differ.

Some of the examples I have seen include assumptions about the
lengths of the inputs (like one word/more) or outputs (one
word/more), or expectations of restricted contents of the inputs
or outputs (upper case/digits), or differing return values
(number of input/output chars/words converted/pointer to last
input/output char/word converted).

Mixing upper level issues (contents, units, desired return
values) with lower level issues (addresses, lengths, results)
avoids doing any setup, takedown, housekeeping, or conversion of
inputs, outputs, or return values, on either side of the
interface.
But you end up with a whole bunch of different chunks of code
that do very similar jobs slightly differently.

If you want to hide all the housekeeping details, you should
write wrapper functions that do the specific housekeeping for
each of these cases, and have all the wrapper functions call one
generic conversion function that passes back enough information
to allow each of the wrappers to do their work easily.
Whether you write a bunch of wrapper functions or just do the
appropriate housekeeping inline in each of the callers is just a
matter of style and taste IMHO.
If you have a consistent development style in the first place,
you should be calling a utility function in a similar situation
from a code leading up to calling these functions, so should only
need a single interface to a conversion function.

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply

In article <bds57k$quf$1@pegasus.csx.cam.ac.uk>, Nick Maclaren wrote:

> You might be surprised at how few software vendors have a reputation
> for honouring the spirit (or even the letter) of their contracts.
> The real question is how badly they let you down.  Their problem is
> that, IF they took every little bug and other fault seriously, they
> would go broke.

I'm not so sure.

In fact, I think part of the reason they _might_ go broke is because
they have been so bad about debugging.

It increases costs all around, and the problem tends to build up, not go
away.

-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

In article <g0b3eb.ebu1.ln@acer>, Morten Reistad wrote:

> In my PPOE I had responsability for taking over web-stuff that was
> moved to the ISP to run in production there. This stuff was almost
> exclusively developed by PHB's running a lot of buzzword-correct 
> script kiddies. Lots of Java, databases and huge stuff. This was
> in the middle of the dotcom boom.
> 
> Around 3/4ths of these projects never got out of development because
> the software couldn't run without handholding. Failed elementary
> stability and load tests with flying colours. So even if the 
> business cases had been solid (most weren't) they were doomed
> anyhow.

I was in the middle of that boom, and I hated it.  Making things work
correctly was an afterthought at best.

But then, consider how the software was sold: we had graphic artists
draw the applications and create pages with these graphics, and that is
what was sold to the customer.

They'd click on an image of the city they lived in, and a real-time
display of every car for sale in that city would pop up.

It never occured to anyone selling this stuff that a computer cannot
"scan a city for used cars".  This was implicit in their demo, and they
sold it to the customer.

Then they waited, impatiently, while we made half-baked efforts to make
some kind of illusion happen for them.

Questioning the wisdom of any of this, or trying to stop dangerous
things from happening was a career-limiting move, or maybe even a firing
offense.

> And we can still program in FORTRAN!

Sadly, I can too, or I could if I studied again.

I had to maintain some FORTRAN that was just as bad as a lot of the
script-kiddie crap I've worked with.

One thing I have always said is that computers are overused, and I think
because so many uses are not really important, it has numbed users and
"leaders" to their failures.

The obvious negative side-effect is that this spills over into computer
usage which really is needed, and which needs to be done properly.

-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

In article <QItNa.2981$9f7.316980@news02.tsnz.net>, Brian Boutel wrote:

> I heard a talk by a lawyer last week. He had moved his firm totally off 
> MS products. He told MS why, and they said "but we wouldn't ever do 
> that", so he said, "In that case let's remove the nasty bits from the 
> agreement", and they said "No".

Exactly.

Have you read some of the licensing information about things like Word?

I remember legal staff in one shop were alarmed because it basically
said that they owned the files you created.

That's pretty damned scary when you think about Longhorn, and the idea
you will use Microsoft servers just to run it.


-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Robert Myers wrote:
> "Not only are there no silver bullets now in view, the very nature of
> software makes it unlikely that there will be any--no inventions that
> will do for software productivity, reliability, and simplicity what
> electronics, transistors, and large-scale integration did for computer
> hardware."

The main point why hardware still manages to increase part numbers without 
much problems is that doesn't increase complexity. A 1GBit DRAM is only 
modestly more complex than a 256MBit DRAM (and most of that additional 
complexity comes from beefed up interfaces). The main point of a CPU-based 
system is that you can move up all the real complexity into the software 
domain. And when you don't, you'll fail with hardware pretty soon, too.

My advice to hardware designers is that whenever you face some modestly 
complex or frequent silly requirement changes from the user, build in a 
CPU, and do those parts that are complex or change often in software. It's 
cheaper that way to change it (even a ROM mask is only one mask, and a lot 
easier to handle than rewiring spare cells and such), and easier to 
develop. Yes, you can turn software into hardware, but if you keep it 
software, it's easier.

Software fails to handle complexity, because it can't easily put up pressure 
against it. The hardware guys can move it over to the software guys. The 
customer, on the other hand, pushes all his complexity requirements into 
the software layer, too, and there's usually no way to push the customer to 
accept something simpler.

When you are in the same position as hardware designer (e.g. because the 
customer makes the software and puts pressure on you to accept all his 
ill-adviced feature requests), hardware design complexity goes up through 
the roof. However, since the cost of hardware complexity are easier to see, 
this doesn't go on and on.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

On Sun, 06 Jul 2003 21:06:18 +0200, Kjetil Torgrim Homme
<kjetilho@yksi.ifi.uio.no> wrote:

>[Robert Myers]:
>
>>   A mind as modest as mine has room for only a few very big ideas,
>>   but here is one of them, and I learned it long before I knew how
>>   to do anything really useful with it:
>>   
>>   The only way to rid a method, theory, statement, or analysis of
>>   hidden assumptions is to reduce it to a string of ones and zeroes
>>   that can be formally manipulated by well-defined rules to adduce
>>   other needed results.
>
>how is this string of ones and zeroes related to the hardware?

The output file produced by a hardware synthesizer is such a string of
ones and zeroes that maps directly to hardware.

People don't commonly code in verilog or VHDL, but if they did, they
could always produce a chip that corresponded to their software.
SystemC is a language that is useful for high-level analysis and
simulation of hardware designs and whose formal properties are
understood, but there is, apparently, no hardware synthesizer for it.
Even at that, people don't code in SystemC.

>the transformation is too big an idea for my mind :-).

If you're aiming at that transformation for c, it's too big for
anybody's mind, because c is too semantically-ambiguous to serve as a
hardware design language.

If you're willing to start with a hardware design language that has a
hardware synthesiser as a back end, you don't need to wrap your own
mind around it.  It's been done for you.

The fundamental issue here is semantic ambiguity, not the ability to
reduce an algorithm to hardware.  As Rupert Pigott has pointed out,
there are semantically unambiguous languages that aren't hardware
design languages.  I went the hardware design language route because
it directly exposes the flawed thinking of "No Silver Bullet".

>it seems to me you'll bump into that pesky Halting Problem.

Or, more to the point, the Incompleteness Theorem, which is equivalent
to the Halting Theorem, and which stopped the agenda of Whitehead et
al dead in its tracks.  The fact that the Halting Theorem is out there
doesn't stop people from building computers and writing programs, nor
should it, and the existence of the Incompleteness Theorem (or the
Halting Theorem) shouldn't stop people from declining to work with
hardware and software whose formal properties cannot even be stated
without ambiguity.

RM

On Mon, 07 Jul 2003 00:12:35 +0200, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>
>Software fails to handle complexity, because it can't easily put up pressure 
>against it. The hardware guys can move it over to the software guys. The 
>customer, on the other hand, pushes all his complexity requirements into 
>the software layer, too, and there's usually no way to push the customer to 
>accept something simpler.
>

The problem you are identifying is social, not technical.  That
doesn't make it any less of a problem, but this thread started and
Brooks pursued statements that purported to be technical, not social,
in nature.

Every engineer soon learns that, no matter what the product, there is
always a customer that wants more.  Almost everyone in any kind of
business soon learns that "Sorry, we can't do that," is almost always
the wrong answer.  Businesses overpromise under pressure from
customers, and customers go to bed at night cursing the people they
have pressured into lying to them.  This reality of commerce predates
the electronic computer by at least as long as people have had means
for quantifying promises.

The business I have the most experience in, large codes to support
engineering design, presents almost a _reductio_ad_absurdum_ of the
interplay between customer pressure and the realities of business.  As
pointed out by others, even one digit of accuracy will suffice under
some circumstances, and a competent and resourceful engineer with a
calculator, a sheet of paper, and access to the literature can as
often as not do well enough without the assistance of a computer.

In fact, one of the principal means for deciding whether one of those
big codes is working or not is to see whether it agrees with problems
whose answers are already known.

Thw whole point of the code, though, is to provide answers to problems
where the answer isn't known, and I know from long and miserable
experience that the overwhelming pressure is to get the answer the
customer wants on the schedule the customer wants it and not to do
scientifically and mathematically credible work.

I've taken apart enough of those codes to know that, more often than
not, the people who designed them might have been sincere, but that
they didn't really know what they were doing.  The close scrutiny of
the software almost always resulted from the software yielding an
answer the customer didn't want, not from any desire to enhance the
credibility of the work.

In fact, the way these codes are used is often embarrassing.  They are
used, as the saying goes of scripture, the way a drunk uses a
lamppost, more for support than for enlightenment.  If the code that a
contractor ran (I believe it was Boeing) had shown that there was a
problem resulting from foam hitting the left wing of the shuttle on
takeoff, you can bet that people would have been flown in from
everywhere to breathe down the neck of the guy unfortunate enough to
have come up with the wrong answer.  As it is, the code said there was
unlikely to be a problem.  *That* was the answer the customer wanted
to hear.

The tools exist to do *much* better work, but as Thoreau learned when
he had invented a more accurate means of measuring cordwood, accuracy
isn't what people are really interested in.

I am sure that there is some analog of this problem in every aspect of
computing.

>When you are in the same position as hardware designer (e.g. because the 
>customer makes the software and puts pressure on you to accept all his 
>ill-adviced feature requests), hardware design complexity goes up through 
>the roof. However, since the cost of hardware complexity are easier to see, 
>this doesn't go on and on.

And people are much more reluctant to fudge it with hardware.  With
software, you deliver whatever you can in the the time and budget that
are available.  If it proves to be inadequate, you say "Oops," and, if
you're really lucky, the customer pays you to make it better.  It
doesn't work that way with hardware.

RM

In article <RWSNHvAMC+B$EwvV@mooremusic.org.uk>, Ken Moore wrote:
> In article <avf5eb.e9h.ln@escape.shannon.net>, Charles Shannon Hendrix
> <shannon@news.widomaker.com> writes
>>The failure of the Galactic Empire was drawn right out of his own very
>>local observations.
> 
> He wrote somewhere that it resulted from his reading Gibbon: "The
> Decline and Fall of the Roman Empire".

Certainly ideas about the periphery match well.

I wonder if the idea of the galactic encyclopdia came from the roman
soldiers destroying libraries during conquest?



-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Kjetil Torgrim Homme wrote:
> 
> [Charles Richmond]:
> >
> >   [jmfbahciv@aol.com]:
> >   > [Charles Richmond]:
> >   > > [Peter da Silva]:
> >   > > > "The only intuitive interface is the nipple"
> >   > >
> >   > > Would that be the "user device from heaven", as adverse to the
> >   > > "user device from hell"???
> >   >
> >   > This must be a "guy thing".
> >
> >   Excuse me. Every baby that I know of...gained sustenance at one
> >   time or another...through a nipple...regardless of gender. And
> >   they all seemed satisfied.
> 
> did you ever see a baby that didn't need to be _taught_ how to use the
> nipple?
> 
I don't have a baby handy to test it...but the sucking response
is supposed to be instinctive, IIRC.

--
+----------------------------------------------------------------+
|   Charles and Francis Richmond     richmond at plano dot net   |
+----------------------------------------------------------------+

 > >But it seems that "it works most of the time" is good enough
> >even for the space shuttle.
> 
> And after the loss of fourteen lives and two spacecraft worth a couple
> of billion dollars each, I'd imagine the people who made the relevant
> decisions are regretting them.

They more or less explicitly said they aren't - basically, they don't
understand what the discussion is about. And to a large degree, they are
correct: space travel is an inherently more dangerous way of transport
than, say, walking, and it still is at the level of exprience air transport
had in about 1916. 

And the Shuttle software is among the best in the world.

	Jan

Robert Myers <rmyers@rustuck.com> wrote in message news:<868hgvsup40miaat57vcuncqtl2tq6gllo@4ax.com>...
> On Sun, 06 Jul 2003 21:06:18 +0200, Kjetil Torgrim Homme
> <kjetilho@yksi.ifi.uio.no> wrote:
> 
> >[Robert Myers]:
> >
> >>   A mind as modest as mine has room for only a few very big ideas,
> >>   but here is one of them, and I learned it long before I knew how
> >>   to do anything really useful with it:
> >>   
> >>   The only way to rid a method, theory, statement, or analysis of
> >>   hidden assumptions is to reduce it to a string of ones and zeroes
> >>   that can be formally manipulated by well-defined rules to adduce
> >>   other needed results.
> >
> >how is this string of ones and zeroes related to the hardware?
> 
> The output file produced by a hardware synthesizer is such a string of
> ones and zeroes that maps directly to hardware.
> 

To be more accurate, synthesis translates HW design written in
structural or register transfer level (RTL) or dataflow style into a
netlist of primitives such as ASIC gates & flops or FPGA LUTs-CLBs.
That netlist is then handed off to a place & route tool. For the FPGA
a .bit file might be stored in eeprom or simple smartmedia (a few
Mbytes) & placed near the FPGA. So .bit files are alot like SW boot
code but are not easy to reverse engineer or manipulate and may well
be encrypted.

> People don't commonly code in verilog or VHDL, but if they did, they
> could always produce a chip that corresponded to their software.
> SystemC is a language that is useful for high-level analysis and
> simulation of hardware designs and whose formal properties are
> understood, but there is, apparently, no hardware synthesizer for it.
> Even at that, people don't code in SystemC.
> 

A small transparent compiled subset of Verilog combined with a C env
and Occams channel rendezvous model is a language I think SW AND HW
types could both use for modelling and sythesizing HW like systems. It
would allow some compute applications to be pushed towards HW (or the
reverse) by remaining compatible with both Verilog subset for
synthesis and C for seq-par behavioural coding.

I don't see SW types even looking at HDLs let alone using them in
their current form. For that to happen, a useful HDL subset is needed
that remains compatible with the original language, but also doesn't
swamp SW person with stuff that just ain't needed like 10xz states,
table driven primitives, limited 80s style IO, incoherent assignment
semantics, transister modelling etc.

I will leave it at that for now
JJ

> >     They just advertised in the local paper for someone to do the
> >work.  I wonder if I will find out the end to the story.
> "In short, being innovative [...]

The problem being that almost all of the work in IT is not, and has no
need to be, innovative at all - application of common sense, some rules
of thumb and a little (engineering/handiwork) discipline would surely
suffice. But all these are irrelevant in this sector of businesses.

	Jan

> "Software systems have orders-of-magnitude more states than computers
> do."
> How, exactly, does a software system get into any state at all without
> the aid of a computer?  And if the software is in some state the
> computer can't be in, I want to examine the computers Brooks has been
> using.

The usual argument is that only the processor internal state (sans cache
etc) counts against the hardware state, while all of memory counts against
software state. Memory bits being more numerous by far than flip-flops in
a processor, "order-of-magnitude" is in fact understating it vastly.

	Jan

On Sun, 06 Jul 2003 12:55:07 GMT in alt.folklore.computers, Kai
Harrekilde-Petersen <khp@harrekilde.dk> wrote:

>wallacethinmintr@eircom.net (Russell Wallace) writes:
>
>[liability for software vendors:]
>
>> What I'm arguing against is the crazy notion that everyone should be
>> forced to use software engineered to that reliability level for all
>> purposes, including word processing and reading Usenet.
>
>How much lower than today's standards can you get? - right now, the
>average EULA basically says "Bend over, grease up. We've run with your
>money, and there's nothing you can do to stop us from doing that":
>IANAL, but the standard clause of denial of "merchantability and
>fitness for a particular purpose" says just that to me.

But that clause is invalid in many legal jurisdictions when the
software is bought by a consumer and not a corporation.

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply

On Mon, 07 Jul 2003 09:18:08 +0200, Jan C.
=?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de> wrote:

>They more or less explicitly said they aren't - basically, they don't
>understand what the discussion is about. And to a large degree, they are
>correct: space travel is an inherently more dangerous way of transport
>than, say, walking, and it still is at the level of exprience air transport
>had in about 1916. 

True as far as it goes, but: if I understand correctly, at least in
the Challenger case, they knew about the problem and had decided
(perhaps correctly) that they could get away with it by not launching
in cold weather - then some manager decided for some reason to order a
launch to proceed on the coldest day on record.

>And the Shuttle software is among the best in the world.

*nods* 2+ decades of operation without a single serious problem.

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace

On Tue, 1 Jul 2003 22:53:40 +0000 (UTC) in
alt.folklore.computers, Sander Vesik <sander@haldjas.folklore.ee>
wrote:

>In comp.arch J Ahlstrom <jahlstro@cisco.com> wrote:
>> 
>> 
>> Robert Myers wrote:
>>> 
>>> FWIW:
>>> 
>>> http://www.jdmag.wpafb.af.mil/bogus%20parts.pdf
>>> 
>>> "a single domestic passenger airplane alone can contain as many as 6
>>> million parts"
>> 
>> 5,900,000 of which are rivets ?
>> 
>
>And really - if somebody wants to compare the number of components in an 
>airplane to software, they should compare parts to opcodes. 

Complexity measures provide ways to do that for various types of
code.
Halstead's computational complexity and McCabe's cyclomatic
complexity both have correlations with ease of understanding,
testing, maintenance, reliability.
DoD and HP have both spent time and money to look at ways of
comparing modules and systems, test the results, and compare to
reality.
A good entry point is:
http://www.sei.cmu.edu/str/descriptions/mitmpm.html

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply

"john jakson" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0307062328.7a429781@posting.google.com...

[SNIP]


> table driven primitives, limited 80s style IO, incoherent assignment
> semantics, transister modelling etc.

Think of all the fun you could have with those ! Surely
the would be a valuable addition to the obfuscator's
art ! As long as there is a byzantine macro mechanism
in there we're laughing, the Obfuscated C contest would
look pretty tame by comparison...

Cheers,
Rupert

In article <r0fggvkb9890d2d60b8g5ghvkmc6phk6q9@4ax.com>,
   Robert Myers <rmyers@rustuck.com> wrote:
>On 6 Jul 2003 11:27:16 GMT, nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>
>>
>>What you do is to track "syndromes".  You keep a database of factors
>>and symptoms, with an indication of the reliability of the data.
>>You then match the factors and symptoms of the unknown problem
>>against the data you have, and come out with a probabilistic ranking.
>>Very simple, very easy and very effective.
>>
>>The key here is that you MUST have human experts in the loop, to
>>deal with new syndromes and MUCH MORE IMPORTANTLY suprious matches.
>>This isn't hard to achieve, if you ensure that both the experts and
>>the initial advisors use the same database and search engine.  Its
>>been done many times, and it works.
>>
>>
>*Very* nice suggestion.  I don't think it will ever happen.
>
>At some level human beings think something or other they don't quite
>understand, perhaps even a "divine creator",  put together the human
>body, and thus they are reasonably humble in diagnosing what goes
>wrong with it.
>
>People who build computers and write software for them suffer from the
>delusion that because they have created said items, they understand
>them. 

BULLSHIT!  I suggest you have never met a bit god.  I also suggest
that you wouldn't know one if s/he bit you.

<snip>

/BAH

Subtract a hundred and four for e-mail.

"Jan C. Vorbr�ggen" <jvorbrueggen@mediasec.de> wrote in message
news:3F091EB0.D47E1B1D@mediasec.de...
> > >But it seems that "it works most of the time" is good enough
> > >even for the space shuttle.
> >
> > And after the loss of fourteen lives and two spacecraft worth a couple
> > of billion dollars each, I'd imagine the people who made the relevant
> > decisions are regretting them.
>
> They more or less explicitly said they aren't - basically, they don't
> understand what the discussion is about.

As best I understand it, most of the discussion concerns the disconnect
between the expressed safety philosopy (that all known risks are carefully
*and honestly* evaluated) and its real-world implementation.  Both
Challenger and Columbia appear to have been lost due to such process
failures.

 And to a large degree, they are
> correct: space travel is an inherently more dangerous way of transport
> than, say, walking, and it still is at the level of exprience air
transport
> had in about 1916.

But the public posture of the space agency is far from the same as the
attitude toward flying in 1916.  And it's not clear how much support the
space program would have if that posture changed to be more consistent with
what seem to be actual operational attitudes.

- bill

In article <be9at5$ehl$1@pegasus.csx.cam.ac.uk>,
   nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>In article <be9244$6e1$7@bob.news.rcn.net>,  <jmfbahciv@aol.com> wrote:
>[ Re: tracking unrepeatable or variable problems. ]
>>>
>>>What you do is to track "syndromes".  You keep a database of factors
>>>and symptoms, with an indication of the reliability of the data.
>>>You then match the factors and symptoms of the unknown problem
>>>against the data you have, and come out with a probabilistic ranking.
>>>Very simple, very easy and very effective.
>>
>>yes, I know.  I'm talking about the specs of the data that is
>>under the heading "factors".  We used keywords.  You can sort on
>>them but they sure didn't reflect any kind of reality with a
>>one-to-one mapping from keyword to specific bug.
>
>Well, of course not.  Why should they?  They don't need to.  The
>combination merely needs to have a significant association, in
>the information theoretic (a.k.a. statistical) sense.  All very
>elementary - to a statistician!

Well, it would be useful to a _developer_ who has just encountered
the behaviour.  It isn't useful if he has to go to a statistician
first ;-).
>
>>>The key here is that you MUST have human experts in the loop, to
>>>deal with new syndromes and MUCH MORE IMPORTANTLY suprious matches.
>>>This isn't hard to achieve, if you ensure that both the experts and
>>>the initial advisors use the same database and search engine.  Its
>>>been done many times, and it works.
>>
>>I know it's been done before; we called it the SIRS data base.
>>My point is that it didn't work very well w.r.t. those stats
>>that you were talking about.  Anything could Ill mem ref.
>>Sorting all bugs using that keyword doesn't contain very interesting
>>data.
>
>Sigh.  The SIRS database had a well-justified reputation for being
>a thoroughly bad approach to the problem.

I know that but it's the only thing I ever met.

> ..  You could do a HELL of
>a lot better, and quite a few people did.

[testy emoticon here]  Why do you think I'm wasting your time?
I'm trying to learn.
>
>In particular, you DO NOT search like that.  You ensure that there
>are MULTIPLE search terms,

There was room for multiple keywords in the SIRS data base and
we were "forced" to fill them in.  I had a fucking difficult time
thinking of separate single words when a book was necessary to
describe some of the problems. 

> .. and accumulate the INFORMATION that they
>provide.  A ubiquitous symptom like SIGSEGV invariably counts
>low on its own, for the obvious information theoretic reasons.

Perhaps my brain is swapped out in idle mode, but I am having
a difficult time understanding how a finite set of independent
keys can be used to collect information about one bug when you
don't know what that bug is yet.  It's real easy when you're
looking backwards in time after the bug is understood.

/BAH

Subtract a hundred and four for e-mail.

On Mon, 07 Jul 2003 09:32:29 +0200 in alt.folklore.computers, Jan
C. Vorbr�ggen <jvorbrueggen@mediasec.de> wrote:

>> >     They just advertised in the local paper for someone to do the
>> >work.  I wonder if I will find out the end to the story.
>> "In short, being innovative [...]
>
>The problem being that almost all of the work in IT is not, and has no
>need to be, innovative at all - application of common sense, some rules
>of thumb and a little (engineering/handiwork) discipline would surely
>suffice. But all these are irrelevant in this sector of businesses.

ISTM the problem is that most management don't want to deal with
innovation, they want to pay a fixed price for a certain
function, with a given support cost, for which they can budget.

Other managers who want innovation seem to think that only
rookies can be innovative, the rest of the issues can be dealt
with by the proper management techniques, and the result is often
a totally useless piece of code that neither satisfies its
requirements nor performs a useful function, and drastically
overruns cost and time budgets as well.

Successful projects usually have some good, experienced,
competent programmers on the team who know how to meet
requirements and perform useful functions without having to
rediscover every failed approach used in the last fifty years.

I know part of a project is in trouble when I hear someone say
"we're going to try this...".
They don't have the foggiest clue what they're trying to achieve
or how to go about it.
They haven't done any analysis, design, looking up references, or
asking others, to try to figure it out.
So now they're playing with code on the off chance they'll
stumble across some approach that might fool some of the people
some of the time! 
Quoting Yoda: "Do, or do not. There is no try."

Until management recognize that they cannot provide a substitute
for some good, experienced, competent programmers, projects will
overrun; fail to: meet requirements, perform useful functions, or
satisfy users; and products will be insecure, unreliable, and
unstable.
These are all technical goals that you need good technical people
to achieve.

This is further exacerbated by allowing people selection, based
on unvalidated resume claims and pseudo-psychological testing, to
be influenced by HR, who haven't a clue about choosing staff who
aren't necessarily their kind of people (and probably wouldn't
want to be, who does?) but may just be an asocial genius some
group could use to get real work done.
RMS appears to be someone who might have a problem getting any
corporate job, despite his qualifications and experiences; I've
also met some successful product developers who have succeeded
despite (or possibly because of) a similar binary nature.

The few (early) times I accepted an employment offer (as opposed
to being inherited by a successor company), HR's function
appeared to be limited to validity checking and cross checking my
verbal and written claims.
I've since been interviewed for contracts with HR types sometimes
present asking touchy-feely kinds of questions, and whatever I
come up with appears to be within the norms of whatever they're
looking for nowadays.
Anyone know what's behind that touchy-feely kind of HR
questioning or have a pointer to an article about it?

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply

Robert Myers wrote:

> Thw whole point of the code, though, is to provide answers to problems
> where the answer isn't known, and I know from long and miserable
> experience that the overwhelming pressure is to get the answer the
> customer wants on the schedule the customer wants it and not to do
> scientifically and mathematically credible work.

Like the DIA slogan.

"If you want it real bad, you can get it *real bad*."

On Sun, 06 Jul 03 09:41:28 GMT in alt.folklore.computers,
jmfbahciv@aol.com wrote:

>In article <1rd6gnq5eb.fsf@glesvat.ifi.uio.no>,
>   Kjetil Torgrim Homme <kjetilho@yksi.ifi.uio.no> wrote:
>>[Robert Myers]:
>>>
>>>   On 2 Jul 2003 09:44:45 -0800, eugene@cse.ucsc.edu (Eugene Miya) wrote:
>>>   
>>>   >I would hold with the academic (Brooks) line that the degree of
>>>   >complexity exceeds anything so far known in the physical realm.
>>>   
>>>   I've had a second look at Brooks ('No Silver Bullet'), and a third,
>>>   and a fourth, and I'm not impressed, to put it mildly.
>>>   
>>>   I could tear his article apart line by line, but my objection
>>>   comes down to this: anything you can do in software you should be
>>>   able to do in silicon and vice versa.  The division between
>>>   hardware and software exists only in Brook's mind, and the
>>>   perpetuation of this fundamental error is made possible only by
>>>   the semantic ambiguity of languages, like c, that are commonly
>>>   used to write software.
>>
>>"No Silver Bullet" doesn't concern itself with the success of hardware
>>design at all.  turning software into hardware is not one of the
>>suggested silver bullets.
>>
>>do we have any indication that hardware development is more efficient
>>than software development, anyhow?  if so, one reason could be that
>>the hardware design can be chosen on pure technical merits -- no
>>business logic or similarily arbitrary customer requirements to worry
>>about.
>
>This [rated on purely technical merits] is what is wrong with
>hardware development (and has been for years).  Not having 
>the customer in mind sucks rocks.  Note that the definition 
>of a customer of a CPU designer is the OS developer.

If the OS is written properly, it is the compiler code generator.
Most of the CPU time should be used by applications to do useful
work, and OS overhead should be negligible under normal loads.
Most of the application code is likely to be generated by
compilers.

The architecture may have to support certain hardware features
and those must be accessible to the OS developer.
The rest of the instruction set is for moving and operating on
user data.

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply

In article <u5tigvs7cohajqc16e9ru1ll91cn8mfgd4@4ax.com>,
   Robert Myers <rmyers@rustuck.com> wrote:
>On Mon, 07 Jul 03 08:42:38 GMT, jmfbahciv@aol.com wrote:
>
>>In article <r0fggvkb9890d2d60b8g5ghvkmc6phk6q9@4ax.com>,
>>   Robert Myers <rmyers@rustuck.com> wrote:
>
>>>
>>>People who build computers and write software for them suffer from the
>>>delusion that because they have created said items, they understand
>>>them. 
>>
>>BULLSHIT!  I suggest you have never met a bit god.  I also suggest
>>that you wouldn't know one if s/he bit you.
>>
>I don't know about that, but I know an ignoramus when I encounter one.
>If you have rubbed shoulders with greatness, and they didn't take a
>shower afterward, shame on them.

One of them would take a shower afterwards, but not because
of my shoulder did the rubbing.

/BAH

Subtract a hundred and four for e-mail.

On Mon, 07 Jul 2003 10:45:12 GMT, Brian Inglis
<Brian.Inglis@SystematicSw.ab.ca> wrote:

>
>This is further exacerbated by allowing people selection, based
>on unvalidated resume claims and pseudo-psychological testing, to
>be influenced by HR, who haven't a clue about choosing staff who
>aren't necessarily their kind of people (and probably wouldn't
>want to be, who does?) but may just be an asocial genius some
>group could use to get real work done.
>RMS appears to be someone who might have a problem getting any
>corporate job, despite his qualifications and experiences; I've
>also met some successful product developers who have succeeded
>despite (or possibly because of) a similar binary nature.
>

There is a fairly straightforward way for organizations of any size to
deal with the RMS's of this world: hire them as consultants, not as
employees.  If an RMS *does* get hired as an employee, sooner or later
there will be a falling out.

I've watched even socially adept employees get ejected by
organizations like the immune system ridding the human body of an
invader because they didn't "fit in".  "Fitting in" often means
operating at an intellectual level that doesn't threaten your
co-workers, and I suspect that's the real reason Gene didn't get
hired.

RM

Jan C. Vorbr�ggen wrote:

>>"Software systems have orders-of-magnitude more states than computers
>>do."
>>How, exactly, does a software system get into any state at all without
>>the aid of a computer?  And if the software is in some state the
>>computer can't be in, I want to examine the computers Brooks has been
>>using.

> The usual argument is that only the processor internal state (sans cache
> etc) counts against the hardware state, while all of memory counts against
> software state. Memory bits being more numerous by far than flip-flops in
> a processor, "order-of-magnitude" is in fact understating it vastly.

Also, the bit-pattern in the machine has no meaning to the processor, it 
will do whatever you say to it.  But to *you* that's a signed number, or 
an unsigned number, or an address, or a subroutine to call, or an error 
code, or whatever.  The processor will print out the number in any 
format you choose, or fetch from the address, or execute the subroutine, 
etc.  It's all the same to the processor, it will just do whatever you 
say, none of it means anything to it.

But if you execute a number or an error code that means a lot to you. 
Store an error code in a subroutine likewise.

So I'll rephrase the question.

Is a printing press more complicated than a dictionary, or less complicated?

--------------060305080604080509050301
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Robert Myers wrote:

>On 2 Jul 2003 09:44:45 -0800, eugene@cse.ucsc.edu (Eugene Miya) wrote:
>
>  
>
>>I would hold with the academic (Brooks) line that the degree of
>>complexity exceeds anything so far known in the physical realm.
>>
>>    
>>
>
>I've had a second look at Brooks ('No Silver Bullet'), and a third,
>and a fourth, and I'm not impressed, to put it mildly.
>
>I could tear his article apart line by line, but my objection comes
>down to this: anything you can do in software you should be able to do
>in silicon and vice versa.  The division between hardware and software
>exists only in Brook's mind, and the perpetuation of this fundamental
>error is made possible only by the semantic ambiguity of languages,
>like c, that are commonly used to write software.
>
>Once you have translated software into gates, that is to say, once you
>have constructed the homology between software and a physical object,
>all the metaphysical distinctions that Brooks leans on vanish.  The
>fault that such a translation cannot be done from a typical c program
>lies with the inadequacies of the language c, and not with anything
>fundamental about software.
>
>RM
>  
>
If there is a 1st law of computer science, it  is  that
hardware and software are logically identical in their capabilities;
any logical thing that can be done in 1 can be done in the other.
The corrollaries are
   they are not physically identical
   they are not  financially identical
   they are not  identical in performance
    they are not identical in cost -performance
    they are not identical in time to implement
    they are not identical in time to debug

Brooks makes not metaphysical distinctions.  He makes vary practical ones.



-- 
Freedom of thought generated variety of thought 
which is the sine qua non of the development of thought 
          Acharya Mahapragya



--------------060305080604080509050301
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<br>
<br>
Robert Myers wrote:<br>
<blockquote type="cite"
 cite="midu78fgv8g9jreojl1fhavcjokdhjeprk9su@4ax.com">
  <pre wrap="">On 2 Jul 2003 09:44:45 -0800, <a class="moz-txt-link-abbreviated" href="mailto:eugene@cse.ucsc.edu">eugene@cse.ucsc.edu</a> (Eugene Miya) wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">I would hold with the academic (Brooks) line that the degree of
complexity exceeds anything so far known in the physical realm.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
I've had a second look at Brooks ('No Silver Bullet'), and a third,
and a fourth, and I'm not impressed, to put it mildly.

I could tear his article apart line by line, but my objection comes
down to this: anything you can do in software you should be able to do
in silicon and vice versa.  The division between hardware and software
exists only in Brook's mind, and the perpetuation of this fundamental
error is made possible only by the semantic ambiguity of languages,
like c, that are commonly used to write software.

Once you have translated software into gates, that is to say, once you
have constructed the homology between software and a physical object,
all the metaphysical distinctions that Brooks leans on vanish.  The
fault that such a translation cannot be done from a typical c program
lies with the inadequacies of the language c, and not with anything
fundamental about software.

RM
  </pre>
</blockquote>
If there is a 1st law of computer science, it &nbsp;is&nbsp; that<br>
hardware and software are logically identical in their capabilities;<br>
any logical thing that can be done in 1 can be done in the other.<br>
The corrollaries are<br>
&nbsp; &nbsp;they are not physically identical<br>
&nbsp; &nbsp;they are not &nbsp;financially identical<br>
&nbsp; &nbsp;they are not &nbsp;identical in performance<br>
&nbsp; &nbsp; they are not identical in cost -performance<br>
&nbsp; &nbsp; they are not identical in time to implement<br>
&nbsp; &nbsp; they are not identical in time to debug<br>
<br>
Brooks makes not metaphysical distinctions. &nbsp;He makes vary practical ones.<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="$mailwrapcol">-- 
Freedom of thought generated variety of thought 
which is the sine qua non of the development of thought 
          Acharya Mahapragya</pre>
<br>
</body>
</html>

--------------060305080604080509050301--

Peter da Silva wrote:
> Robert Myers  <rmyers@rustuck.com> wrote:

>>That's when the fun begins.  Interfaces are broken, hierarchies are
>>scrambled, and, before you know it, you might just as well have
>>skipped c++ and written the whole thing in c to begin with.

I don't think it works very well to enforce structured programming or OO 
or whatever.  They're supposed to be tools to help you get things 
working.  Not rules to limit your ability.

> That's why it's so important to find the right way to factor the code, and
> how throwing out 55,000 lines of code and keeping 5,000 can be progress.

The trouble is, it looks like a defeat.  It can be argued that you 
should have figured out the better way before those 55,000 lines were 
written.  Somebody looks bad, while if the better way doesn't get 
introduced nobody in particular looks bad unless some competitor does 
nearly the same thing much better.

> Contrariwise, when you come up with a factoring that really works well over
> a long period of time, you want to think really hard about whether you
> really need to change it.

> And if you're always having problems with a particular division of labour,
> then maybe it's a good idea to change how you're doing it.

> The UNIX programming model of things stuck together with file descriptors
> and later with sockets works pretty well. Sometimes it doesn't, but it
> works more often than it doesn't, and you can work on other interfaces
> without breaking it and end up with new ones... so you keep sockets and
> mmap and don't keep multiplexed files.

> Putting URL resolution in the operating system, however, has proven less
> of a good idea. Even if the Internet is robust.

What is an OS supposed to do, anyway?  It looks to me like split 
functions.  On the one hand you have a manager who has authority to 
mediate among his workers and bail them out when they get in trouble.

And on the other hand you have a librarian who provides a whole lot of 
commonly-needed services and standard methods.

In article <3F09220D.356DD28C@mediasec.de>,
Jan C. Vorbr�ggen  <jvorbrueggen@mediasec.de> wrote:
> The problem being that almost all of the work in IT is not, and has no
> need to be, innovative at all - application of common sense, some rules
> of thumb and a little (engineering/handiwork) discipline would surely
> suffice. But all these are irrelevant in this sector of businesses.

Not to mention that sometimes innovation is a bad thing. Sometimes a
feature is really a bug, even if you meant it to be there.

-- 
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate.  All
these things will be lost in time, like chalk-paintings in the rain.   `-_-'
Time for your nap.  | Peter da Silva | Har du kramat din varg, idag?    'U`

Robert Myers <rmyers@rustuck.com> writes:
> Once you have translated software into gates, that is to say, once you
> have constructed the homology between software and a physical object,
> all the metaphysical distinctions that Brooks leans on vanish.  The
> fault that such a translation cannot be done from a typical c program
> lies with the inadequacies of the language c, and not with anything
> fundamental about software.

Hardware description languages do not allow general recursion or memory
allocation, for rather obvious reasons (*). That makes them rather
different beasts than Java, C or Haskell.

*: I assume that somebody will immediately post a reference to a language
that does, so assume this sentence contains the word "typically".

-- 
David Gay
dgay@acm.org

"Robert Myers" <rmyers@rustuck.com> wrote in message
news:aavigvoqdd23r51ekhfolflut4vkvq25ud@4ax.com...
....
> I've watched even socially adept employees get ejected by
> organizations like the immune system ridding the human body of an
> invader because they didn't "fit in".  "Fitting in" often means
> operating at an intellectual level that doesn't threaten your
> co-workers, and I suspect that's the real reason Gene didn't get
> hired.

  Just try designing and writing PL/I in a shop of COBOL
  morons.  ("But I repeat myself.")

jmfbahciv@aol.com wrote:
> >do we have any indication that hardware development is more efficient
> >than software development, anyhow?  if so, one reason could be that
> >the hardware design can be chosen on pure technical merits -- no
> >business logic or similarily arbitrary customer requirements to worry
> >about.
> 
> This [rated on purely technical merits] is what is wrong with
> hardware development (and has been for years).  Not having
> the customer in mind sucks rocks.  Note that the definition
> of a customer of a CPU designer is the OS developer.
> 

I think it helps if the OS developer works for the same company
that does the CPU or is large as Microsoft.  Linux is at a disadvantage
there.  It has to make do with whatever.

Even if the OS was developed at the same company, it didn't always help
that much.  Kingston, NY (where VM was developed) was a lot further from
Poughkeepsie (where MVS was developed and the architecture group was)
than 25 miles or so.  When I did the initial implementation of TOD clock
synchronization for VM it was fairly straightforward.  For MVS it was more
of a problem since MVS had error recovery (VM had none to worry about).
MVS ended up having to vary off all the processors offline and bringing
them online one by one, synching the clocks one at a time.  MVS ended up
getting the architecture changed so that clocks were synchronised by
hardware when they were brought online. VM would never have had that
kind of clout with the architecture group to fix any problems it ran into.

As a former kernel developer and someone who still tries to use some the
specialized hardware functions, I find the big problem is hardware
architects not only don't consider anyone to be their customers, they
don't bother to explain the intent of the architecture.  Any architecture
rationales are invariably stripped from the final documentation.  Fortunately,
I've gotten rather good at architectural deconstruction.

This might partially explain the popularity of the MPI idiom.  It completely
bypasses the hassle of having to deal with the architecture.

Joe Seigh

Eugene Miya wrote:
> =

> In article <ucm4gvor5eg0qfh3e00uv5agjsbf48of6v@4ax.com>,
> Robert Myers  <rmyers@rustuck.com> wrote:
> >On 1 Jul 2003 14:34:00 -0800, eugene@cse.ucsc.edu (Eugene Miya) wrote:=


> >>>A paradigm already exists for scaling programs to arbitrarily large
> >>>sizes.  It's called a network.
> >>
> >>Huh?  What kind of network?
> >
> >I responded to the same question posed by Nick Maclaren in some detail=

> >in this thread.
> >
> >What I described is a message-passing paradigm for stitching together
> >software that is common in clusters but I don't think is used for
> >routine programming.  I also gave a reasonably clear description of
> >why I think the model is, to all appearances, indefinitely
> >extensible.
> >
> >As I said in responding to Nick, I think Jan C. Vorbr=FCggen got it
> >exactly right when he said that what is different about software is
> >that it is written in a strongly-coupled way.  A message-passing
> >paradigm is one way of strictly limiting the coupling and allowing for=

> >complete monitoring of the interactions between separate program
> >modules.
> =

> Message passing from the 60s to today is performance limited.
> This is a common criticism (e.g., call by reference vs. call by value)
> and it way COMMON blocks also got created.

That's what Cooperative Data Sharing (CDS,
http://cds-bcr.sourceforge.net) is all about: "Give me a
message-passing-like interface, but with a semantics which can translate
into either call-by-reference or call-by-value, depending on which works
best at the time" (i.e. based on the permissions required to the data by
the "sender" and "receiver", and the latency of the interconnect between
them).  Turns out if you look at the same interface from a different
angle, it looks a lot like shared memory.  That is, a shared message
queue can be considered like a lock:  If there is a reference to a
region (a.k.a. message) in the queue, then that region is available to
anyone who wants it, and if someone removes it, then it is exclusively
theirs.  A simple software-controlled copy-on-write approach in CDS
allows multiple readers in shared memory environments while still
providing consistency and low overhead in unshared.  CDS even provides
macros for an interface that looks very similar to either traditional
message passing or shared memory, even though both sets of macros
translate to the same set of communication primitives.

Also, calling "message passing" (in the sense of a copy from sender's
address space to the receiver's) "performance limited" is not entirely
accurate.  Although it has higher overhead than reference semantics, in
high-latency environments that is often outbalanced by its ability to
hide latency (i.e. by allowing the sender to forward data to its
ultimate destination before it is demanded there) and by pipelining
(i.e. transferring large blocks at one time over the link)--which is why
so many DSM architectures (hardware and software) still perform better
when programmed as message passing.  That's one reason that it's
important to reserve the judgement on implementation until the link
latency can be determined--i.e. usually long after the code is written. =

The ultimate goal of CDS (not yet completely attained) is to completely
hide the differences between processes and threads from the programmer: =

The code would look the same in either case, though the penalties for
over-reaching your logical address space would differ (i.e. bad data vs.
memory fault).  That can be a compile-time option.  This is why CDS uses
the more abstract term "CCE" (CDS Computational Entity) rather than
"thread" or "process".

> >Notice, please, that I am not proposing a message-passing paradigm for=

> >all programming.  I am proposing it as a way of coping with extremely
> >complex systems.
> =

> Packet switching.
> Data flow.
>  etc.

The meaning of "data flow" is very context dependent:  To some, it
suggests a hardware architecture, to some it is a class of programming
languages, to some it is a software engineering method, etc.  Many
interpret the term to mean "data is flowing from one place to another",
therefore implying overhead for moving the data. As a result, it seems
the term is capable of offending nearly anyone as unworkable. (As you
will recognize, Eugene, the stuff I will discuss here was an offshoot of
a so-called "Large Grain Data Flow" approach.)

As the CDS discussion above implies, data can logically "flow" from one
CCE to another without necessarily physically moving anywhere.  Still,
CDS is developed as, at best, a low-level programming solution, akin to
message passing or shared memory. However, there is also the Software
Cabling (SC) visual notation for managing programming complexity, for
many of the reasons, and using many of the mechanisms, described in this
thread.  Though SC's intrinsic communication paradigm is similar to CDS
(and, in fact, the design of CDS was motivated in part by SC), SC is
where hierarchy, transactions, etc. come in.

The basic building block of an SC is called a "chip", and is basically a
function, or subroutine written in your favorite (imperative
deterministic) language.  Surprisingly, that inherently makes it a
transaction in some sense, in that it is two-phase (i.e. locks all of
its external data resources, a.k.a. arguments, before
relinquishing/returning any when it is done), giving it atomicity and
serializability properties.  By putting restrictions on side effects and
persistent state of those "chips", each can also be considered as a pure
function--i.e. as a functional (deterministic) mapping from the initial
state of its arguments to their end state.  Then its just a matter of
connecting these chips/transactions/functions up together in a network,
to tell how the results of one may be used by another, and the
circumstances under which each can be initiated.  Without going into
those details, SC calls such a network a "board". Boards can be nested
to any hierarchy.  Through various clever tricks, they can also serve as
objects (where the chips on board serve as its methods), and or nested
transactions.  Array/record indexing, data parallelism, and dynamic
memory allocation are also supported at the board level.

It is really the CDS-like model that makes this all viable.  For
example, although chips aren't allowed to maintain internal state, they
are allowed to access external state transparently (by reference if it's
'close', by copying if not) in the CDS way, so it's not a problem, and
very portable--and the state accessed outside the chip can still be
encapsulated within a board ("object").

(So, why isn't everyone using SC?  Because it doesn't exist
yet...because it hasn't been funded yet...because, well, apparently
nobody sees the sense in making high-performance software easy to
write.  My last attempt at funding from angels said "go to the NSF", my
last attempt with the NSF was met with the following review, in part: =

"The panel's biggest confusion is concerned with the goal of this
proposal.  Simply put, it is not clear whether this is a proposal about
high performance computing or about high end software engineering, and
panelist opinions on that question diverged."  They saw it as a huge
problem that it might do both!  They finally decided to evaluate it as a
software engineering proposal, even though it was filed under an HPC
topic, then claimed that the approach was obviated by UML because UML
also uses a visual approach.  So, I'm not really sure what this thread
is all about: The NSF has already decided that UML and J2EE have already
solved your problems!)

-- Dave
-----------------------------------------------------------------
David C. DiNucci  Elepar                 Tools for portable grid,
dave@elepar.com   http://www.elepar.com  parallel, distributed, &
503-439-9431      Beaverton, OR 97006    peer-to-peer computing

On Mon, 07 Jul 2003 18:42:35 GMT, Joe Seigh <jseigh_01@xemaps.com> wrote:
>
>I think it helps if the OS developer works for the same company
>that does the CPU or is large as Microsoft.  Linux is at a disadvantage
>there.  It has to make do with whatever.

That is usually seen as an advantage :-)
I use Linux on 2 totally different CPUs - Pentium and PowerPC - and
the same source code, more or less, runs on both.

-- 
Cheers,
Stan Barr     stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)

The future was never like this!

In article <slrnbgjio3.thh.stanb45@citadel.metropolis.local>,
Stan Barr <stanb45@dial.pipex.com> wrote:
>On Mon, 07 Jul 2003 18:42:35 GMT, Joe Seigh <jseigh_01@xemaps.com> wrote:
>>
>>I think it helps if the OS developer works for the same company
>>that does the CPU or is large as Microsoft.  Linux is at a disadvantage
>>there.  It has to make do with whatever.
>
>That is usually seen as an advantage :-)
>I use Linux on 2 totally different CPUs - Pentium and PowerPC - and
>the same source code, more or less, runs on both.

It depends on your viewpoint!  But I agree - I regret not having
access to a range of systems to stress test the portability of
my code.  All Unix-like systems (including Microsoft ones) based
on power-of-two bits, twos' complement integers and IEEE-like
floating point are just SO boringly similar :-(


Regards,
Nick Maclaren.

jonah thomas <j2thomas@cavtel.net> wrote:

> Robert Myers wrote:
> 
> > Thw whole point of the code, though, is to provide answers to problems
> > where the answer isn't known, and I know from long and miserable
> > experience that the overwhelming pressure is to get the answer the
> > customer wants on the schedule the customer wants it and not to do
> > scientifically and mathematically credible work.
> 
> Like the DIA slogan.
> 
> "If you want it real bad, you can get it *real bad*."

"I want this software written in the worst way!"

"OK boss."


-- 
Walter It is difficult to get a man to understand something," wrote
Upton Sinclair, "when his salary depends upon his not understanding it."
Walter

 <jmfbahciv@aol.com> wrote:

> In article <1rd6gnq5eb.fsf@glesvat.ifi.uio.no>,
>    Kjetil Torgrim Homme <kjetilho@yksi.ifi.uio.no> wrote:
> >[Robert Myers]:
> >>
> >>   On 2 Jul 2003 09:44:45 -0800, eugene@cse.ucsc.edu (Eugene Miya) wrote:
> >>   
> >>   >I would hold with the academic (Brooks) line that the degree of
> >>   >complexity exceeds anything so far known in the physical realm.
> >>   
> >>   I've had a second look at Brooks ('No Silver Bullet'), and a third,
> >>   and a fourth, and I'm not impressed, to put it mildly.
> >>   
> >>   I could tear his article apart line by line, but my objection
> >>   comes down to this: anything you can do in software you should be
> >>   able to do in silicon and vice versa.  The division between
> >>   hardware and software exists only in Brook's mind, and the
> >>   perpetuation of this fundamental error is made possible only by
> >>   the semantic ambiguity of languages, like c, that are commonly
> >>   used to write software.
> >
> >"No Silver Bullet" doesn't concern itself with the success of hardware
> >design at all.  turning software into hardware is not one of the
> >suggested silver bullets.
> >
> >do we have any indication that hardware development is more efficient
> >than software development, anyhow?  if so, one reason could be that
> >the hardware design can be chosen on pure technical merits -- no
> >business logic or similarily arbitrary customer requirements to worry
> >about.
> 
> This [rated on purely technical merits] is what is wrong with
> hardware development (and has been for years).  Not having 
> the customer in mind sucks rocks.  Note that the definition 
> of a customer of a CPU designer is the OS developer.
> 
> /BAH
> 
> Subtract a hundred and four for e-mail.

But if you're cutting hardware for a banking application, one would have
to clarify the banking rules into silicon, which would entail all the
travils of equivalent software, except the cost would perhaps, make the
customer more likely to settle for good enough earlier.

A separate chip for every report?

-- 
Walter It is difficult to get a man to understand something," wrote
Upton Sinclair, "when his salary depends upon his not understanding it."
Walter

Robert Myers wrote:
> Just as Microsoft has no particular incentive to make it easy to avoid
> the use of Outlook Express and Internet Explorer, those who package
> and distribute Linux distributions have no particular incentive to
> make it easy to drop a third party desktop onto their distribution.

Huh? I could swear that both the KDE and Gnome desktops come with all major
Linux distributions. Hmm, hold on while I fire up the Mandrake Control Center
and ask it what desktops are available on the 3-disk Mandrake set... ah.
Enlightenment, GNOME, KDE, Windowmaker, ICEwm, BlackBox, Lesstif, qvwm, vtwm
(for the real minimalists out there, good ole' Tom's Window Manager circa
1988!)...

In the Linux world, where the software is free and distribution vendors compete
fiercely for customers, distribution vendors have no incentive to NOT include
somebody's favorite desktop. After all, if they refused to ship good ole'
Tom's Window Manager with the product, Tom might refuse to buy their
distribution, and will instead buy someone else's distribution (someone who
DOES include twm with their distribution). This is simple economics. Adding
features adds customers. If only 100 customers out of 100,000 want twm, and
the incremental cost of adding twm is 50K of disk space and a minute amount of
programmer time on a one-shot basis, with no (zero) development or licensing
costs, why not? 

-- 
Eric Lee Green  mailto:eric@badtux.org
Unix/Linux/Storage Software Engineer needs job -- 
see http://badtux.org for resume


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

"Eric Lee Green" <eric@badtux.org> wrote in message
news:3f09d2ae_6@corp.newsgroups.com...
> Peter da Silva wrote:
> > In article <3f051141_6@corp.newsgroups.com>,
> > Eric Lee Green  <eric@badtux.org> wrote:
> >> Modern SCSI tape drives use partitions to do this. Each partition can only
> >> be written beginning to end, but you can switch between them. I considered
> >> using the partitioning support for a backup program that I architected,
but
> >> DLT was very popular at the time and it was not feasible to do so.
> >
> > I imagine that forcing customers to buy a new tape drive just to use your
> > program would put you at a competitive disadvantage. :)
>
> Heh :-=). Not to mention that we used DLT for our own internal tape backups,
> and not being able to eat our own dogfood would have been a major loss :).
>
> > I've had customers reluctant to upgrade from DDS2 just because their file
> > systems had gone from megabytes to gigabytes.
>
> But how much of those gigabytes really need backed up?!
>
> A typical home system nowdays has a 40gb hard drive. For the most part, the
> stuff that people want to keep forever (as vs. don't care if it disappears
> into the ether) will fit on a single CD-RW platter.


Except for the wave and mp3 files I have digitized from old
records (78/45/33 1/3) and various kinds of audio tape.

At present that archive is 7 GB and growing fast.

I'm most concerned about the stuff that came from audio tape,
as those tapes are shedding oxide and the deck no longer functions.

Then there are pictures from the digital camera. Only a GB now,
but that will grow as well.

At this point we create multiple archives on multiple hard drives,
kept on multiple machines :-)

DVD may be a good solution, once the format wars are over.

-- 

   ...  Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net

In article <3f09d2ae_6@corp.newsgroups.com>,
Eric Lee Green  <eric@badtux.org> wrote:
> > I've had customers reluctant to upgrade from DDS2 just because their file
> > systems had gone from megabytes to gigabytes.

> But how much of those gigabytes really need backed up?!  

It's pretty hard to decide what part of a 40G SCADA database on
a 192G RAIDset you just want to throw away...

> A typical home system

That doesn't describe the customers I'm talking about.

> nowdays has a 40gb hard drive. For the most part, the
> stuff that people want to keep forever (as vs. don't care if it disappears
> into the ether) will fit on a single CD-RW platter.

I've got more personal mail than that.

-- 
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate.  All
these things will be lost in time, like chalk-paintings in the rain.   `-_-'
Time for your nap.  | Peter da Silva | Har du kramat din varg, idag?    'U`

In article <3F09AE7B.2070802@cavtel.net>,
jonah thomas  <j2thomas@cavtel.net> wrote:
> Peter da Silva wrote:
> > That's why it's so important to find the right way to factor the code, and
> > how throwing out 55,000 lines of code and keeping 5,000 can be progress.

> The trouble is, it looks like a defeat.  It can be argued that you 
> should have figured out the better way before those 55,000 lines were 
> written.

I didn't say it was easy. Just necessary.

> > Putting URL resolution in the operating system, however, has proven less
> > of a good idea. Even if the Internet is robust.

> What is an OS supposed to do, anyway?

Manage resources that may be shared between applications.

-- 
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate.  All
these things will be lost in time, like chalk-paintings in the rain.   `-_-'
Time for your nap.  | Peter da Silva | Har du kramat din varg, idag?    'U`

In article <slrnbgjio3.thh.stanb45@citadel.metropolis.local>,
Stan Barr <stanb45@dial.pipex.com> wrote:
> That is usually seen as an advantage :-)
> I use Linux on 2 totally different CPUs - Pentium and PowerPC - and
> the same source code, more or less, runs on both.

I use UNIX on Pentium, Power PC, and Alpha, and the same source code, more
or less, runs on all three.

One of the Pentium-based UNIX variants is shipped by Microsoft and runs as
a subsystem under Windows NT.

None of them are Linux.

-- 
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate.  All
these things will be lost in time, like chalk-paintings in the rain.   `-_-'
Time for your nap.  | Peter da Silva | Har du kramat din varg, idag?    'U`

Charles Richmond wrote:
> Kjetil Torgrim Homme wrote:
> 
>>[Charles Richmond]:
>>
>>>  [jmfbahciv@aol.com]:
>>>  > [Charles Richmond]:
>>>  > > [Peter da Silva]:
>>>  > > > "The only intuitive interface is the nipple"
>>>  > >
>>>  > > Would that be the "user device from heaven", as adverse to the
>>>  > > "user device from hell"???
>>>  >
>>>  > This must be a "guy thing".
>>>
>>>  Excuse me. Every baby that I know of...gained sustenance at one
>>>  time or another...through a nipple...regardless of gender. And
>>>  they all seemed satisfied.
>>
>>did you ever see a baby that didn't need to be _taught_ how to use the
>>nipple?
>>
> 
> I don't have a baby handy to test it...but the sucking response
> is supposed to be instinctive, IIRC.

My sister says that you have to put the baby where the nipple is, at 
first, but it certainly knows what to do with it. Think of it -- _how_ 
would one go about teaching a newborn to suck?

--Larry

Larry Elmore wrote:
> . Think of it -- _how_
> would one go about teaching a newborn to suck?

Heh. You don't have to teach some people how to suck. They suck naturally.
Especially the typical PHB types who seem to rise to the top of corporate
management.

(Sorry, couldn't resist :-).

-- 
Eric Lee Green  mailto:eric@badtux.org
Unix/Linux/Storage Software Engineer needs job -- 
see http://badtux.org for resume


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

In article <mroOa.1647$sY2.821@rwcrnsc51.ops.asp.att.net>, Larry Elmore wrote:

> My sister says that you have to put the baby where the nipple is, at 
> first, but it certainly knows what to do with it. Think of it -- _how_ 
> would one go about teaching a newborn to suck?

With a live demonstration of course!


-- 
Ah... you gotta love it when your ISP switches to a SPAMMING newsfeed.
Sigh...



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

<jmfbahciv@aol.com> wrote:
<Snip>
> This line number
> thing is making me throw up [barfing emoticon runs to the bathroom].
> I can't believe that anybody even thought of it.  Huff...huff...huff.
<Snip>

You mean BASIC line numbers that if you want to insert a line you may
have to renumber the entire program changing you GOT O s. Yep, that's
pretty much Franco American Spaghetti.

And having thought of it didn't immediaterly flush it down the nearest
porcelain convenience. Make that flush trice. 

-- 
Walter It is difficult to get a man to understand something," wrote
Upton Sinclair, "when his salary depends upon his not understanding it."
Walter