Our tests were either multiple choice or we typed up something, compiled, and gave them the source + executable.
Every CS class I took while in school a few years ago had handwritten portions. Granted it wasn't full programs (most of the time) but it was still frustrating because in the real world you could debug and step through code.
The vast majority of my CS tests required you to write code on paper. That included my assembly class, and my advanced data structures class, where I remember having to write the code to rebalance an AVL tree during a midterm.
I wrote code during an entrance interview once. That felt like a huge waste of time because it wasn't a programming language but a made up language from the company.
I guess that's still better than fizzbuzz though.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
I could go into the pedagogical benefits of having students handwrite code if you'd like...
That sounds like a fun way to say, "completely worthless except for the subset of students who like to write neatly."
Challenge accepted! First, we need to understand that tests serve primarily as a metric of measuring student mastery of pre-determined learning goals and a forcing function for students to master those goals. So the question is, what learning goals are tested when a student writes code on paper?
(1) Writing code away from a computer tests mastery of language syntax. This is a fine learning goal for an introductory course but should not be a high-priority (if it is emphasized at all).
(2) Writing code away from a computer is itself a useful skill in the context of a job interview or in the workplace. Developers will need to talk about programs with other developers at various levels of detail and this will usually be away from a computer. Furthermore, it is a useful technique to avoid hammering on an IDE/compiler (see next bullet) and write down thoughts, ideas, and partial programs on paper away from a computer. Setting aside a time in the classroom to do this emphasized the importance of this skill.
(3) Finally, writing code on paper forces students to think critically about the code they are writing. While REPLs and quick compilation loops give instant feedback to the student which in turn helps accelerate their learning, students frequently fall into the trap of "hacking their way out of a hole" rather than taking a step back and critically thinking about the program they want to construct. Students need to develop a mental model of how their programs work which can be impeded by the availability of a tool that can (partially) do that work for them. Thus, offline work is essential to develop and test that they are correctly developing that model.
There are also pragmatics and legitimate concerns of academic dishonesty. If the course (in particular a large course) does not have access to a sufficiently large computer lab, then their only recourse may be a "traditional" test in a lecture hall on paper as the risk of cheating outside the classroom could be too high for their tastes.
Here's a blog post that goes into the pros and cons of written code on exams that was the result of a discussion on the sigcse mailing list:
Sorry, I don't agree with any of that just because someone 'feels' it or 'there isn't enough space'
Trial and error is an important way to learn, too, actually.
I disagree with the entire premise here, and since this is all 'opinion' the only way I'd be happy is if there's metrics presented.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
acidlacedpenguinInstitutionalizedSafe in jail.Registered Userregular
My school apparently had one of the most esteemed and was among the first universities to offer a CS program. We had to write code on paper but aside from having to memorize the java shit for buffered readers and doing stuff with streams there was an understanding that it would for the most part not compile. So if you forgot braces or semi-colons sometimes they wouldn't really dock you for it... except for the first year classes where apparently the only takeaway you should have is where to put your punctuation .
I always thought it was bullshit because I like to approach writing a particular non-trivial component in baby steps, like get it working in a bare-bones sense, then get my functions returning *something*, then control structure and the real logic. That way when I catch myself doing something that wouldn't work with my original expectations of how it's all going to work I can make revisions to those expectation relatively inexpensively. This kind of approach isn't as feasible without any feedback whatsoever.
My school apparently had one of the most esteemed and was among the first universities to offer a CS program. We had to write code on paper but aside from having to memorize the java shit for buffered readers and doing stuff with streams there was an understanding that it would for the most part not compile. So if you forgot braces or semi-colons sometimes they wouldn't really dock you for it... except for the first year classes where apparently the only takeaway you should have is where to put your punctuation .
I always thought it was bullshit because I like to approach writing a particular non-trivial component in baby steps, like get it working in a bare-bones sense, then get my functions returning *something*, then control structure and the real logic. That way when I catch myself doing something that wouldn't work with my original expectations of how it's all going to work I can make revisions to those expectation relatively inexpensively. This kind of approach isn't as feasible without any feedback whatsoever.
That is a sensible way to attack a project.
Writing code on paper doesn't teach skills, it teaches rote memorization of APIs and languages. That's not necessarily helpful and I'll keep my stance that hand writing code is ridiculous. You want to weed out whack-a-mole coders? Time the test. Whack-a-mole coders don't make it past data structures usually anyways. You either get pointers or you don't. There's no hack-method to get through them.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Sorry, I don't agree with any of that just because someone 'feels' it or 'there isn't enough space'
Trial and error is an important way to learn, too, actually.
I disagree with the entire premise here, and since this is all 'opinion' the only way I'd be happy is if there's metrics presented.
"There isn't enough space" and other issues of pragmatics are very legitimate reason that things are done the way that they are. You might not like them, but idealism aside, people have to work within the confines of what they are given and those are very, very frequently un-ideal conditions (in this context, too many students and not enough space).
Trial and error is an important way to learn how to code, but is is certainly not an ideal way to actually develop programs on a day-to-day basis. That's the distinction that I'm making, and it is a very important one as many students walk out of introductory programming classrooms without a mental model of computation, arguably the concept you want to impart on students.
Unfortunately, computer education research is not as quantitative as we would like although people are working hard at fixing that. So there aren't specific studies that I know of that test the merits of hand-writing code in the classroom. That being said, the points and the blog post above are drawn from my experience in the classroom and industry as well as the collective wisdom of experts in the field. It isn't conclusive evidence of anything, but it is a good guide when there is no quantitative evidence out there.
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
Writing code on paper doesn't teach skills, it teaches rote memorization of APIs and languages. That's not necessarily helpful and I'll keep my stance that hand writing code is ridiculous. You want to weed out whack-a-mole coders? Time the test. Whack-a-mole coders don't make it past data structures usually anyways. You either get pointers or you don't. There's no hack-method to get through them.
To those points:
(1) Good code-on-paper test questions specifically avoid points of API memorization and language minutiae as the blog post outlines. And as penguin pointed out, syntax is typically hand-waived in everything but intro classes (where syntax is a legitimate learning goal).
(2) Timing the test helps but is not a complete answer and is ultimately orthogonal to handwriting code-or-not.
(3) Banking on later courses for people to "weed themselves out" is just plain irresponsible. Just like in programming, you want students to fail early and fast so they can respond accordingly. If your course demands that they have a certain level of programming expertise, then you need to test for it. Regardless, you shouldn't be surprised that people can get through a curriculum without "getting" pointers completely.
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
My school apparently had one of the most esteemed and was among the first universities to offer a CS program. We had to write code on paper but aside from having to memorize the java shit for buffered readers and doing stuff with streams there was an understanding that it would for the most part not compile. So if you forgot braces or semi-colons sometimes they wouldn't really dock you for it... except for the first year classes where apparently the only takeaway you should have is where to put your punctuation .
I always thought it was bullshit because I like to approach writing a particular non-trivial component in baby steps, like get it working in a bare-bones sense, then get my functions returning *something*, then control structure and the real logic. That way when I catch myself doing something that wouldn't work with my original expectations of how it's all going to work I can make revisions to those expectation relatively inexpensively. This kind of approach isn't as feasible without any feedback whatsoever.
To echo bowen, that is, in fact, a very good way to attack a project.
To play a bit of devil's advocate, however, given a level of proficiency in coding, you should be able to write something and be fairly sure it will succeed without compiling it. For instance, I am confident in my ability to write a linked list from scratch, in full, without compiling or testing it. Of course I would still go and test it, if I actually ended up writing one, but if I asked you to write fizzbuzz and you told me you would need to utilize incremental development to complete it, I would definitely raise my eyebrows.
Apparently I lost 2 points on comments. 10 points on not submitting a file with my algorithm in it. But that's ok, because nobody did. The grader apparently didn't get the memo that he wasn't supposed to grade that bit because there was no algorithm for the first assignment.
Got my test score back too. 25/30.
Argued that up to 30/30 because he apparently misread my code in two places.
I'm constantly harassing my teacher about little shit like whether I've commented to her satisfaction before turning my assignments in. She always thinks I'm just being silly, but I tell her I know too many people who miss points because of minor stuff and I'm not going to lose points because I didn't comment something that's obvious to me but shouldn't be at the class' level and so she's expecting a comment or anything along those lines. Sometimes I also find it hard to judge if I've completely missed the point of the assignment by doing it my way that I'm not even supposed to know yet.
I've got my first CS test today. I'll be horribly embarrassed if I miss anything.
You are right to nitpick. I had a professor that you could go and do this with, and they would say its fine. You need to get a definition of "fine", because we would get shit back all the time with D's and C' on them after being told it was good to go and fine. Then we had to spend 2 hours a week arguing with the professor about every assignment to get the points back where they confirmed it was fine.
I remember taking a handwritten test, and I wrote a portion of code in a very K&R way:
while (*s++ = *t++) ;
Got a zero for that portion of the test, because the professor could not believe the code works.
Even though K&R's quintessential C book has examples like this all throughout.
Granted, the professor used a different C book....
I remember taking a handwritten test, and I wrote a portion of code in a very K&R way:
while (*s++ = *t++) ;
Got a zero for that portion of the test, because the professor could not believe the code works. Even thought K&R's quintessential C book has examples like this all throughout.
That looks like a pretty 'fuck you' way to do an array copy.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
I remember taking a handwritten test, and I wrote a portion of code in a very K&R way:
while (*s++ = *t++) ;
Got a zero for that portion of the test, because the professor could not believe the code works.
Even thought K&R's quintessential C book has examples like this all throughout.
Granted, the professor used a different C book....
There was a professor who did not know that syntax?
I remember taking a handwritten test, and I wrote a portion of code in a very K&R way:
while (*s++ = *t++) ;
Got a zero for that portion of the test, because the professor could not believe the code works. Even thought K&R's quintessential C book has examples like this all throughout.
That looks like a pretty 'fuck you' way to do an array copy.
I remember taking a handwritten test, and I wrote a portion of code in a very K&R way:
while (*s++ = *t++) ;
Got a zero for that portion of the test, because the professor could not believe the code works.
Even thought K&R's quintessential C book has examples like this all throughout.
Granted, the professor used a different C book....
There was a professor who did not know that syntax?
You'd be surprised at the ineptitude of some professors with respect to programming, or more generally, things that are not their area of expertise.
I remember taking a handwritten test, and I wrote a portion of code in a very K&R way:
while (*s++ = *t++) ;
Got a zero for that portion of the test, because the professor could not believe the code works.
Even thought K&R's quintessential C book has examples like this all throughout.
Granted, the professor used a different C book....
There was a professor who did not know that syntax?
You'd be surprised at the ineptitude of some professors with respect to programming, or more generally, things that are not their area of expertise.
I remember taking a handwritten test, and I wrote a portion of code in a very K&R way:
while (*s++ = *t++) ;
Got a zero for that portion of the test, because the professor could not believe the code works. Even thought K&R's quintessential C book has examples like this all throughout.
That looks like a pretty 'fuck you' way to do an array copy.
That is the canonical implementation of strcpy()
I figured as much. It definitely is an array copy, didn't know the specifics of how that loop plays out. I assume \0 causes it to break out?
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Yeah, the assignment effectively "returns" whatever the value being assigned is, so the while keeps evaluating true until it returns \0 which evaluates as false.
Yeah, the assignment effectively "returns" whatever the value being assigned is, so the while keeps evaluating true until it returns \0 which evaluates as false.
elegant because it still assigns that 0, which null terminates the string, as the last thing before it breaks out.
I figured as much. It definitely is an array copy, didn't know the specifics of how that loop plays out. I assume \0 causes it to break out?
Yeah, it's short hand for:
while (*t != 0) {
*s = *t;
s++;
t++;
}
*s = 0;
Reading K&R forces you to learn operator precedence, pointer arithmetic, how non-zero is treated as true, and how pre/post-increment really works. They don't come out and teach you this (well, maybe a page or two), they just write code this way, and expect you to figure it out.
Yeah, the assignment effectively "returns" whatever the value being assigned is, so the while keeps evaluating true until it returns \0 which evaluates as false.
elegant because it still assigns that 0, which null terminates the string, as the last thing before it breaks out.
I love elegant code. My coworkers just don't get it.
Posts
PHP and GCC give the most obtuse error messages sometimes.
Who handwrites code?
What is this, the 70s?
Our tests were either multiple choice or we typed up something, compiled, and gave them the source + executable.
on rare occasions that can be useful, but usually it just causes everything else to be misparsed after the first error
Every CS class I took while in school a few years ago had handwritten portions. Granted it wasn't full programs (most of the time) but it was still frustrating because in the real world you could debug and step through code.
Your school is worse than ITT, that's pretty bad!
'Worse' being in context there.
That sounds like a fun way to say, "completely worthless except for the subset of students who like to write neatly."
I guess that's still better than fizzbuzz though.
Challenge accepted! First, we need to understand that tests serve primarily as a metric of measuring student mastery of pre-determined learning goals and a forcing function for students to master those goals. So the question is, what learning goals are tested when a student writes code on paper?
(1) Writing code away from a computer tests mastery of language syntax. This is a fine learning goal for an introductory course but should not be a high-priority (if it is emphasized at all).
(2) Writing code away from a computer is itself a useful skill in the context of a job interview or in the workplace. Developers will need to talk about programs with other developers at various levels of detail and this will usually be away from a computer. Furthermore, it is a useful technique to avoid hammering on an IDE/compiler (see next bullet) and write down thoughts, ideas, and partial programs on paper away from a computer. Setting aside a time in the classroom to do this emphasized the importance of this skill.
(3) Finally, writing code on paper forces students to think critically about the code they are writing. While REPLs and quick compilation loops give instant feedback to the student which in turn helps accelerate their learning, students frequently fall into the trap of "hacking their way out of a hole" rather than taking a step back and critically thinking about the program they want to construct. Students need to develop a mental model of how their programs work which can be impeded by the availability of a tool that can (partially) do that work for them. Thus, offline work is essential to develop and test that they are correctly developing that model.
There are also pragmatics and legitimate concerns of academic dishonesty. If the course (in particular a large course) does not have access to a sufficiently large computer lab, then their only recourse may be a "traditional" test in a lecture hall on paper as the risk of cheating outside the classroom could be too high for their tastes.
Here's a blog post that goes into the pros and cons of written code on exams that was the result of a discussion on the sigcse mailing list:
http://frankmccown.blogspot.com/2013/05/hand-writing-code-on-exams.html
*All of this is predicated on the fact that the educator involved is cognizant of these issues. Many aren't, unfortunately.
Trial and error is an important way to learn, too, actually.
I disagree with the entire premise here, and since this is all 'opinion' the only way I'd be happy is if there's metrics presented.
I always thought it was bullshit because I like to approach writing a particular non-trivial component in baby steps, like get it working in a bare-bones sense, then get my functions returning *something*, then control structure and the real logic. That way when I catch myself doing something that wouldn't work with my original expectations of how it's all going to work I can make revisions to those expectation relatively inexpensively. This kind of approach isn't as feasible without any feedback whatsoever.
That is a sensible way to attack a project.
Writing code on paper doesn't teach skills, it teaches rote memorization of APIs and languages. That's not necessarily helpful and I'll keep my stance that hand writing code is ridiculous. You want to weed out whack-a-mole coders? Time the test. Whack-a-mole coders don't make it past data structures usually anyways. You either get pointers or you don't. There's no hack-method to get through them.
"There isn't enough space" and other issues of pragmatics are very legitimate reason that things are done the way that they are. You might not like them, but idealism aside, people have to work within the confines of what they are given and those are very, very frequently un-ideal conditions (in this context, too many students and not enough space).
Trial and error is an important way to learn how to code, but is is certainly not an ideal way to actually develop programs on a day-to-day basis. That's the distinction that I'm making, and it is a very important one as many students walk out of introductory programming classrooms without a mental model of computation, arguably the concept you want to impart on students.
Unfortunately, computer education research is not as quantitative as we would like although people are working hard at fixing that. So there aren't specific studies that I know of that test the merits of hand-writing code in the classroom. That being said, the points and the blog post above are drawn from my experience in the classroom and industry as well as the collective wisdom of experts in the field. It isn't conclusive evidence of anything, but it is a good guide when there is no quantitative evidence out there.
To those points:
(1) Good code-on-paper test questions specifically avoid points of API memorization and language minutiae as the blog post outlines. And as penguin pointed out, syntax is typically hand-waived in everything but intro classes (where syntax is a legitimate learning goal).
(2) Timing the test helps but is not a complete answer and is ultimately orthogonal to handwriting code-or-not.
(3) Banking on later courses for people to "weed themselves out" is just plain irresponsible. Just like in programming, you want students to fail early and fast so they can respond accordingly. If your course demands that they have a certain level of programming expertise, then you need to test for it. Regardless, you shouldn't be surprised that people can get through a curriculum without "getting" pointers completely.
To echo bowen, that is, in fact, a very good way to attack a project.
To play a bit of devil's advocate, however, given a level of proficiency in coding, you should be able to write something and be fairly sure it will succeed without compiling it. For instance, I am confident in my ability to write a linked list from scratch, in full, without compiling or testing it. Of course I would still go and test it, if I actually ended up writing one, but if I asked you to write fizzbuzz and you told me you would need to utilize incremental development to complete it, I would definitely raise my eyebrows.
You are right to nitpick. I had a professor that you could go and do this with, and they would say its fine. You need to get a definition of "fine", because we would get shit back all the time with D's and C' on them after being told it was good to go and fine. Then we had to spend 2 hours a week arguing with the professor about every assignment to get the points back where they confirmed it was fine.
It's actually awesome!
Even though K&R's quintessential C book has examples like this all throughout.
Granted, the professor used a different C book....
That looks like a pretty 'fuck you' way to do an array copy.
There was a professor who did not know that syntax?
That is the canonical implementation of strcpy()
You'd be surprised at the ineptitude of some professors with respect to programming, or more generally, things that are not their area of expertise.
Nah. That's why you don't take classes from bad professors (if you can help it; frequently you can't).
I would be less likely to be surprised than to be immensely saddened.
But I would probably still be surprised.
I figured as much. It definitely is an array copy, didn't know the specifics of how that loop plays out. I assume \0 causes it to break out?
elegant because it still assigns that 0, which null terminates the string, as the last thing before it breaks out.
while (*t != 0) { *s = *t; s++; t++; } *s = 0;Reading K&R forces you to learn operator precedence, pointer arithmetic, how non-zero is treated as true, and how pre/post-increment really works. They don't come out and teach you this (well, maybe a page or two), they just write code this way, and expect you to figure it out.I love elegant code. My coworkers just don't get it.
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.
Pft, but I want to corrupt the stack!