The infinite-recursion paradigm
-
I'm a TA in an advanced course that includes a programming project (I use the term freely, as this could be completed in 300 loc).
Anyway, in two years in a row, I have two studetns submitting me the same new paradigm for programing. The code needs to read input and send appropriate output. These two brillant students came up with the following: Whenever they read input that needed to start a new section, they went on and recursively called the handler for that section. When it was finally time to exit they simply did exit(0).
-
Nice... a classic case of (future) "programmers" who have no idea how a computer actually works.
-
I think that you should compare this with the following article:
http://thedailywtf.com/forums/thread/84085.aspx
-
@Thalagyrt said:
@GettinSadda said:
I think that you should compare this with the following article:
http://thedailywtf.com/forums/thread/84085.aspxEr, 10 points for linking from the thread to the same thread.
And 10 more points. And 10 more points. And...
-
@epsalon2 said:
I'm a TA in an advanced course that includes a programming project (I use the term freely, as this could be completed in 300 loc).
Anyway, in two years in a row, I have two studetns submitting me the same new paradigm for programing. The code needs to read input and send appropriate output. These two brillant students came up with the following: Whenever they read input that needed to start a new section, they went on and recursively called the handler for that section. When it was finally time to exit they simply did exit(0).
Err that's ostrich recursion - jump out when you're in trouble, stick your head in the sand and pretend everything's fine.
-
@epsalon2 said:
I'm a TA in an advanced course that includes a programming project (I use the term freely, as this could be completed in 300 loc).
Anyway, in two years in a row, I have two studetns submitting me the same new paradigm for programing. The code needs to read input and send appropriate output. These two brillant students came up with the following: Whenever they read input that needed to start a new section, they went on and recursively called the handler for that section. When it was finally time to exit they simply did exit(0).
Actually, that is a perfectly reasonable approach for at least "functional" programming languages.As opposed to "procedural" progamming languages. I'm assuming your talking about the latter, but still consider that it might be valid in other paradigns.
Some compilers for specific languages will even optimize recursive functions to run as a loop on an imperitive processor.
-
@R.Flowers said:
@Thalagyrt said:
@GettinSadda said:
I think that you should compare this with the following article:
http://thedailywtf.com/forums/thread/84085.aspxEr, 10 points for linking from the thread to the same thread.
And 10 more points. And 10 more points. And...
And close the browser window when you're done following the thread.
-dZ.
-
The assignment is basically to write an agent that participates in various types of auctions, but all communication has been abstracted out of the problem, leaving the students only to write a simple program reading input and writing output.
It's not a functional programming language, we're talking about C, and they didn't use tail recursion, and in some obscure cases the functions would have actually returned, wrecking havoc on the behavior of the program.
-
@danielpitts said:
Some compilers for specific languages will even optimize recursive functions to run as a loop on an imperitive processor.
That's called "Tail recursion optimization", and as it says, it only works for tail-recursive functions (be it in functional or in imperative languages). If your function is not tail-recursive, the interpreter/compiler won't have any way to optimize it (into a simple loop) and you'll blow the stack.
GCC is able to do tail recursion optimization BTW.
