Re: Iteration over recursion?
Bruno, > It doesn't. Technical possible, but BDFL's decision... Sure. But why bother? Anything that can be done with recursion can be done with iteration. Turng proved that in 1936. Recursion was just an attempt to "unify" design approach by abstracting itteration and creating a new context. It allowed the programmer to isolate himself from the reality that he was actually iterating. Talk about mind fuck. It seems things were just to simple the way they were. Like all fashion, this too shall pass. Sudden Disruption -- Sudden View... the radical option for editing text http://www.sudden.net/ http://suddendisruption.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Iteration over recursion?
Bruno, > Yes. And everything done with Python can be done with assembly language > too. It's even more general than that... To simply Turning, anything that can compute, can compute anything that can be computed - hardware OR software. But that doesn't mean you should use it. Imagine if we all took that to heart and only coded for the Turing Machine! So yes, I'll concede the point. Some tools ARE better than others. It's just that recursion is more often misused than not. > Recursion is the most convenient way to express some common algorithms. Yes. But very few. > Too bad for you if it does some nasty things to your mind. It's not recursion per se that does the nasty things. It's the way it's been promoted over the years when the simplier iterative solution is a better choice. Sudden Disruption -- Sudden View... the radical option for editing text http://www.sudden.net/ http://suddendisruption.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Iteration over recursion?
Nick, > you will have cursed the concept to hell and back again. Been there - done > that :-( My point exactly. Years ago with Pascal I took the recursive approach way too often with much distress. I began to learn that if I move enough stuff out of the loop and set up a context that could easily see what was getting "re-cursed" (great term), iteration was often much easier to debug and FAR more effective to execute. Since those times I can count on one hand the times I've used recursion - and then only because I was late for lunch and I knew "i" wouldn't get away from me. > As someone who was in this area when the Algol versus Fortran wars were I'll take your word for it. My start with recursion was Pascal. > Agreed. Recursion should be used when it is the right technology to > clarify the code, and not as a gimmicky, obfuscatory and often dogmatic > substitute for iteration! Well put. > There are algorithms that become almost incomprehensible without recursion, > and I > have implemented a recursion layer in both assembler AND Fortran just to > enable me > to write them without going bonkers. With a reasonable exception. Sudden Disruption -- Sudden View... the radical option for editing text http://www.sudden.net/ http://suddendisruption.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: how do you move to a new line in your text editor?
John, > This is a real small point No point is small when you apply it hundreds of times a day. I spent quite a bit of time on this element and ended up allowing conversion from tabs to spaces and the reverse. Who knows what you'll find in the world of ASCII. Historically, Tabs were stops on the typewriter carriage, a control function. This Tabs = Spaces thing came about largely because of cursor bondage. So how do YOU think of a Tab key? Is it a data key or a control key? Internally, I treat Tab (and Shift Tab) as a navigation (control) key instead of pumping in lots of spaces. It seems more useful that way. But then Sudden View doesn't have "cursor bondage" to worry about. Sudden Disruption Try Sudden View - for the art of editing text Beta test now in progress at... http://www.sudden.net/ -- http://mail.python.org/mailman/listinfo/python-list
