Microsoft abandons the C language

[Les Cargill]

Le 03/09/12 00:01, Stephen Sprunk a écrit :

This is an unwarranted insult to NASA people, that have to be able to
survive and do outstanding work in an ever decreasing budget.

A declining budget is Nature's way of telling you to work somewhere
else.

The
systems on Mars, for instance, have reliably worked since years:
Opportunity rover is running its real time OS since 8 years already, and
the twin rover Spirit, had a few startup problems but worked flawlessly
for many years after that initial problem.

NASA CAN'T replicate everything since every gram sent to Mars or to
Jupiter costs a fortune. You can't send several computers, several
backup systems, etc. You are constrained by the laws of gravity.

The problem with NASA is the PR end of it. That's Tom Wolfe's thesis
from "The Right Stuff" and it's still true. Because NASA's mission has
been made mythic, the failures resonate as mythic, too.

Hopefully, the good people there know that going in, or figure it out.

 

[Ian Collins]

A declining budget is Nature's way of telling you to work somewhere
else.
Mars?

Your sig is missing the trailing space after the "--".

 

[Les Cargill]

Mars?

Yep. Mars.

Your sig is missing the trailing space after the "--".

Ah - thanks.

 

[James Kuyper]

jacob navia wrote: ....

A declining budget is Nature's way of telling you to work somewhere
else.

Sending sensors into space to look back at Earth should continue to be
well-funded, even if budgets decline for those looking outward.

 

[Stephen Sprunk]

Le 03/09/12 00:01, Stephen Sprunk a écrit :

This is an unwarranted insult to NASA people,

It is not an insult at all, much less an unwarranted one.

It is a recognition that NASA's mission is unique, so perhaps their
methodology isn't automatically the best choice for everyone else.

S

 

[Stephen Sprunk]

For some value of "recover". If a server reboot is your idea of a
gracefull recovery, I recommend that you start using SCO Openserver as
deployment platform

Or Windows

But that bittterness aside, I think that we disagree about the
definition of recovery, rather than the tradeoff between effort and
return.

For the purposes of this discussion so far, I would say that if
restarting the application brings it back to a normal operational state,
that constitutes recovery. And, if such recovery is possible, then by
definition the error was not "unrecoverable".

Regarding the acceptability (or inevitability) of crashes, there is
nothing about restarting the application that proper error-handling code
within the application could not have done itself. Since there was no
need to crash in the first place, the crash is not acceptable.

I do recognize that there are "legitimate" reasons for an application to
crash, eg. bad hardware, OS problems, gamma rays, crashing into the
surface of Mars, etc. Let's not go making excuses for preventable
crashes just because we're too lazy to do our jobs right.

S

 

[Keith Thompson]

For the purposes of this discussion so far, I would say that if
restarting the application brings it back to a normal operational state,
that constitutes recovery. And, if such recovery is possible, then by
definition the error was not "unrecoverable".

Regarding the acceptability (or inevitability) of crashes, there is
nothing about restarting the application that proper error-handling code
within the application could not have done itself. Since there was no
need to crash in the first place, the crash is not acceptable.

I do recognize that there are "legitimate" reasons for an application to
crash, eg. bad hardware, OS problems, gamma rays, crashing into the
surface of Mars, etc. Let's not go making excuses for preventable
crashes just because we're too lazy to do our jobs right.

Suppose the crashes cost you X person-hours over the lifetime
of the application, and fixing it will cost you Y person-hours.
(Or express the costs in terms of money if you prefer.) If Y > X,
does leaving the bug in place still constitute being "too lazy to
do our jobs right"?

Note that just determining the value of Y might itself cost Z
person-hours; in some cases, Z==Y, or nearly so.

 

[Paul J Gans]

Suppose the crashes cost you X person-hours over the lifetime
of the application, and fixing it will cost you Y person-hours.
(Or express the costs in terms of money if you prefer.) If Y > X,
does leaving the bug in place still constitute being "too lazy to
do our jobs right"?

Note that just determining the value of Y might itself cost Z
person-hours; in some cases, Z==Y, or nearly so.

But one has to include the side effects of the crashes in X
as well. If a crash brings down a system resulting in the
loss of several million dollars of business...

 

[Stephen Sprunk]

I think scrapping a prototype is both easier and cheaper, but it
apparently offends people's sensibilities.

What's a prototype? Do you mean the code that Marketing/Sales shipped
as version 1.0 before you figured out that it would never work? And
that management is now insisting you fix--and add features to--rather
than start over from scratch?

Yes, it is. Although I was ( erroneously ) thinking "reliability"
not in the redundant or hot-backup sense - more in the "don't crash"
sense.

Well, your primary focus moves from the reliability of the entire system
rather than of individual components, but you still want the individual
components to be reliable as well.

*Some* NASA stuff uses "voting" type redundancy, as do other aviation
electronics.

I've read that NASA uses three-way voting between two systems from
vendor A and one system from vendor B. That's great for handling
hardware faults or a bug in vendor B's software, but a bug in vendor A's
software can outvote vendor B's correct software.

Then again, the US political system has soured me on voting in general.

nobody has a knife that sharp

The precision probably exceeds the accuracy, but our accountants at
least _think_ their knives are that sharp.

S

 

[Keith Thompson]

But one has to include the side effects of the crashes in X
as well. If a crash brings down a system resulting in the
loss of several million dollars of business...

Of course. That's implicit in how I defined X (which can be defined
either as person-hours or as money).

 

[Nick Keighley]

Le 02/09/12 13:05, Anse a écrit :







The strategy of this troll is always the same: Just hang a "profound"
looking sentence into some posts at random. Obviously there isn't any
discussion or hint of any, it is just always the same pattern.

He has been trolling in the C++ group too, always with the same tactic.

He has no knowledge of anything technical or about software or anything
like that, it is just somebody that loves to start insulting people at
random and the anonymity of usenet allows to do it with easy.

Look at this for instance:

"I was trying to help the flailing duck and you call me a hunter?"
"Aren't you the one who shot him to begin with?"

Etc. Meaningless sentences juxtaposed so that they seem to be
articulated when in fact they aren't.

poorly written bot maybe?

 

[Nick Keighley]

What theorpy did you have? And what about the strippers? Did you shack up
with one? 5 times a year only? No way! I call bullshit.

oh, this is well over-due

PLONK.

 

[BartC]

But one has to include the side effects of the crashes in X
as well. If a crash brings down a system resulting in the
loss of several million dollars of business...

There is a difference in the costs of the software developer, and any
consequential losses of any single customer out of thousands. The developer
won't care to spend a definite $1000 to save a possible $1000000 of a
customer.

It might make more sense to just give a refund to that one customer,
although that would be a dangerous precedent, so any liabilities (or lack
of) of the software ought to be carefully spelled out in the licence
agreement.

Of course if many customers are getting irate at such problems, then the
developer should do something about them. But it needs to make financial
sense for the developer not the customer.

 

[Rui Maciel]

Is this some variant of Tourette's syndrome - you post these outbursts
and we should just ignore them?

No, it's just a troll that created an account dedicated to flood comp.lang.c
with noise.

https://groups.google.com/groups/profile?hl=pt-
PT&enc_user=eoOl9iEAAACyiQ5aqNhaHUuu7grpJzQFIkg6arSY_QO9EjaByWboSZHRGrMdZImE0Gr1e5nVtd0


Rui Maciel

 

[Rui Maciel]

The economics of defects seems to be incredibly poorly understood.

Considering the number of people who profit from this, along with how much
profit can be made from defective software, maybe it's actually understood
very well.


Rui Maciel

 

[Rui Maciel]

The original context was unrecoverable resource contentions, not
programming bugs.

If you take the time to browse this thread down to its root, you will notice
that this particular branch of the thread started when VLAs were mentioned,
particularly why their use is frowned upon by some programmers.

If you get to that part, you will notice that "Don't make my brown eyes
China Blue" criticised and poke fun at those who took care of making sure
that the call stack wasn't overflowed, to which he insinuated that it was an
issue which only mattered in 1966, and then proceeded to refer to how he
solved this type of issue by restarting the process.

I believe we can agree that bursting the stack is not a mere resource
contention issue, and that it is a serious programming bug.


Rui Maciel

 

[Rui Maciel]

Restarting a process certainly does fix whatever problems were
caused by the process not running, because now it's running again,
and presumably doing useful work.

If the process crashed due to fundamental problems of how the software was
written, which includes adding vulnerabilities such as a propencity to
overflow the call stack, then I believe that we can agree that restarting
the process does nothing to fix this sort of problem.


Rui Maciel

 

[Rui Maciel]

Suppose the crashes cost you X person-hours over the lifetime
of the application, and fixing it will cost you Y person-hours.
(Or express the costs in terms of money if you prefer.) If Y > X,
does leaving the bug in place still constitute being "too lazy to
do our jobs right"?

If the person responsible for punching in the code intentionally disregards
fundamental coding practices that are covered in every programming 101
course, claiming that somehow they only mattered in the 1960s, and then
proceeds to mitigate the problems caused by that level of incompetence by
claiming that restarting the process is an adequate fix, then I believe we
can agree that it easily fits the "too lazy to do our jobs right" category.

There may be software bugs whose fix presents a cost/benefit ratio that is
too high to justify fixing them, but that doesn't mean that a programmer
should be free to intentionally implement disastrous coding practices and
criticise those who actually try to avoid making that sort of mistake.


Rui Maciel

 

[Rui Maciel]

I hve never had an abort due to a variable length array on the stack. My
stack aborts are from endless recursion.

So, after boasting about your vast experience in having "learned programming
using Fortran 77, Pascal, and Algol 61 on CDC 3300s and Cyber 170s" and how
you "learned a great deal about allocating loc variables with limitted
space", and then proceeding to make sarcastic comments such as "I realise
that VM, like recursion and stack allocation are radical concepts that have
been around for a mere 50 years, but I have coped with these", you then go
on to admit that you actually are oblivious to how a call stack works and
are incapable of putting the legwork to avoid making that rookie mistake?


Rui Maciel

 

[Les Cargill]

Considering the number of people who profit from this, along with how much
profit can be made from defective software, maybe it's actually understood
very well.


Rui Maciel

And then there's that....