Software bugs aren't inevitable
rrr at ronadam.com
Fri Sep 16 17:59:51 CEST 2005
Paul Rubin wrote:
> Steven D'Aprano <steve at REMOVETHIScyber.com.au> writes:
>>But there is a difference: writing assembly is *hard*, which is why we
>>prefer not to do it. Are you suggesting that functional programming is
>>significantly easier to do than declarative?
> I think you mean imperative. Yes, there is a community that believes
> that writing bug-free programs in functional style is easier than
> writing them in imperative style. Writing buggy programs might be
> easier in imperative style, but in some application areas, that's not
> good enough.
> Why don't you read the Hughes paper I cited instead of taking cheap
> shots at it without reading it, if you want to understand the issues
Just some comments from my own experiences concerning bugs and writing
dependable software. It pretty much depends on a number of things and
isn't just a matter of good design or what language is used.
* The dependability of the hardware
* The dependability of the OS
* The stability of the language used
* The programmers knowledge of the language used
* Program design
* How many programmers are working on the same project
* How many extensions are used and written by other people
* The stability of those extensions
* Rate of change of the program design, and all underlying parts.
A small program with no external modules and written by a single person
can be fairly dependable, or as dependable as the underlying language,
OS, and hardware.
But as soon as the softwares complexity increases and/or multiple
programmers are used, either directly or indirectly through third party
extensions, then the probability of bugs increases substantially.
Given *enough* time, effort, and testing, without changing the design,
even a large program can be nearly as dependable as the least dependable
part of the platform it is running on. ("enough" could be a long time
To increase reliability to nearly 100%, you need to run different
versions of a program on several different platforms simultaneously and
use only the results that have a majority agreement.
Or to put it another way; risk management by ... "keep it simple",
"don't have too many cooks", "get second opinions", and "don't put all
your eggs in one basket".
More information about the Python-list