Faulty hardware found on shuttle

In article ,
says...
The advantage of a limited memory for a computer is that it forces the
programer to really sit down and work the problem on paper to simplify it
before starting to code.

Youch! In software engineering (heck, all forms of engineering), the
development cost is a strong, non-linear, function of the number of
constraints on the system. A computer that is almost too small provides
a number of constraints that make it *much* harder to build a good
system.

One of the hardest lessons learned in the past half-century of
programming, is that it is really, *really* hard to work the problem on
paper. So much so that the current flavor-of-the-month in programming
("extreme programing") flatly rejects that it is possible. The folks who
have learned to work the problem on paper (e.g., Dijkstra, who never
learned to use a word processor and eventually transended the
typewriter, composing his latter thoughts with pen and ink) are
exceeding rare.


If they hire microsoft weenies to code the next
shuttle, they'll just bloat the code up and not worry about limited
resources and that is when you start to have problems because you're not
careful with memory allocation, buffer sizes etc etc.

On the other hand, if you have a bit of margin in cpu-speed, real-time
requirements, and memory, it is valid engineering to consider not
forcing the programmers to be careful with memory allocations. Let the
machine keep track of memory usage (keyword: "garbage collection").

If you have significant margin, you often have the chance to consider
reusing some programs that already exist. Reuse can have a dramatic
effect on cost, time and reliability of a system.
--
Kevin Willoughby lid

Imagine that, a FROG ON-OFF switch, hardly the work
for test pilots. -- Mike Collins

In article , says...
If you allocate some memory and the code that deallocates it doesn't always
get executed, it means that your logic is flawed and you haven't done the due
diligence to ensure your code reflects the intentions all the time.

Or it may mean a deliberate decision that 0.000001 seconds of CPU time
is less valuable than hours spent by a programmer, followed up by hours
and hours spent by program reviewers.

Which is cheaper: a microsecond of computer time, or 24+ hours of people
time?

(Oddly enough, this is on-topic for sci.space. Misplaced priorities
aren't limited to software engineering. Spacecraft engineers sometimes
focus on launch mass or GLOW to the exclusion of other important
parameters.)
--
Kevin Willoughby lid

Imagine that, a FROG ON-OFF switch, hardly the work
for test pilots. -- Mike Collins

Kevin Willoughby wrote:
forcing the programmers to be careful with memory allocations. Let the
machine keep track of memory usage (keyword: "garbage collection").

My immediate reaction to that is sloppy programming where the programmer HOPES
the "system" (or more precisely, the run time library) will fix the stuff the
programmer forgot to do.

If you allocate some memory and the code that deallocates it doesn't always
get executed, it means that your logic is flawed and you haven't done the due
diligence to ensure your code reflects the intentions all the time.

Marvin wrote:
The ideal is to have *just enough* computer to comfortably do the job,
without tempting to excess growth. Unfortunately witht he tempo of computer
growth nowadays, matching this balance is a bit tough.

Or worded a different way: justify the computer resources you really need. If
you do this justification in front of peers, it motivates you to remove bloat
that you know your peers will tell you is not necessary.

Kevin Willoughby wrote in
:

Youch! In software engineering (heck, all forms of engineering), the
development cost is a strong, non-linear, function of the number of
constraints on the system. A computer that is almost too small
provides a number of constraints that make it *much* harder to build a
good system.

Quite correct, bit a somewhat myopic view of a real-life problem.
Having a computer that is more than ample in abilities virtually forces the
developers (via management's imperative not to 'waste') to utilise it to
capacity, even when it is not really needed. This causes code and
especially data bloat, which leads to exponential increase in cost of
quality control.

The ideal is to have *just enough* computer to comfortably do the job,
without tempting to excess growth. Unfortunately witht he tempo of computer
growth nowadays, matching this balance is a bit tough.

In article , says...
Kevin Willoughby wrote in
:
Which is cheaper: a microsecond of computer time, or 24+ hours of
people time?
Get a clue!
Sloppy memory management relates not only to processing time, but also to
system stability! You are thinking like microsoft.

No need for insults.


Pity your remarks place you in the "sloppy" category.

I tried, now I give up:
-*ploink*-
--
Kevin Willoughby lid

Imagine that, a FROG ON-OFF switch, hardly the work
for test pilots. -- Mike Collins

Kevin Willoughby wrote in
:

In article , says...
If you allocate some memory and the code that deallocates it doesn't
always get executed, it means that your logic is flawed and you
haven't done the due diligence to ensure your code reflects the
intentions all the time.

Or it may mean a deliberate decision that 0.000001 seconds of CPU time
is less valuable than hours spent by a programmer, followed up by
hours and hours spent by program reviewers.

Which is cheaper: a microsecond of computer time, or 24+ hours of
people time?

(Oddly enough, this is on-topic for sci.space. Misplaced priorities
aren't limited to software engineering. Spacecraft engineers sometimes
focus on launch mass or GLOW to the exclusion of other important
parameters.)

Get a clue!
Sloppy memory management relates not only to processing time, but also to
system stability! You are thinking like microsoft.

As to your remark :
Which is cheaper: a microsecond of computer time, or 24+ hours of
people time?
The microsecond, when it is in a piece of code that is executed thousands
of times per hour, on millions of computers running that code.

Accurate coding only requires more time than sloppy coding when the
programmer's skill is not sufficient to the task. For a fully competent
coder, accurate code is *easier* to create and debug than sloppy code!
Pity your remarks place you in the "sloppy" category.

Kevin Willoughby wrote:

On the other hand, if you have a bit of margin in cpu-speed, real-time
requirements, and memory, it is valid engineering to consider not
forcing the programmers to be careful with memory allocations. Let the
machine keep track of memory usage (keyword: "garbage collection").

Of course to use that margin, you have to ensure not only that the
garbage collector is called, but that it actually functions as
intended and is itself bug free.

D.
--
Touch-twice life. Eat. Drink. Laugh.

"Derek Lyons" wrote in message
...
Kevin Willoughby wrote:

On the other hand, if you have a bit of margin in cpu-speed, real-time
requirements, and memory, it is valid engineering to consider not
forcing the programmers to be careful with memory allocations. Let the
machine keep track of memory usage (keyword: "garbage collection").

Of course to use that margin, you have to ensure not only that the
garbage collector is called, but that it actually functions as
intended and is itself bug free.

Of course, you also need to trust your compiler's deallocation routine. I
remember that at one time Turbo Pascal essentially ignored deallocation.

Course, you could then explicitly manage all your allocations in your own
code. (Which is much more efficient for things like OS code.)