the right thing*.
snip
As a result I'd say that the subject Software bugs aren't inevitable
is not true.
I think you can argue (I would) that any behaviour that is in the
specification this isn't right is not a software bug, but a
specification error.
To a user there is no difference
Terry Hancock wrote:
/a few statements which seem to be there - apparently - just for the sake
of quarreling/
The FP camp (apparently) wants to advance the claim that FP will *always*
reduce bugs. I find that very hard to believe.
Good.
Now go, and talk to some FP people before accusing them
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 threads,
In article [EMAIL PROTECTED], Mike Meyer [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Aahz) writes:
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] wrote:
Every serious FP language implementation optimizes tail calls and thus
using recursion instead of iteration doesn't cost
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 willing
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]
--
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 computers,
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.
That
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 silly things when
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 that if
translate into bugs, no matter what approach you use.
It's why I find XP and agile approaches interesting, they're often more
than just engineering.
As a result I'd say that the subject Software bugs aren't inevitable
is not true.
Regards,
Michael.
--
[EMAIL PROTECTED], http
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
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 iteration?
It
As a result I'd say that the subject Software bugs aren't inevitable
is not true.
I think you can argue (I would) that any behaviour that is in the
specification this isn't right is not a software bug, but a
specification error. This obviously puts the focus on specification
errors, but standard
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 are
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 programming
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 is a
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 effect of
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. Yes, there is
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
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?
That it is
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
[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
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 on than
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
(eg
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 while the
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 ADA
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 fibd(n):
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 saying that
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
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
machine code,
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
recursive
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 finite
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 your
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] 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 of the
[EMAIL PROTECTED] (Aahz) writes:
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] 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
[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: return 1
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. This is
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 dunno
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 about
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
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) +
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 time
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
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
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-requirement
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 than
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 serious FP
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
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
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 space
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 versa.
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 iteration.
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 are no
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 ADA based language Sparc
55 matches
Mail list logo
