Basic computer skills need to be taught. Coding? It should possibly be a required semester in university for all majors. ...beyond that? Does everyone really need to know about recursion?
Basic computer skills need to be taught. Coding? It should possibly be a required semester in university for all majors. ...beyond that? Does everyone really need to know about recursion?
Some papers on that:
http://www.bogost.com/writing/procedural_literacy.shtml
http://dm.lcc.gatech.edu/~mateas/publications/MateasOTH2005....
http://www.cs.cmu.edu/afs/cs/usr/wing/www/publications/Wing0...
Does everyone really need to know about recursion?
Does everyone really need to know the basics of calculus? Or how about genetics? Does everyone really need to know French? I had classes for the above in my high-school. In fact I can't think of any class I took in high-school that isn't useless to a large portion of high-school graduates.And I can't think of many examples that are more useful than grasping the concept of recursion.
One of the most horrifying pieces of Perl I had to work on was written by a biologist who knew just enough Perl to translate certain information from File Format A to File Format B. Or at least, he thought he knew just enough Perl....
A lot of businesses depend on complicated Excel spreadsheets whose authors don’t realize that they are programming.
Yes, and I'd argue indirection as well. If you teach coding without recursion, you're just teaching basic logic coupled with arithmetic, we have classes for that already. (As an aside, I think iteration should be introduced as a special case to recursion.)
Coding (especially for high schoolers) doesn't have to be "sitting in front of a computer alone all day", in fact if this is how it's presented that's totally the wrong approach. That comes in the pro stage. At he early stage you have to stress the creative and social aspects of coding.
Now... how many people in the industrialized world don't spend at least part of their day interacting with programmable devices?
Recursion is taught in gym class through the game of dodgeball. Consider the following C-like pseudocode:
void throw(int *ball, int hits)
{
if (hits < NUMBER_OF_PLAYERS)
throw(ball + angle(), hits + *ball);
else
return;
}
The question then becomes, do people need to learn specific computer languages, or is teaching the underlying concepts in abstract ways enough? def dodgeball(players, balls)
until players.all? { |p| p.is_hit? }
throw(nearest_ball(balls), nearest_player(players))
end
end
Most people think like this. Dodgeball teaches while loops, not recursion.I'm sorry to be a jerk, but I found your code pretty tough to decipher. Here's my thought process:
NUMBER_OF_PLAYERS could be, say, 6.
the caller calls: throw(ball, 0);
0 < 6, so throw(ball+angle(), 0+dereference(ball));
So, what is ball? It's either an integer and you're just passing its address around for no particular reason, or it's an integer array and you're using angle() to move around inside the array somehow? Then what exactly is stored in that array, the positions of people? Let's imagine it's 1s and 0s to denote a person or not.After making that leap of logic, your code starts to make sense. You're adding "some amount" to the address, and then whatever is at that address (1 for hit, 0 for nothing) to hits, and passing them into the next invocation, as long as it's less than the necessary number of hits. Could easily be a while loop, but I'll get to that in a minute. I have some other points:
- Ball isn't a great name for the list of the positions of the players.
- It isn't clear that ball is an array.
- There's a pointless 'else return'.
- You never address the "I don't have a ball" situation!
This code requires explanations of arrays, pointers, and addresses before you can talk about recursion. I'd express how to play dodgeball to a new programmer as follows: throw(angle, enemy_positions):
# This function takes an angle and a list of
# the spots where other people are, removing
# them from their spot if it registers a hit.
# Returns true if it's a hit, false if a miss.
find_ball():
# Tries to find a ball; returns the number
# which you found -- 0, 1, or 2.
load_enemy_team():
# Returns a list of the spots where other players are
enemy_positions = load_enemy_team()
players_on_other_team = enemy_positions.length()
ball_count = 0 # all balls start in the middle!
while players_on_other_team > 0:
if ball_count > 0:
angle = get_throw_angle() # user inputs this
hit = throw(angle, team_positions)
if hit:
shout("Yahoo!")
players_on_other_team -= 1 # they're down a guy!
else:
ball_count += find_ball() # reload
That should cover it - though I'm sure there's problems with my code too. :)The biggest point I want to make is that this example is trivially easy to represent without recursion. While recursion can be used in place of any loop, a non-programmer's mind will likely arrive at iteration first for tail-recursive examples. And once someone understands how to solve a problem one way, teaching them a totally different way can be tough.
I personally think people do pretty well at understanding how recursion applies with respect to exploring a maze, which is almost as universal an experience as dodgeball.
From a code maintainability point of view, yes. I would never write code like this for a real application. However, for analogizing the game in code, I have to strongly disagree.
Ball is not a list of players. It is, just as in the game, a pointer to a location in space. Players may or may not occupy that space. If the player does, a hit occurs. The hit test is based on the intersection of the location in space and the occupation of that space.
I chose to represent my code in a C-like manner because it makes that spacial representation easy to write. People are not thinking about the game in terms of lists and objects, that I am sure.