From: Mario Castelán Castro <marioxcc.MT@yandex.com>
Date: Tue, 26 Sep 2017 09:46:46 -0500
> "correct" means that the client (the people who required the software)
> says that the program fulfills his requirements. Sometimes you need to
> wait an infinite amount of time for obtaining client's approbation :-)
The same answer applies: If a client either provides himself or accepts
a formula in formal logic as a description of his requirements, then
yes, we can prove that a program is correct according to this concept.
If the client can not provide an *absolutely accurate* description (this
is necessarily a specification in formal logic) of what his requirements
are, then we can not assure the client that the program meets his
requirements. This is not a fault of the programmer, but of the client
for being vague about what his requirements are.
Good luck finding many clients that can provide such a set of
requirements. Most of the projects I deal with in my daytime job have
to do with clients that cannot even provide _in_formal requirements,
and depend on me and my team to do that for them.
> […] We must provide what is requested from us, in
> terms of functionality, performance and cost […]
Somebody has to take a decision between cheap software and reliable
software. Those are mutually exclusive.
The world is not black-and-white, it's an infinite set of gray shades.
If you are running a practical operation that needs to satisfy clients
and be self-sustaining, you will have to choose one of those shades.
You seem to be advocating the "reliable software" extreme, which,
according to your definitions, is unreachable in any practical project
of a large enough size. This is a kind of academic solution that does
not translate well to any software engineering practices that lead to
a delivery soon enough for clients to want to order your solutions.
IOW, I'm firmly with Óscar here.
The predominating choice is cheap software. As evidence for this claim I
note the very high frequency of bug reports including security
vulnerabilities.
I think you are misinterpreting the reasons for those bugs and
vulnerabilities. The real reasons are the tremendous complexity of
software we are required to produce nowadays, and the respectively
inadequate level of formal-proof technologies that prevent their use
in large-scale projects.
IOW, we are simply trying to solve problems that are in principle
insoluble with the current technology. So what we get are solutions
that are 90% reliable, and the rest are bugs and vulnerabilities.
I have spent already enough time addressing your misconceptions. If you
reply to this message with even more misconceptions, I will not reply
because I am unwilling to spend even more time explaining what you
should already know. It is *YOUR* task to make sure you know what you
are talking about (and you have failed so far), not mine!.
Please consider dropping your arrogant style and allow that others
come into this discussion with some level of experience and knowledge,
which should be respected as valid, instead of discarding it. If you
disregard engineering practices, then your pure science is not
interesting, at least not to those who have practical problems to
solve every day.
signature.asc