On Jun 7, 2013, at 8:59 PM, ben <bfranchuk at jetnet.ab.ca> wrote: Recursion is a tool, just like iteration. In cases where it's useful the code is clearer/cleaner than if it was written with say iteration. Stack overflow is a bug just like any other and your point is? Given the number of compilers I've written, I wouldn't write a parser that wasn't recursive decent. It's easy to write that way and easy to read the parser code (can't say that about a table driven parser). Tree walks are another case where recursion is the way to go. Iteration results in ugly looking code. Also, different languages lend themselves to different ways of thinking about a problem. Some problems are easier to express in some languages than others. I think functional programming languages are along those lines. There are a class of problems that can be solved easily (ok, easier) in a functional language than in say a procedural language. I think part of the problem with why folks perceive this topic difficult is that they only have experience with a single class of languages. Unless you've had to work in multiple *classes* of languages and really understand the problems that a particular language class is trying to solve, folks will try to use techniques from a previous language in the new language. It's always easy to tell when that's done. I remember when I was taking an APL course, there were a number of problems that needed to be solved and were told at the beginning that we'd fail if we *ever* used iteration. You really had to think about the problem differently. TTFN - Guy

On Fri, Jun 07, 2013 at 09:44:36PM -0700, Guy Sotomayor wrote: There is a certain amount of confusion forming in this thread. It is idiomatic in functional programming to use recursion for things that would normally be done with iteration in imperative languages. This is because "variables" aren't, and you can't assign new values to them. That means no loop counters, for example. So one "cheats" by creating a little helper function into which the value you want to change is passed into it, and which calls itself where necessary. The compiler's optimiser then uses tail-call optimisation to turn it back into a loop again! There are two reasons for the immutability of variables. The first reason is because ivory-tower computer scientists are really crusty old mathematicians at heart and that's what the theory dictates. I think these people should get out more. The second reason is one I am much more interested in. Because variables are immutable, this means data structures can be shared between threads without having to faff around with atomic updates and locking. This takes away some incredibly hard-to-debug problems with synchronisation and data corruption. In real-world code, you need a hybrid approach, which is why I've a certain fondness for Scala which allows me to use functional most of the time, but also drop in imperative code in hot spots that need a bit more performance.

On 6/7/2013 11:18 PM, Dave McGuire wrote: Is rebooting the computer a option?

On 6/7/2013 10:18 PM, Dave McGuire wrote: Or proper tail-call optimization... - Josh

On Fri, Jun 07, 2013 at 09:59:11PM -0600, ben wrote: tail recursion. http://www.haskell.org/haskellwiki/Tail_recursion Diane -- - db at FreeBSD.org db at db.net http://www.db.net/~db

On 06/08/2013 10:27 AM, Fred Cisin wrote: One aspect that I've noticed over the years is that, generally speaking, people who use recursion in memory-limited situations are less able to accurately tell you how DEEP they can recurse before running out of memory. The ones who iterate usually can tell you precisely. Similarly, the one using recursion usually will be able to tell you less about error recovery than the iterative user. In practice, there's no really good reason for this to be true, but it is something that I've noticed. Recursion and iteration are methods and both have their place--and are equally disastrous when badly implemented. --Chuck

On 06/08/2013 12:19 AM, Mouse wrote: Indeed, that has been my primary objection to the lumbering pigs that are object-oriented codebases. Pretty much everything found under MacOS X nowadays, for example. FP does have the same problem. Lispers and Schemers, in particular, say it's "no longer a problem" because "computers are so much faster now" and "have so much memory". This is directly indicative of the problem. Of course I myself am a schemer, when I wear that hat, and I do fully half of my work these days in R. So I see it from both sides. The power of those languages just has to be experienced to be believed...and if I have to put together a beefier computer to get at that power, I'll do it! It's contrary to my every instinct, but still it is so. Absolutely. The stuff under the hood is NUTS. And yet still I keep reaching for R whenever I need to manipulate big piles of numbers...but I'm certain more seasoned R/S programmers would say that I write very nice C code in R. ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

Agreed. But it also contains some truth. Sometimes, especially when doing exploratory computing or other one-offs, the programmer time versus CPU cycles tradeoff is weighted in favour of saving programmer time. That's when higher-level languages like Lisp, or Prolog, or Haskell, or etc, come into their own - even more so when one matches the problem particularly well; consider, for example, FFTW's use of OCAML to find code fragments that do useful things (the documentation remarks that their code generator has found algorithms they do not understand). Certainly. To dogmatically decree that FP has no place is just as false as to dogmatically decree that it is an advance over everything else. Like most (all?) other programming methodologies, it has a place, but that place is not everywhere. Part of being a good programmer is knowing how to pick a paradigm (and language) appropriate to the task at hand. Sometimes code space efficiency wins, so you go for something small, usually slow and probably interpreted. Sometimes execution time wins, and you go for something compiled close to the hardware, like C or occasionally even assembly. Sometimes programmer time wins and you go for whatever is most familiar to the coder and not a horrible match to the problem, which could be C or sh or R or APL or perl or whatever. Occasionally the language is externally constrained, as when tweaking an existing codebase or doing an assignment for a programming-language course, and you have little choice. But, if all you have is a hammer, all problems look like nails. Even when they're actually screws...or velcro. Insisting on your favourite language regardless leads to one-liners like "when your hammer is C++, everything looks like a thumb" or "I had a problem; I used Java to attack it and now I have a problem factory". Indeed. When I managed to write generators using continuations, I was both pleased and proud, on the one hand, and appalled, on the other - the former because it worked, and in a conceptually pleasing way; the latter because it worked very wastefully - it absolutely slaughtered execution speed, running slow even on my fast machines. (Not that my Lisp was any kind of speed demon to begin with. But, even for it, this was slow.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B