Where it stems from is, of course, because the lab is not the thing that the instructors want solved. After all, the lab problem is not an unsolved problem, and it will only be unique (if at all) in some surface way. This is the source of the feeling that people have that the restrictions are unreasonable: they feel like solving the lab is somehow the purpose of the assignment, and therefore any high quality solution is to be praised.

So if solving the problem isn't the deeper purpose of a lab, then what is? Typically, we are teaching an algorithm or a data structure. The lab is conjured as something that lends itself to that algorithm or data structure, and that is the goal of the instruction. I want to engender mastery of linked lists, or stack management, or two-dimensional arrays, or memory management, or... whatever the focus is.

The lab problem itself is entirely secondary, even if it does not in any way feel like this to the student. The lab problem is simply meant to provide a rich environment to play around with the learning target, and to gain some measure of experience wrestling with it.

The problem that we run into, then, is that there is no problem that cannot be solved in many ways. I can search as hard as I might for a problem that would be much, much harder to solve in a manner perpendicular to the purpose of the lab, and sometimes I will have some success. But sometimes I will not, because sometimes no such problem exists.

There exists no problem that can be solved with a linked list that cannot also be solved with an arraylist. I could provide starter code to try to force my approach, but that simultaneously increases the difficulty of creating the lab while decreasing the thought that must go into solving it.

A blanked ban, such as "you may use no bang operators in your Racket lab" is an imperfect solution, but all of the solutions are imperfect, and sometimes a ban feels like the least of the evils.

This is not a blanket defense; such bans can be careless, or needless, or clumsily done. I try hard to avoid them in my own instruction, but I don't always succeed. If it seems unfair to restrict my students' approach, it is also unfair to my students if they don't delve far enough into the course material because they originally thought of a different solution, and they just stuck with it. That cheats them of the chance to learn the material in the course, which they may well need in their next course, or later on in their life.

Where it stems from is, of course, because the lab is not the thing that the instructors want solved. After all, the posed lab problem is not unsolved, and your solution will only be unique (if at all) in some surface way. This is the source of the feeling that people have that the restrictions are unreasonable: they feel like solving the lab is somehow the purpose of the assignment, and therefore any high quality solution is to be praised. But, of course, that's not the point at all.

So if solving the problem isn't the deeper purpose of a lab, then what is? Typically, we are teaching an algorithm, a language feature, a data structure, or some other mental model of how something works. The lab is conjured as something that lends itself to that problem, and that is the goal of the instruction. I want to engender mastery of linked lists, or stack management, or two-dimensional arrays, or memory management, or... whatever the focus is.

The lab problem itself is entirely secondary, even if it does not in any way feel like this to the student. The problem posed to students is simply meant to provide a rich environment to play around with the learning target, and to gain some measure of experience wrestling with it.

The problem that we run into, then, is that there is no problem that cannot be solved in many ways. I can search as hard as I might for a problem that would be much, much harder to solve in a manner perpendicular to the purpose of the lab, and sometimes I will have some success. But sometimes I will not, because sometimes no such problem exists.

There exists no problem that can be solved with a linked list that cannot also be solved with an arraylist. I could provide starter code to try to force my approach, but that simultaneously increases the difficulty of creating the lab while decreasing the thought that must go into solving it.

A blanked ban, such as "you may use no bang operators in your Racket lab" is an imperfect solution, but all of the solutions are imperfect, and sometimes a ban feels like the least of the evils.

This is not a blanket defense; such bans can be careless, or needless, or clumsily done. I try hard to avoid them in my own instruction, but I don't always succeed. If it seems unfair to restrict my students' approach, it is also unfair to my students if they don't delve far enough into the course material because they originally thought of a different solution, and they just stuck with it. That keeps them on their own familiar territory and cheats them of the chance to learn the material in the course, which they may well need in their next course, or later on in their life.

Where it stems from is, of course, because the lab is not the thing that the instructors want solved. After all, the lab problem is not an unsolved problem, and it will only be unique (if at all) in some surface way. This is the source of the feeling that people have that the restrictions are unreasonable: they feel like solving the lab is somehow the purpose of the assignment, and therefore any high quality solution is to be praised.

So if solving the problem isn't the deeper purpose of a lab, then what is? Typically, we are teaching an algorithm or a data structure. The lab is conjured as something that lends itself to that algorithm or data structure, and that is the goal of the instruction. I want to engender mastery of linked lists, or stack management, or two-dimensional arrays, or memory management, or... whatever the focus is.

The lab problem itself is entirely secondary, even if it does not in any way feel like this to the student. The lab problem is simply meant to provide a rich environment to play around with the learning target, and to gain some measure of experience wrestling with it.

The problem that we run into, then, is that there is no problem that cannot be solved in many ways. I can search as hard as I might for a problem that would be much, much harder to solve in a manner perpendicular to the purpose of the lab, and sometimes I will have some success. But sometimes I will not, because sometimes no such problem exists.

There exists no problem that can be solved with a linked list that cannot also be solved with an arraylist. I could provide starter code to try to force my approach, but that simultaneously increases the difficulty of creating the lab while decreasing the thought that must go into starting it.

A blanked ban, such as "you may use no bang operators in your Racket lab" is an imperfect solution, but all of the solutions are imperfect, and sometimes a ban feels like the least of the evils.

This is not a blanket defense; such band can be careless, or needless, or clumsily done. I try hard to avoid them in my own instruction, but I don't always succeed. If it seems unfair to restrict my students' approach, it is also unfair to my students if they don't delve far enough into the course material because they originally thought of a different solution, and they just stuck with it. That cheats them of the chance to learn the material in the course, which they may well need in their next course, or later on in their life.

Where it stems from is, of course, because the lab is not the thing that the instructors want solved. After all, the lab problem is not an unsolved problem, and it will only be unique (if at all) in some surface way. This is the source of the feeling that people have that the restrictions are unreasonable: they feel like solving the lab is somehow the purpose of the assignment, and therefore any high quality solution is to be praised.

So if solving the problem isn't the deeper purpose of a lab, then what is? Typically, we are teaching an algorithm or a data structure. The lab is conjured as something that lends itself to that algorithm or data structure, and that is the goal of the instruction. I want to engender mastery of linked lists, or stack management, or two-dimensional arrays, or memory management, or... whatever the focus is.

The lab problem itself is entirely secondary, even if it does not in any way feel like this to the student. The lab problem is simply meant to provide a rich environment to play around with the learning target, and to gain some measure of experience wrestling with it.

The problem that we run into, then, is that there is no problem that cannot be solved in many ways. I can search as hard as I might for a problem that would be much, much harder to solve in a manner perpendicular to the purpose of the lab, and sometimes I will have some success. But sometimes I will not, because sometimes no such problem exists.

There exists no problem that can be solved with a linked list that cannot also be solved with an arraylist. I could provide starter code to try to force my approach, but that simultaneously increases the difficulty of creating the lab while decreasing the thought that must go into solving it.

A blanked ban, such as "you may use no bang operators in your Racket lab" is an imperfect solution, but all of the solutions are imperfect, and sometimes a ban feels like the least of the evils.

This is not a blanket defense; such bans can be careless, or needless, or clumsily done. I try hard to avoid them in my own instruction, but I don't always succeed. If it seems unfair to restrict my students' approach, it is also unfair to my students if they don't delve far enough into the course material because they originally thought of a different solution, and they just stuck with it. That cheats them of the chance to learn the material in the course, which they may well need in their next course, or later on in their life.