Re: Software bugs aren't inevitable

Giles Brown wrote: > Michael Sparks wrote: >> The problem that these sorts of approaches don't address is the simple >> fact that simple creating a formal spec and implementing it, even if >> you manage to create a way of automating the test suite from the spec >> *doesn't guarantee that it will do

Re: Software bugs aren't inevitable

On Saturday 17 September 2005 06:03 pm, Scott David Daniels wrote: > Sybren Stuvel wrote: > > ... Computers aren't happy. They couldn't care less about the > > programming language. > > This reminds me of a quote I love (and wish I could cite the > originator): > > Don't anthropomorphize com

Re: Software bugs aren't inevitable

Sybren Stuvel wrote: > ... Computers aren't happy. They couldn't care less about the > programming language. This reminds me of a quote I love (and wish I could cite the originator): Don't anthropomorphize computers, they don't like that. --Scott David Daniels [EMAIL PROTECTED] -- http://m

Re: Software bugs aren't inevitable

"Aahz" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Note that I said "one reason". The primary reason is that tail-call > optimization destroys the call stack, which means that exception > semantics would have to change. If tail-call optimization were more > useful, he might be

Re: Software bugs aren't inevitable

In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] (Aahz) writes: >> In article <[EMAIL PROTECTED]>, >> Paul Rubin wrote: >>> >>>Every serious FP language implementation optimizes tail calls and thus >>>using recursion instead of it

Re: Software bugs aren't inevitable

phil hunt enlightened us with: > If a program is too slow to respond isn't that about "system time"? Not by definition. Could be anything. If it's slow to respond due to a slow harddisk, then you're right. If it's slow to respond due to not putting the I/O and the GUI main loop in different thread

Re: Software bugs aren't inevitable

On Fri, 16 Sep 2005 20:05:04 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] (phil hunt) writes: >> Compilers/interpreters/runtimes are black boxes: we don't (or >> shouldn't) care how they do their work as long as they run correctly >> and aren't too heavy on system resources like

Re: Software bugs aren't inevitable

[EMAIL PROTECTED] (phil hunt) writes: > Compilers/interpreters/runtimes are black boxes: we don't (or > shouldn't) care how they do their work as long as they run correctly > and aren't too heavy on system resources like CPU time and memory. Maybe in academia. Not in the real world. Or maybe you

Re: Software bugs aren't inevitable

The article states that their method calls for them to have much more than normal access to many more people in the clients organisation than is normal; from the CEO to the receptionist. The specification stage can take a year without the customer seeing a line of code. And they deliberately "write

Re: Software bugs aren't inevitable

On Fri, 16 Sep 2005 20:36:02 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >On Thu, 15 Sep 2005 18:07:28 +0100, phil hunt wrote: > >> On Thu, 15 Sep 2005 21:56:06 +1000, Steven D'Aprano <[EMAIL PROTECTED]> >> wrote: >>> >>>Are you saying that the recursion done by "serious" languages is a fake

Re: Software bugs aren't inevitable

Terry Reedy wrote: > You cannot tell whether a function object will act > recursive or not just by looking at its code body. Trivial examples: I was thinking last night that maybe it would be useful to be able to define a function explicitly as a recursive object where it's frame is reused on

Re: Software bugs aren't inevitable

Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> 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. Y

Re: Software bugs aren't inevitable

On Friday 16 September 2005 09:41 am, Terry Hancock wrote: > > (Terry Hancock formulated this plainly, he prefers dumb ways because > > he wants to solve problems, and he doesn't like to perform gymnastics > > with his brain. We have to accept those attitudes. But I believe that > > this is the eff

Re: Software bugs aren't inevitable

On Friday 16 September 2005 08:35 am, Michael Sparks wrote: > Steven D'Aprano wrote: > > 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? > > But there

Re: Software bugs aren't inevitable

Terry Hancock enlightened us with: > This is ludicrous sophistry. The technical reason for having ANY high > level languages is "psychological". Computers are happier with binary > code, over ANY language that must be interpreted. Computers aren't happy. They couldn't care less about the programm

Re: Software bugs aren't inevitable

On Thursday 15 September 2005 04:38 am, Jerzy Karczmarczuk wrote: > is for me a biased view of the problem. Justified only by the fact that > at the beginning of functional programming (sixties) nobody cared about > the efficiency. Now, such languages as Clean, or good implementations of > Scheme a

Re: Software bugs aren't inevitable

Michael Sparks wrote: > The problem that these sorts of approaches don't address is the simple > fact that simple creating a formal spec and implementing it, even if > you manage to create a way of automating the test suite from the spec > *doesn't guarantee that it will do the right thing*. > As

Re: Software bugs aren't inevitable

Steven D'Aprano wrote: > On Thu, 15 Sep 2005 18:07:28 +0100, phil hunt wrote: >> On Thu, 15 Sep 2005 21:56:06 +1000, Steven D'Aprano >> <[EMAIL PROTECTED]> wrote: >>> >>>Are you saying that the recursion done by "serious" languages is a fake? >>>That it is actually implemented behind the scenes by

Re: Software bugs aren't inevitable

Steven D'Aprano <[EMAIL PROTECTED]> 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

Re: Software bugs aren't inevitable

Paddy wrote: > A work colleague circulated this interesting article about reducing > software bugs by orders of magnitude: The problem that these sorts of approaches don't address is the simple fact that simple creating a formal spec and implementing it, even if you manage to create a way of auto

Re: Software bugs aren't inevitable

On Thu, 15 Sep 2005 18:07:28 +0100, phil hunt wrote: > On Thu, 15 Sep 2005 21:56:06 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >> >>Are you saying that the recursion done by "serious" languages is a fake? >>That it is actually implemented behind the scenes by iteration? >> >>It seems to me

Re: Software bugs aren't inevitable

Terry Reedy cites: > "Mike Meyer" who fights with: >>>While that's true, one of the reasons Guido has historically rejected >>>this optimization is because there are plenty of recursive algorithms >>>not amenable to tail-call optimization. >>Since the BDFL is *not* known for doing even mildly sill

Re: Software bugs aren't inevitable

"Mike Meyer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [EMAIL PROTECTED] (Aahz) writes: >> While that's true, one of the reasons Guido has historically rejected >> this optimization is because there are plenty of recursive algorithms >> not amenable to tail-call optimization.

Re: Software bugs aren't inevitable

François Pinard <[EMAIL PROTECTED]> writes: > This being said, for one, I always found _insane_ presenting recursion > to new programmers using such examples, which are both very easily, > and much better written non-recursively. It does not help beginners > at taking recursion any seriously. I d

Re: Software bugs aren't inevitable

François Pinard <[EMAIL PROTECTED]> writes: > This being said, for one, I always found _insane_ presenting recursion > to new programmers using such examples, which are both very easily, > and much better written non-recursively. It does not help beginners > at taking recursion any seriously. Thi

Re: Software bugs aren't inevitable

[Jerzy Karczmarczuk] > 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: re

Re: Software bugs aren't inevitable

[EMAIL PROTECTED] (Aahz) writes: > In article <[EMAIL PROTECTED]>, > Paul Rubin wrote: >>Every serious FP language implementation optimizes tail calls and thus >>using recursion instead of iteration doesn't cost any stack space and >>it probably generates the exact same

Re: Software bugs aren't inevitable

In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > >Every serious FP language implementation optimizes tail calls and thus >using recursion instead of iteration doesn't cost any stack space and >it probably generates the exact same machine code. While that's true, one

Re: Software bugs aren't inevitable

On Thu, 15 Sep 2005 11:38:57 +0200, Jerzy Karczmarczuk wrote: >> Yes, the maximum recursion depth in Python is an artificial limit. But >> that artificial limit is built into Python specifically to protect you >> from running into a real recursion limit based on the hardware and >> architecture of

Re: Software bugs aren't inevitable

On Wed, 14 Sep 2005 23:44:18 -0400, Terry Reedy wrote: >> Yes. There are lots of algorithms that could be done, and they all have >> their pros and cons. Biset's formula, for example, is mathematically >> correct, but for large enough n, the "mere implementation detail" that >> floats have a finit

Re: Software bugs aren't inevitable

"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Are you saying that the recursion done by "serious" languages is a fake? > That it is actually implemented behind the scenes by iteration? Although easy to confuse, we should separate expressive syntax, whether recu

Re: Software bugs aren't inevitable

On Thu, 15 Sep 2005 21:56:06 +1000, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > >Are you saying that the recursion done by "serious" languages is a fake? >That it is actually implemented behind the scenes by iteration? > >It seems to me that if recursion and iteration produce "the exact same >mach

Re: Oh Yes, They Are [was: Re: Software bugs aren't inevitable]

Surely, (don't call me Shirley), one of the goals pf Python is to make the Programmer more productive. It is obvious that we can tolerate some bugs in programs, but, after reading the article, I thought that we might have a change to here from 'the other side'. I get the fealing that the proponents

Re: Software bugs aren't inevitable

Steven D'Aprano wrote: > On Wed, 14 Sep 2005 12:23:00 -0700, Paul Rubin wrote: >>Every serious FP language implementation optimizes tail calls and thus >>using recursion instead of iteration doesn't cost any stack space and >>it probably generates the exact same machine code. > > > Are you sayin

Re: Software bugs aren't inevitable

Hi! 2005/9/15, Jerzy Karczmarczuk <[EMAIL PROTECTED]>: [snip] > But, I have used myself the cascading version. It was done on purpose, in > order to get to the following solution. > [[I preferred to use a global dict, but other ways of doing it are also > possible]]. > > fibdic={0:0,1:1} > def

Oh Yes, They Are [was: Re: Software bugs aren't inevitable]

Paddy wrote: > A work colleague circulated this interesting article about reducing > software bugs by orders of magnitude: > http://www.spectrum.ieee.org/WEBONLY/publicfeature/sep05/0905ext.html > > Some methods they talk about include removing error prone and ambiguous > expressions from their

Re: Software bugs aren't inevitable

On Wed, 14 Sep 2005 12:23:00 -0700, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> It is a "mere implementation detail" that (for most computer systems, and >> most programming languages) stack space is at a premium and a deeply >> recursive function can run out of stack space

Re: Software bugs aren't inevitable

Steven D'Aprano is still unhappy with the linear complexity recursive Fibonacci I proposed as as an alternative to the cascading recursion which for some people is "standard" or "obvious" or other similar attribution which is not valid anymore. > RuntimeError: maximum recursion depth exceeded >

Re: Software bugs aren't inevitable

"Paddy" <[EMAIL PROTECTED]> writes: > As I write, the main article starts here: > http://www.spectrum.ieee.org/sep05/2164 > With the sidebar here: > http://www.spectrum.ieee.org/sep05/2164/extsb1 Thanks, the article is slightly interesting but it doesn't say much. I'm sure a lot more is going

Re: Software bugs aren't inevitable

"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Wed, 14 Sep 2005 14:32:17 +0200, Jerzy Karczmarczuk wrote: >> Here you are a recursive version linear in n; it >> returns the two last Fibonacci numbers of the sequence The minor problem is that for n = 0, there a

Re: Software bugs aren't inevitable

"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Wed, 14 Sep 2005 11:28:02 -0400, Terry Reedy wrote: > But in the context of my response, I was replying to a paraphrased quote > from somebody who apparently believes that recursion is *always* better > than itera

Re: Software bugs aren't inevitable

"Rocco Moretti" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > The algorithm one uses sometimes depends quite heavily on which mindset > you're using. Some algorithms require much more mental effort to > understand when in their recursive form versus the iterative form, and > vice

Re: Software bugs aren't inevitable

On Wednesday 14 September 2005 02:23 pm, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: > > It is a "mere implementation detail" that (for most computer systems, and > > most programming languages) stack space is at a premium and a deeply > > recursive function can run out of stack

Re: Software bugs aren't inevitable

Thanks Giles, I was hoping for a reply from someone close to Praxis like yourself, but, I'm shocked when you said they use Perl as their scripting language of choice, because I thought that with such an emphasis on correctness and maintainability, that it would spill over into other aspects of thei

Re: Software bugs aren't inevitable

Hmm, They seem to have reorganised things. As I write, the main article starts here: http://www.spectrum.ieee.org/sep05/2164 With the sidebar here: http://www.spectrum.ieee.org/sep05/2164/extsb1 - Paddy. -- http://mail.python.org/mailman/listinfo/python-list

Re: Software bugs aren't inevitable

Steven D'Aprano <[EMAIL PROTECTED]> writes: > It is a "mere implementation detail" that (for most computer systems, and > most programming languages) stack space is at a premium and a deeply > recursive function can run out of stack space while the heap still has > lots of free memory. Every serio

Re: Software bugs aren't inevitable

On Wed, 14 Sep 2005 14:32:17 +0200, Jerzy Karczmarczuk wrote: > First of all, the recursive version of Fibonacci IS EXPONENTIAL in complexity, > don't say such not-quite-truth as "not quite". Your correction is noted. I had compared the work done with 2**n, but of course any constant greater tha

Re: Software bugs aren't inevitable

On Wed, 14 Sep 2005 11:28:02 -0400, Terry Reedy wrote: > > "Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> 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-requ

Re: Software bugs aren't inevitable

Terry Reedy wrote: > But that, I admit, would be an invalid conclusion. And that, I claim, is > also invalid when 'iteration' and 'recursion' are reversed, no matter how > often repeated in texts and articles. The difference is between the > algorithms, not the differing syntactic expressions

Re: Software bugs aren't inevitable

"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 > sign

Re: Software bugs aren't inevitable

Paddy wrote: > 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. I used to work at Praxis about 4 years ago and Perl was their scripting language of choice at that tim

Re: Software bugs aren't inevitable

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

Re: Software bugs aren't inevitable

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).

Re: Software bugs aren't inevitable

"Paddy" <[EMAIL PROTECTED]> writes: > A work colleague circulated this interesting article about reducing > software bugs by orders of magnitude: > http://www.spectrum.ieee.org/WEBONLY/publicfeature/sep05/0905ext.html This gets a not found error. Got a different link? > Some methods they talk