thraxil.org:

designing a high school computer science curriculum

by anders pearson Thu 08 Sep 2005 01:25:11

recently, a friend of mine got a job as the head of the CS department (a one person department so that means he also teaches all the CS classes) in a private high school and is faced with the challenge of redesigning their curriculum. he's been teaching CS courses at the college level for a few years now but hasn't taught high school before or designed a full curriculum. he came to "Eric":http://www.ericmattes.com/ and i for ideas. the school is a typical 4-year high school. CS is an elective there, so one of his goals is to keep things interesting and fun enough that students will actually sign up for the classes. i don't have an educational background, but i have a surplus of opinions about how CS should be taught, so i thought about the problem a while and came up with a rough outline of a curriculum myself. i'm posting it here to see what sort of opinions others have about CS education and how programming should be taught. first of all, i think it's important to consider the different types of CS students and what they may get out of a program. at one end, you have the hardcore computer geek kids. they're already interested in computers and won't need much encouragement; just let them loose and provide them with as much info as they can take. someone without the ability to learn and explore on their own just won't make it far in programming. a good program for these kids will just accelerate the process for them. it should also ensure that if they pursue CS in college, that they'll be well prepared. at the other end are kids who have no real desire to ever be a programmer or even do anything close to math or hard sciences. i happen to think that learning programming still has a lot of value for them. not just because computers have invaded every aspect of modern life and knowing how to subjugate them to your will is becoming a more general useful skill. science and math are valued parts of a liberal arts education because of mental skills that they are supposed to impart to the student: thinking precisely, logical problem solving, breaking a problem down into smaller, solvable sub-problems, the habit of creating testable hypothesis to understand new phenomenon, etc. programming can offer all that but in a very concrete and direct fashion. having a computer that does *exactly* what you tell it to can be very humbling and make you realize that quite often you don't really understand what you're telling it. i've learned from years of programming that unless i can write a program expressing some concept, i probably don't fully understand it. you just can't bullshit your way past a compiler. if they're lucky, beyond picking up those fancy liberal arts sort of values, they'll also gain an appreciation for computers as tools to eliminate repetition. that's largely what they are to me. if you have a computer and you know how to teach it to do things for you, there's no good reason to ever do a boring or time-consuming task twice. being comfortable getting a computer to automate stuff for you is useful in just about any field. unfortunately, though, most CS curriculums i've seen seem almost purposefully designed to drive students away from programming. starting out with such exciting topics as binary and hexadecimal numbers, fibonacci sequences, and factorials. after learning a bunch of meaningless theory, students are then introduced to the exciting world of writing programs that spit out some text or numbers to a console. probably in a language like Java that requires them to understand object oriented programming, static methods, and classpaths just to make sense of a "hello world" program. the lesson to students is clear: programming is arcane, complicated, and boring. the overall goal of the curriculum, then, is to cover as much of that spectrum as possible and avoid scaring them off too early. the obvious approach is to take advantage of the fact that only the relatively hardcore kids are going to stick with it for all four years. so the program starts off gently and tries to get in as many of the basic concepts as possible without causing too much pain and eventually progresses to the more nitty-gritty stuff that's really only going to help the future programmers in the class. h3. year 1 h4. goals: don't scare too many students. cultivate interest. develop understanding of basic computer programming concepts and problem solving techniques. precision, breaking down problems, methodical approach to debugging, etc. h4. curriculum: robotics (probably Lego Mindstorms or similar). fun for the students, makes things very hands on, allows for programming to be introduced in a very concrete manner ("hello world" programs that print stuff on a computer screen are boring. making a real physical thing that moves around and does stuff is much more satisfying.). introduce basic concepts of programming as needed: conditionals, loops, variables, subroutines. follow up each with concrete exercises. heavy focus on problem solving aspects, debugging, and incremental design. avoid too much abstraction. possibly spend some time (towards the end) on stuff like Word Macros, spreadsheets, applescript, etc focusing on how they can let you automate away boring, repetitive tasks. h3. year 2 h4. goals: develop more advanced skills and understanding. build toolset for developing real applications. h4. curriculum: taught in python, scheme, ruby, haskell, etc. something high level with relatively simple syntax, a REPL(Read Eval Print Loop), and built-in simple data structures. emphasis on use of data structures rather than how to build them. basic development process: editor, shell, interpreter, libraries, tools. simple OOP(Object Oriented Programming) concepts. simple algorithms, focusing on graphics rather than math. continued focus on practical scripting and automation; this time just with better, more general tools (python + unix shell rather than Word macros). h3. year 3 h4. goals: advanced programming concepts, databases, web, low level programming. prepare for project work. h4. curriculum: more data structures and algorithms. introduce lower level programming and hardware understanding. memory, process execution, stacks and function calls. work with a processor simulator for a short unit on basic assembly language (simulate a simpler processor than x86. maybe Z80 or MIPS). move to C and focus on pointers and memory management (should be much more concrete after working in assembly). linked lists and trees and their construction in C using pointers. database concepts and SQL. how to access from python (or ruby, etc.), database schema design. intro to web technologies: HTTP, HTML, CSS, work with a simple web server. h3. year 4 h4. goals: project work. get more depth into a particular area. experience building something non-trivial. software engineering, managing complexity, usability, etc. h4. curriculum: student driven. most time spent on individual or group projects. students write project proposals, then develop them. occasional lectures on advanced topics related to student projects, but mostly time is spent on projects. perhaps a short unit or two on some other languages like Java (which they're bound to run into in college, lisp, smalltalk, prolog, etc.)