软件错误并非不可避免 [英] Software bugs aren't inevitable
问题描述
一位工作同事散发了这篇有趣的文章，关于减少数量级的软件错误：
http://www.spectrum.ieee.org/WEBONLY...5/0905ext.html
他们谈论的一些方法包括从基于ADA的语言Sparc中删除容易出错且含糊不清的
表达式 - 他们给出的示例
是关于他们删除的原因增量运算符x ++，x--。
一些谷歌搜索显示他们在过去提到过的
工作规范中的Python，但仅限于很多语言中的一种。
我想知道Praxis对Python的看法，以及如果Praxis工程师对Python进行批评，它会有多好生成低错误数软件的流程的一部分。
在这个侧栏中的主要文章：
< a rel =nofollowhref =http：// www.spectrum.ieee.org/WEBONLY/publicfeature/sep05/0905extsb1.html\"target =_ blank> http://www.spectrum.ieee.org/WEBONLY...905extsb1.html
似乎他们使用Z符号模型中的一个等式并添加
作为对其主要编程语言函数定义的注释
作为评论，然后有一个方法来自动测试评论
对功能体。
这就像doctest如何检查测试和预期结果
在文档字符串中给出了函数中给出的实现;
确实我在工作中写了这样一个例子并在
$中传播它b $ b居民perl贩子。 - Gosh它非常好:-)
所以，我如何从Praxis获得反馈，他们已经阅读了
comp.lang.py?
干杯，帕迪。
" Paddy" < PA ******* @ netscape.net>写道：一位工作同事散发了这篇有趣的文章，关于减少数量级的软件错误：
http://www.spectrum.ieee.org/WEBONLY...5/0905ext.html
这会得到一个未找到的错误。有一个不同的链接？
他们谈论的一些方法包括从基于ADA的语言Sparc中删除容易出错和含糊不清的表达式 - 他们给出的例子是关于为什么他们删除了增量运算符x ++，x--。
John Hughes的一篇着名论文称为为什么功能性很好/
编程问题。 （廉价的过度简化）说你应该
从不修改任何变量的值。因此，没有增量，甚至没有增加循环（使用递归代替）。
2005年9月14日星期三01:05:55 - 0700，Paul Rubin写道：
约翰·休斯（John Hughes）的一篇着名论文称为什么功能性的编程很重要。 （廉价过度简化）说你应该永远不会修改任何变量的值。因此，没有增量，甚至没有循环（使用递归代替）。
作为一个学术练习非常有用，但是不会起作用
在现实世界中表现非常出色，其中迭代和递归之间的性能和资源需求差异可能很大。
例如，在Fibonacci序列中尝试第n个数字
的这两个简单函数：
def fibr（n）：
Fibonacci序列的递归版本。
如果n == 0：返回0
elif n == 1：返回1
else：return fibr（n-1）+ fibr（n-2）
def fibi（n）：
" ; Fibonacci序列的简单迭代版本。
如果n == 0：返回0
elif n == 1：返回1
否则：
Fn2 = 0
Fn1 = 1
为_范围内（2，n + 1）：
s = Fn2 + Fn1
Fn2，Fn1 = Fn1，s
返回s
尝试使用这两种算法计算生成第30个Fibonacci数的时间长度
（832040）。现在尝试第50次。 （警告：递归版本完成的
工作量与斐波那契序列本身增加的速度相同。
斐波那契序列本身增加。这不是指数级的，
但速度非常快，非常痛苦。）
-
史蒂文。
< blockquote> Steven D''Aprano建议迭代迭代：
例如，在Fibonacci序列中尝试第n个数字的这两个简单函数：
def fibr（n）：
Fibonacci序列的递归版本。
如果n == 0：返回0
elif n == 1：return 1
else：return fibr（n-1）+ fibr（n-2）
def fibi（n）：
Fibonacci序列的简单迭代版本。
如果n == 0：返回0
等尝试计算使用这两种算法生成第30个斐波纳契数（
）（832040）需要多长时间。现在尝试第50次。 （警告：递归版本完成的工作量与斐波那契序列本身增加的速度相同。这不是指数级的，但它足够快非常痛苦。）
首先，Fibonacci递归版的复杂性是指数，
不要说这么不太真实作为不完全。但是，更重要的是：
如果你不太了解函数式编程的方式现在使用的是
，请不要给予荒谬的例子，因为
NOBODY认真编程你的递归版本的风格。
这种递归的反广告说减去递归
比你自己。这里你是n的线性递归版本;它
返回序列中最后两个Fibonacci数字
def fibo（n）：
如果n< 2：
返回（n-1，n）
else：
（a，b）= fibo（n-1）
返回（b，a + b）
指数复杂，级联版本是一个很好的测试用例如何使用memoization来支持
，所以学习它并非完全没有意义。
Jerzy Karczmarczuk
A work colleague circulated this interesting article about reducing
software bugs by orders of magnitude:
http://www.spectrum.ieee.org/WEBONLY...5/0905ext.html
Some methods they talk about include removing error prone and ambiguous
expressions from their ADA based language Sparc - The example they give
is on why they removed the increment operators x++, x-- .
A bit of googling shows that they have, in the past mentioned Python in
Job specs, but only as one of many languages.
I was wondering what Praxis thought of Python, and how good it would be
if a Praxis engineer gave a critique of Python as a part of a flow for
producing low bug-count software.
In this sidebar to the main article:
http://www.spectrum.ieee.org/WEBONLY...905extsb1.html
It seems that they use one equation from the Z notation model and add
it as a comment to their main programming languages function definition
as a comment, then have a means of automatically testing the comment
against the function body.
This is rather like how doctest can check the test and expected result
given in a doc-string against the implementation given in the function;
indeed I wrote up such an example at work and circulated it amongst the
resident perl mongers. - Gosh it fealt good :-)
So, How do I get feedback from Praxis, Do they already read
comp.lang.py?
Cheers, Paddy.
"Paddy" <pa*******@netscape.net> writes:A work colleague circulated this interesting article about reducing
software bugs by orders of magnitude:
http://www.spectrum.ieee.org/WEBONLY...5/0905ext.html
This gets a not found error. Got a different link?
Some methods they talk about include removing error prone and ambiguous
expressions from their ADA based language Sparc - The example they give
is on why they removed the increment operators x++, x-- .
There''s a famous paper by John Hughes called "Why Functional
Programming Matters" that (cheap oversimplification) says you should
never modify the value of any variable. So, no increments, not even
for loops (use recursion instead).
On Wed, 14 Sep 2005 01:05:55 -0700, Paul Rubin wrote:
There''s a famous paper by John Hughes called "Why Functional
Programming Matters" that (cheap oversimplification) says you should
never modify the value of any variable. So, no increments, not even
for loops (use recursion instead).
Which works wonderfully as an academic exercise, but doesn''t tend to work
so terribly well in the real world where the performance and
resource-requirement differences between iteration and recursion can be
significant.
For instance, try these two simple functions for the nth number
in the Fibonacci sequence:
def fibr(n):
"Recursive version of Fibonacci sequence."
if n == 0: return 0
elif n == 1: return 1
else: return fibr(n-1) + fibr(n-2)
def fibi(n):
"Simple iterative version of Fibonacci sequence."
if n == 0: return 0
elif n == 1: return 1
else:
Fn2 = 0
Fn1 = 1
for _ in range(2, n+1):
s = Fn2 + Fn1
Fn2, Fn1 = Fn1, s
return s
Try timing how long it takes to generate the 30th Fibonacci number
(832040) using both of those algorithms. Now try the 50th. (Warning: the
amount of work done by the recursive version increases at the same rate as
the Fibonacci sequence itself increases. That''s not quite exponentially,
but it is fast enough to be very painful.)
--
Steven.
Steven D''Aprano recommends iteration over recursion:For instance, try these two simple functions for the nth number
in the Fibonacci sequence:
def fibr(n):
"Recursive version of Fibonacci sequence."
if n == 0: return 0
elif n == 1: return 1
else: return fibr(n-1) + fibr(n-2)
def fibi(n):
"Simple iterative version of Fibonacci sequence."
if n == 0: return 0
etc. Try timing how long it takes to generate the 30th Fibonacci number
(832040) using both of those algorithms. Now try the 50th. (Warning: the
amount of work done by the recursive version increases at the same rate as
the Fibonacci sequence itself increases. That''s not quite exponentially,
but it is fast enough to be very painful.)
First of all, the recursive version of Fibonacci IS EXPONENTIAL in complexity,
don''t say such not-quite-truth as "not quite". But, what is more important:
If you don''t know too much about the way the functional programming is
used nowadays, please refrain from giving nonsensical examples, since
NOBODY serious programs something in the style of your recursive version.
Such anti-advertizing of recursion says less about the recursion
than about yourself. Here you are a recursive version linear in n; it
returns the two last Fibonacci numbers of the sequence
def fibo(n):
if n<2:
return (n-1,n)
else:
(a,b)=fibo(n-1)
return (b,a+b)
The exponential complexity, cascading version is a nice test case how to
use memoization, though, so it is not entirely senseless to learn it.
Jerzy Karczmarczuk
这篇关于软件错误并非不可避免的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
