2 Fixed spelling and grammar
source | link

Maybe some complementary points to what as already been said (as a CS assistant professor, giving both theoretical and practical courses).

  • Even for practical courses (those which involve coding), writing code on paper is good. The point is not to fill your page with boilerplate code (and I cannot stress that enough). Writing sequence of Java imports or mystical incantations to setup say a Map/Reduce transformation in Hadoop on paper makes absolutely zero sense. However, being able to write correct application logic and being aware of implementation aspects (some object can actually be null, problems with side-effects...) is a must. The hard part (which is actually an art I have not fully mastered yet), is to make exams that tests theses aspects without the noise and being of course lenient about small syntactic mistakes (missing ; capitalisationcapitalization and so on). At some level, what I want to test is this: "Here is a problem (from which I have abstracted the noise for you). Can you solve it with programming, without having to compile it 10 times until there are no more syntax/type errors and without running it a 100 times with printfs all around to see why this does not work ?". Because if the student can do that, then I know (s)he will be able to take it to the next step and generalize it to harder problems or use it in other contexts. If a student takes whatever is in the lecture notes, paste it in an IDE and fiddle with it until it somehow works, I cannot make the same guarantyguarantee. Also, you cannot copy/paste on paper, which forces you to think about your code and write it in a terser manner. I have to initialiseinitialize an array. Ok I'll write a loop rather than cut/and paste 25 lines and change each one.

  • Conversely, even for theoretical classes (complexity/calculability, type-systems, logic , ...), I think it is good to have a bit of coding. Write a lambda calculus interpreter. A small (even naive) SMT solver. Code several sorting algorithms and try to see what constants are hidden inside your big O. Is the impact of sorting in place noticeable w.r.t.without resorting to having to copy your data  ? In highly advanced courses (in particular type systems and logic) you only really see what's going on when you can test large examples. And penPen and paper only take you so far.

Maybe some complementary points to what as already been said (as a CS assistant professor, giving both theoretical and practical courses).

  • Even for practical courses (those which involve coding), writing code on paper is good. The point is not to fill your page with boilerplate code (and I cannot stress that enough). Writing sequence of Java imports or mystical incantations to setup say a Map/Reduce transformation in Hadoop on paper makes absolutely zero sense. However, being able to write correct application logic and being aware of implementation aspects (some object can actually be null, problems with side-effects...) is a must. The hard part (which is actually an art I have not fully mastered yet), is to make exams that tests theses aspects without the noise and being of course lenient about small syntactic mistakes (missing ; capitalisation and so on). At some level, what I want to test is this: "Here is a problem (from which I have abstracted the noise for you). Can you solve it with programming, without having to compile it 10 times until there are no more syntax/type errors and without running it a 100 times with printfs all around to see why this does not work ?". Because if the student can do that, then I know (s)he will be able to take it to the next step and generalize it to harder problems or use it in other contexts. If a student takes whatever is in the lecture notes, paste it in an IDE and fiddle with it until it somehow works, I cannot make the same guaranty. Also, you cannot copy/paste on paper, which forces you to think about your code and write it in a terser manner. I have to initialise an array. Ok I'll write a loop rather than cut/and paste 25 lines and change each one.

  • Conversely, even for theoretical classes (complexity/calculability, type-systems, logic , ...), I think it is good to have a bit of coding. Write a lambda calculus interpreter. A small (even naive) SMT solver. Code several sorting algorithms and try to see what constants are hidden inside your big O. Is the impact of sorting in place noticeable w.r.t. to having to copy your data  ? In highly advanced courses (in particular type systems and logic) you only really see what's going on when you can test large examples. And pen and paper only take you so far.

Maybe some complementary points to what as already been said (as a CS assistant professor, giving both theoretical and practical courses).

  • Even for practical courses (those which involve coding), writing code on paper is good. The point is not to fill your page with boilerplate code (and I cannot stress that enough). Writing sequence of Java imports or mystical incantations to setup say a Map/Reduce transformation in Hadoop on paper makes absolutely zero sense. However, being able to write correct application logic and being aware of implementation aspects (some object can actually be null, problems with side-effects...) is a must. The hard part (which is actually an art I have not fully mastered yet), is to make exams that tests theses aspects without the noise and being of course lenient about small syntactic mistakes (missing ; capitalization and so on). At some level, what I want to test is this: "Here is a problem (from which I have abstracted the noise for you). Can you solve it with programming, without having to compile it 10 times until there are no more syntax/type errors and without running it a 100 times with printfs all around to see why this does not work ?". Because if the student can do that, then I know (s)he will be able to take it to the next step and generalize it to harder problems or use it in other contexts. If a student takes whatever is in the lecture notes, paste it in an IDE and fiddle with it until it somehow works, I cannot make the same guarantee. Also, you cannot copy/paste on paper, which forces you to think about your code and write it in a terser manner. I have to initialize an array. Ok I'll write a loop rather than cut/and paste 25 lines and change each one.

  • Conversely, even for theoretical classes (complexity/calculability, type-systems, logic , ...), I think it is good to have a bit of coding. Write a lambda calculus interpreter. A small (even naive) SMT solver. Code several sorting algorithms and try to see what constants are hidden inside your big O. Is the impact of sorting in place noticeable without resorting to having to copy your data? In highly advanced courses (in particular type systems and logic) you only really see what's going on when you can test large examples. Pen and paper only take you so far.

1
source | link

Maybe some complementary points to what as already been said (as a CS assistant professor, giving both theoretical and practical courses).

  • Even for practical courses (those which involve coding), writing code on paper is good. The point is not to fill your page with boilerplate code (and I cannot stress that enough). Writing sequence of Java imports or mystical incantations to setup say a Map/Reduce transformation in Hadoop on paper makes absolutely zero sense. However, being able to write correct application logic and being aware of implementation aspects (some object can actually be null, problems with side-effects...) is a must. The hard part (which is actually an art I have not fully mastered yet), is to make exams that tests theses aspects without the noise and being of course lenient about small syntactic mistakes (missing ; capitalisation and so on). At some level, what I want to test is this: "Here is a problem (from which I have abstracted the noise for you). Can you solve it with programming, without having to compile it 10 times until there are no more syntax/type errors and without running it a 100 times with printfs all around to see why this does not work ?". Because if the student can do that, then I know (s)he will be able to take it to the next step and generalize it to harder problems or use it in other contexts. If a student takes whatever is in the lecture notes, paste it in an IDE and fiddle with it until it somehow works, I cannot make the same guaranty. Also, you cannot copy/paste on paper, which forces you to think about your code and write it in a terser manner. I have to initialise an array. Ok I'll write a loop rather than cut/and paste 25 lines and change each one.

  • Conversely, even for theoretical classes (complexity/calculability, type-systems, logic , ...), I think it is good to have a bit of coding. Write a lambda calculus interpreter. A small (even naive) SMT solver. Code several sorting algorithms and try to see what constants are hidden inside your big O. Is the impact of sorting in place noticeable w.r.t. to having to copy your data ? In highly advanced courses (in particular type systems and logic) you only really see what's going on when you can test large examples. And pen and paper only take you so far.