A framework, much like its name implies, provides a reusable design for part of or an entire program. Frameworks are generally more abstract, since they have to be molded to each specific situation that they're used for. A framework is documented with smaller patterns that are used to deal with smaller parts of a larger program. Each pattern builds off the one before it, and by providing patterns with a framework, someone can write a program to deal with something that they might not even understand.

The premise of a framework sounds like a very good idea. Providing a rather flexible design for a progam would greatly help those people new to CS who are still learning how to design. Patterns are also helpful in that they teach people how to solve one type of problem, as oppose to one specific problem. Design patterns are also imperative, things like the factory, proxy, and state patterns show up everywhere. The combination of a framework and patterns could be useful in an introductory course.

For the first few assignments in CS015, students were basically given a framework. All the magic was hidden from their eyes, and the design for the program was thoroughly covered at the help sessions. Having these things explained in detail was very helpful for the first few programs, but after that I think its imperative that students learn how to design themselves. For the more complex programs, support code rightly replaces a framework. Always giving students a design and tools to work with, in addition to the basic "magic" that intro students would have a tough time implementing, would teach them to rely too heavily on being given the bulk of their work. It is important that students learn how to attack a problem, how to apply patterns that they've seen before, and how to deal with new problems.

In thinking about patterns, I couldn't help but think about design patterns. Design patterns are a very important part of CS because they provide an elegant solution to very common problems. In the same manner that a pattern in a framework deals with one aspect of the program, a design pattern takes care of one part of the design. It is hard to teach the value of design patterns to students who might only use the pattern once. It would be much more beneficial if design patterns could be written apart from larger programs, and then simply implemented when needed. Suppose students had to create a more generic factory pattern before Swarm. This factory pattern could be implemented in both Swarm and Tetris. By showing how design patterns and code can actually be reused would help to demonstrate their importance.

You make a good point about design patterns. As Andy has said in lecture, there are books of design patterns that are meant to provide generic solutions to common coding problems. You can then take the generic and modify it to suit the individual programs needs, but it will still essentially be the pattern mentioned in the book. Factory is a good example, as is the visitor pattern that we used in Orbit; or perhaps the proxy/holder idea. All are generic patterns that most programmers with experience might recognize, and therefore understand at least that part of your program.