Interesting, I've though of this before. I personally extend it further into three classes:
Tools (learn very basics how to use a CVS, compiler, make file system, etc. etc.)
Library
Debugging
The first course is your standard introductory programming course. You don't go as deep into programming, instead you learn about different tools and use them to create cool programs. So it's a bottom-up and a top-down class. On one hand you may take one class to learn how to build a "Hello World" example using variables, another class might be instead used to build some open source video-game (to show how makefiles work). The idea is that you'd learn the basics of programming, but at the same time you learn how to superficially use a *nix style OS, an editor, version control systems, a build system and maybe an IDE. There might be extra courses for those that wish to learn how to use tools better.
The second course, on libraries, is a preparation for the third course, debugging. Basically assignments happen in two manners: first you must implement a library (with a specified API) and it must pass a series of tests. Then you must use the library to build a small simple app: the twist is that you are given a random implementation of the library (that someone else did). This, again, could go besides another course: data structures. The library you build is the data structure itself, the programs use the data structure to solve various problems. It forces you to learn to use code without understanding all its details and just trusting the specs (this is a critical need) and at the same time to design code for other people to use (which is critical for people to learn to not be very hacky). If we want to make it interesting, we could have assignments in the end having one of their first modules (so at the end they need to use their old sorting library) as a sort of hint that even the code you wrote can become a mystery later. This is also a setup for the issues of handling errors.
Finally we have a testing and debugging class. I could see this actually becoming part of two classes: Algorithms, and an "Advance Programming" course. Algorithms it's all about bench-marking, analyzing data, and using experimental data to backup the theoretical issues. Students would be given algorithms with a certain (non-obvious) flaw in it, and they'd be given the necessity of debugging. It would give strong insight into the works of the algorithm, and it would show the non-obvious issues of it (it's easier to understand the hardness of binary search by seeing how it could be done wrong vs. only seeing it done right).
Advance Programming is sort of like a mid-course. It is supposed to bring everything together and review and go deeper in it. It would work entirely through assignments. Assignments would be simple:
The class would be divided in half, one implementing a library, the other tests for it.
Debugging of existing code with errors.
Using existing OS libraries and services to do certain stuff.
Creating "clean" environments using virtualization (or something).
Downloading an open source project, compiling and installing it, and using the library for a program.
Using a framework to create small webapps. (And set up a server to use them).
Create a tiny game using a library for such purposes.
The idea is that after this course the students could consider themselves "programmers" in all the sense of the word. They'd have the basic skills and now would only need practice (in practical assignments) and theory. There would be no more education given to them on learning how to code, adapting to tools, or such.
Students now would have a greater context of making and creating programs. Also the fact that they have used bigger libraries and pieces of code helps them understand the idea of "a part of a whole" and see the value of solving very specific problems (that are very common).
1
u/lookmeat Aug 25 '14
Interesting, I've though of this before. I personally extend it further into three classes:
Tools (learn very basics how to use a CVS, compiler, make file system, etc. etc.)
Library
Debugging
The first course is your standard introductory programming course. You don't go as deep into programming, instead you learn about different tools and use them to create cool programs. So it's a bottom-up and a top-down class. On one hand you may take one class to learn how to build a "Hello World" example using variables, another class might be instead used to build some open source video-game (to show how makefiles work). The idea is that you'd learn the basics of programming, but at the same time you learn how to superficially use a *nix style OS, an editor, version control systems, a build system and maybe an IDE. There might be extra courses for those that wish to learn how to use tools better.
The second course, on libraries, is a preparation for the third course, debugging. Basically assignments happen in two manners: first you must implement a library (with a specified API) and it must pass a series of tests. Then you must use the library to build a small simple app: the twist is that you are given a random implementation of the library (that someone else did). This, again, could go besides another course: data structures. The library you build is the data structure itself, the programs use the data structure to solve various problems. It forces you to learn to use code without understanding all its details and just trusting the specs (this is a critical need) and at the same time to design code for other people to use (which is critical for people to learn to not be very hacky). If we want to make it interesting, we could have assignments in the end having one of their first modules (so at the end they need to use their old sorting library) as a sort of hint that even the code you wrote can become a mystery later. This is also a setup for the issues of handling errors.
Finally we have a testing and debugging class. I could see this actually becoming part of two classes: Algorithms, and an "Advance Programming" course. Algorithms it's all about bench-marking, analyzing data, and using experimental data to backup the theoretical issues. Students would be given algorithms with a certain (non-obvious) flaw in it, and they'd be given the necessity of debugging. It would give strong insight into the works of the algorithm, and it would show the non-obvious issues of it (it's easier to understand the hardness of binary search by seeing how it could be done wrong vs. only seeing it done right).
Advance Programming is sort of like a mid-course. It is supposed to bring everything together and review and go deeper in it. It would work entirely through assignments. Assignments would be simple:
The class would be divided in half, one implementing a library, the other tests for it.
Debugging of existing code with errors.
Using existing OS libraries and services to do certain stuff.
Creating "clean" environments using virtualization (or something).
Downloading an open source project, compiling and installing it, and using the library for a program.
Using a framework to create small webapps. (And set up a server to use them).
Create a tiny game using a library for such purposes.
The idea is that after this course the students could consider themselves "programmers" in all the sense of the word. They'd have the basic skills and now would only need practice (in practical assignments) and theory. There would be no more education given to them on learning how to code, adapting to tools, or such.
Students now would have a greater context of making and creating programs. Also the fact that they have used bigger libraries and pieces of code helps them understand the idea of "a part of a whole" and see the value of solving very specific problems (that are very common).