3 ms·

> The barrier is in the sequential part of the topic pbhjpbhj's point still stands -- the question is "supremely facile" once you get past matters of syntax. F

> The barrier is in the sequential part of the topic pbhjpbhj's point still stands -- the question is "supremely facile" once you get past matters of syntax. For example, most third graders could solve the problem when you make the time indexing explicit: a(1) = 10 and b(1) is undefined. a(2) = a(1) and b(2) = 20. b(3) = b(2) and a(3) = b(3). What is the value of a(3) and b(3)? We can go a step further for students still struggling by associating to each variable at each time step a fresh variable (bonus: when they see SSA it'll be a breeze): Q = 10 W is undefined R = Q T = 20 Y = T U = Y What are the values of Y and U? I've had students for whom even this didn't work, so I definitely don't believe "everyone can code". But still, if 30 - 60% of your students can't solve this problem, then there's something very wrong with the way the course is being managed, because I don't even get close to that percentage with sixth graders. Of course, I take the time to explain in excruciating detail what the symbols mean. So if I had to bet, it means that no one is sitting down and taking the time to help students get up to speed on the meaning of the syntax for this huge engineered system that was just thrown at them. Which is a real shame, because having these sorts of difficulties early in an intro course is, IME, completely uncorrelated with how the student will do throughout the rest of the curriculum. You see the same thing when tutoring for early mathematics courses -- most students in the bottom of the distribution are having difficulty because some historical-cruft syntax is presented and not properly explained in lecture. Unsurprisingly, if no one bothers to explain what the hell the symbols mean, three more weeks of using the symbols to do more complicated stuff isn't particularly useful. So lack of movement among the groups isn't surprising, but reading off from that anything other than lack of sufficiently differentiated instruction is a fool's errand. > Requiring prior exposure to succeed in a degree is an oddity 1. This is obviously not true for any of the natural sciences or for mathematics. It's also not true for English -- students have already done a lot of reading and essay writing by the time they get to college. Maybe it's a little more true for engineering fields, but at least there students are expected to have some background in math and physics. Oh, and also, typically take some university-level science and math alongside or prior to their serious engineering courses. 2. Requiring the mastery of large engineered systems during the first week or day of a course is also an extreme oddity.

jdmichal 10y ago
I'll defer to your experience on the first portion. I only did a bit of CS tutoring while in college, and sequential logic was one of the big issues I saw in the intro classes. Recursion was, of course, usually the next big hump after that. I definitely understand the point about opaque syntax, and do agree that, in both math and CS, the tendency is to simply throw these things at students. Compare to the approach taken by R6RS [0]; it's very explicit about symbols and locations and values and what operations like assignment mean. On the second point, however, I still have some dispute. In maths or natural sciences, are you really expecting prior exposure to the subject matter? Or are you expecting a foundation upon which to build further? [1] I think the latter is a more appropriate statement. However, in CS, I feel it's more the former. "You must have experience programming, so that we can teach you how to properly program." If someone already knows how to program, what are they doing in a CS program other than getting a piece of paper that certifies their knowledge? Indeed, this is the argument you see regarding drop-outs or "equivalent experience" in lieu of degrees. This is why I argue that we should instead find those fundamental building blocks and teach those instead. Basically, extract programming from the domain of computers, and figure out how to teach that. Then learning programming is about how those concepts apply to the domain of computers, much like how aerospace engineering is about learning how physics applies to airframes. [2] [0] http://docs.racket-lang.org/r6rs/r6rs-std/r6rs-Z-H-2.html#node_toc_start http://docs.racket-lang.org/r6rs/r6rs-std/r6rs-Z-H-2.html#no... [1] It doesn't help that something like "math" is really more of an umbrella term for a large number of fields across different domains. [2] This is, I'm sure, a huge simplification. Hopefully you can see the intent of my point and overlook the crude analogy.

jdmichal 10y ago

I'll defer to your experience on the first portion. I only did a bit of CS tutoring while in college, and sequential logic was one of the big issues I saw in the intro classes. Recursion was, of course, usually the next big hump after that. I definitely understand the point about opaque syntax, and do agree that, in both math and CS, the tendency is to simply throw these things at students. Compare to the approach taken by R6RS [0]; it's very explicit about symbols and locations and values and what operations like assignment mean. On the second point, however, I still have some dispute. In maths or natural sciences, are you really expecting prior exposure to the subject matter? Or are you expecting a foundation upon which to build further? [1] I think the latter is a more appropriate statement. However, in CS, I feel it's more the former. "You must have experience programming, so that we can teach you how to properly program." If someone already knows how to program, what are they doing in a CS program other than getting a piece of paper that certifies their knowledge? Indeed, this is the argument you see regarding drop-outs or "equivalent experience" in lieu of degrees. This is why I argue that we should instead find those fundamental building blocks and teach those instead. Basically, extract programming from the domain of computers, and figure out how to teach that. Then learning programming is about how those concepts apply to the domain of computers, much like how aerospace engineering is about learning how physics applies to airframes. [2] [0] http://docs.racket-lang.org/r6rs/r6rs-std/r6rs-Z-H-2.html#node_toc_start http://docs.racket-lang.org/r6rs/r6rs-std/r6rs-Z-H-2.html#no... [1] It doesn't help that something like "math" is really more of an umbrella term for a large number of fields across different domains. [2] This is, I'm sure, a huge simplification. Hopefully you can see the intent of my point and overlook the crude analogy.