I couldn't help but read this and think about all the "coding" initiatives I've seen in K-12 and shake my head.
What Norvig is doing is what we should be teaching. He is tackling this seemingly REALLY hard problem by thinking about it methodically, translating some intuition into code, carefully constructing an argument about how to solve it, and ways that it could be extended. This is what actual engineers look like.
Everything I've seen around "coding" though has become a masochistic exercise in teaching kids random syntax details and then calling them Coders and Geniuses and Computer Scientists when they successfully copy what the teacher showed them.
When you read Norvig's code (big fan of his Sudoku one as well), you realize how the actual "code" is secondary in the sense that what it is really doing is expressing an idea. A very nunanced, elegant idea, but ultimately the product of doing some hard thinking and exploration on a problem domain.
If we taught kids to just think about problems in this way, ohh what a world it would be!
I agree that what Norvig demonstrates here and in all of his notebooks is an ideal of how we use programming to explore (nevermind implement) concepts. But how do we get there without teaching people how to program, including syntax? I think everyone agrees that kids should be able to understand the themes of "A Modest Proposal" and perhaps even write with such depth, but they have to learn their ABCs and be compelled to write about what they ate for breakfast and other insignificant topics before they get to an adequate level.
I wish I could say that in my time of teaching, I've met people who could just get these things without actually writing code. But I think for most non-geniuses, including myself, it's all too abstract until you know how to concretely write code yourself.
Ohh I completely agree with you. But what I was mostly reacting to is the idea that the way to propel these kids into the 21st century is to simply teach them some basic coding syntax and leave it at that. Even the new AP CS curriculum seems to take a step back from "hard cs" by adding lots of content not directly related to solving cs problems. All that I really meant is that the true value in coding comes in using it to express solutions to problems, whereas teachers and schools that I've seen try to implement "coding" seem to think that if these kids just memorize syntax they have some great advantage in life.
I'll give you a perfect example. I was asked to evaluate this Scratch course for middle schoolers just as they were about to present their final projects. One of the kids did a basic pong-like game with human-controlled characters. The ball would move all over the place, seemingly randomly. The game didn't seem to make any sense to the kids who played it. But, the administration felt that this was an incredible success.
I later learned that he had produced the game by mostly following along a step-by-step tutorial introduced in class. And I also learned that the reason the ball moved erratically was that the kid had absolutely no concept of how to deal with the angles, much less identify what portion of the character the ball had struck!
To me, THAT would have been the real learning! What an opportunity to have taken that kid outside and kick a soccer ball (this was in Brazil) outside and explore some intuition about how it rebounded on the wall; what a chance to see if he could not come up with a way to grok a solution to figuring out to detect where in the character the ball had hit since this didn't come out-of-the-box in Scratch.
In other words, I don't mind that they learn the syntax. But there's a reason why firms outsource a lot of "coding" to South Asian countries for pennies on the dollar. Knowing the syntax is cheap. Stimulating kids to think about problems, developing a routine and passion about solving them, that's where the real pot of gold is.
The compiler/interpreter will correct your syntax. Explain it once and show where the documentation is, then let kids loose. There's no need to do a worksheet with 100 "spot the syntax error" problems or to have to write it out by hand on a piece of paper to learn it. That kind of pain is only going to teach kids that programming is a boring game of "find the missing semi-colon".
They're going to have to play that game anyway since the compiler/interpret won't spell out the exact issue every time. But they'll get through it anyway because their goal is something else rather than that game. A lot of learning comes from getting past stepping stones, but targeting a stepping stone as an explicit thing to learn and drill on is a poor plan.
But what you should realize is that the person who wrote this beautiful piece of code is someone who is at the peak of their career, a thinker, an artist, and that it must be ok to not ever rise to his level, because this is close to a master-piece. Few of these geniuses become professors, is just a guess, because no matter how quirky you are you always get a job somewhere.
I think Norvig's actually improved substantially since he wrote this — he wasn't at the peak of his career! But yes, it's a masterpiece, and yes, it's okay to not ever rise to that level, because even if nothing you ever create is as worthwhile as this, it's still worthwhile. Hacking is fun! And sometimes very useful, too.
(Also note that, despite appearances, this isn't the work of one man. Norvig didn't design Python and didn't invent the tabling technique for speeding up search; and Darius found a couple of bugs in the code. That doesn't mean it's not an authentic Norvig masterpiece.)
Sir, btw, I need a rule that I can use intuitively when deciding on wether to concatenate two words and when to put a dash between them. Do you have one?
Sir, it depends entirely on how widely used the compound word in question is. Hyphenated compounds that become sufficiently familiar lose their hyphen.
It's funny, I was given this as a lab assignment around when the article came out. In fact, we were shown the article. We had an hour, maybe two, for the lab and had to re-implement it in C++. At this point I already had 3-4 years of experience with C++ but found the task ABSOLUTELY daunting. Looking at it now it seems simple, but I'll never forget trying to figure out how this works for the first time with the two hours I was given. Even if a solution is simple, understanding it can be hard, especially if it seems like it should be hard.
I agree, you could learn so much just looking at how he defines functions.. see this for example:
def pdist(counter):
"Make a probability distribution, given evidence from a Counter."
N = sum(counter.values())
return lambda x: counter[x]/N
P = pdist(COUNTS)
"If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea."
That's a lovely idea although I can't help noticing that I know of no shipbuilding companies based on the teaching of yearning while I do know of some that seem based on organising a workforce. I suspect that this is one of those ideas that while beautiful is far from being literally true.
How about "if you want your citizens to fund a space program, don't gather the workforce to build a spaceship but teach them to yearn for the vastness and potential of the void."
programming is already such an opaque concept before you learn it, kids entering the class won't even really know what programming is.
if you start with a single-minded focus on syntax, as most do, the kid's mental model of programming becomes "programming is done by entering premade code words that someone made up. if i want to do something, i need to find the premade code word that does that thing".
as opposed to, "programming is about blobs of information and what i do with them - changing their shape, organizing them, picking certain things from them, taking stuff away from them. if i want to solve a complicated problem, i won't start typing, i'll start thinking about how i'd make a machine that makes the blob i want. the best way to make a machine like that is usually out of smaller machines that live inside it. i'd figure out what the smallest machines i need are, and i'd make those, and then use those to make the bigger machines, until i'm done."
if kids were started with a functional, problem-solving oriented approach like that, you'd create very capable programmers much faster. this applies to introductory CS classes in college. i went into my first CS class knowing absolutely nothing about programming beyond CSS/HTML - i was a math / mech eng major at the time. i think it was the third class where they had us write a program in C that did some non-trivial dynamic allocation. they never told us things like what the heap or the stack are, or the concept of a memory leak, what happens if you dereference a null pointer, etc, etc. i never got that program to stop segfaulting. i came very close to failing that class and was told, because of that, i probably shouldn't continue with CS. i taught myself computer science instead and now i know that i'm not stupid or unsuited to programming - my introductory CS education was shit.
The commenter right above you expressed the same issue, and I wrote a longer reply there. But it's not that I don't think syntax is important, but I don't think we should pretend that the value in learning to code is learning the syntax. What I'm reacting to is "coding" programs that seem to eradicate any semblance of forcing kids to confront hard problems in favor of presenting them with trivial exercises for the sole purpose s of claiming "they can code."
Yes, my son's High School Software Course has a lot of old dusty design content (data flow diagrams), chunks of soft content - "social impact of computers".
And the actual coding is a Visual Basic forms and a bit of html/javascript.
Very little in the way of what I would call proper coding: data structures, algorithms.
What Norvig is doing is what we should be teaching. He is tackling this seemingly REALLY hard problem by thinking about it methodically, translating some intuition into code, carefully constructing an argument about how to solve it, and ways that it could be extended. This is what actual engineers look like.
Everything I've seen around "coding" though has become a masochistic exercise in teaching kids random syntax details and then calling them Coders and Geniuses and Computer Scientists when they successfully copy what the teacher showed them.
When you read Norvig's code (big fan of his Sudoku one as well), you realize how the actual "code" is secondary in the sense that what it is really doing is expressing an idea. A very nunanced, elegant idea, but ultimately the product of doing some hard thinking and exploration on a problem domain.
If we taught kids to just think about problems in this way, ohh what a world it would be!