Aug 15, 2010
Every few months I encounter people who harbor deep misunderstandings about the TeachScheme! curriculum. I cannot eliminate these misunderstandings in a single conversation, but I can at least spell them out and address them here. I did so with a Little LISPer style dialog, though it can also be read as a FAQ list.
(Note: My dialog supplements and does not compete or conflict with the section on frequently asked questions at our TeachScheme! site.)
Q: Is TeachScheme! about Scheme?
A: No, TeachScheme! is about the systematic design of programs from the very beginning, regardless of programming language.
Q: So why do you use Scheme?
A: We don’t. The "!" signals not, because we really do not use Scheme. We also don’t use Racket, our own language, which is a flavor of LISP and Scheme.
Q: What do you use?
A: We use a series of teaching languages, with each successor a bit more expressive than its predecessor. These teaching languages borrow elements from Racket, a member of the LISP family of languages. That’s why our programs use all these parentheses.
Q: Is the TeachScheme! idea of design really useful in all kinds of programming languages?
A: Yes, it is. Over the years, I have had students who applied the design
recipe and the design guidelines in all kinds of languages: assembly,
Python, Perl, Ruby, and Java. Indeed, I know instructors for each of these
languages who adopted the design recipe for their languages—
Q: Okay, so TeachScheme! isn’t about Scheme. Is it about functional programming?
A: No, TeachScheme! is about the systematic design of all kinds of programs. That includes object-oriented and imperative programs.
Q: Why are most of the early programs in a functional style?
A: We consider the functional style of programming the best starting point for two reasons. To start with, our decision is based on many years of experience with designing large systems in assembly, Pascal, C, and with teaching in similar languages. Functional programming is easier than anything else. Most importantly, functional programming focuses programmers on values, the fact that every function should produce a value, and that this value can be tested for correctness.
Q: And the second reason?
A: We really do consider the functional style of programming the proper starting point in middle school and high school. When you teach programming there, a functional approach has numerous, beneficial side effects. In middle school, it reinforces algebra and clarifies that you can create animations, games, and all kinds of fun and relevant products with algebra, not just calculate when trains leaving Pittsburgh and Philadelphia meet and crash. In high school, functional programming is in a symbiosis with trigonometry and geometry; with (pre)calculus and logic; and even with sciences that use mathematical models (physics, economics).
Q: Should everyone use functional programming for all projects?
A: No way! We are not functional ideologues; Racket—
Q: But the imperative-iterative style is so common. Why shouldn’t we show novices the most common style?
A: Our experience shows that a prior understanding of functional style produces significantly stronger programmers than an immediate immersion into the OOP monoculture.
Q: Couldn’t this just mean that a good programmer must have studied several different languages?
A: That’s precisely what it means. Some universities, e.g., CMU and Harvard, swap the order. They teach conventional programming first and use an HtDP-like approach for the second course. The key is, however, that the students produce more than a dozen or two dozen lines of code in either style; they produce large programs in both.
Q: Aren’t your students at a disadvantage when it comes to internships?
A: Yes and no. Yes, because we consider it a bad thing to send students into the real world with one course in programming under their belt. What would you say if your pharmacist hired a student after a single semester of chemistry?
Q: And no?
A: No, because my experience at Northeastern—
See TeachScheme! and co-op for a summary of Northeastern’s experience with introducing the TeachScheme! curriculum and its coop program.
To really understand why these prejudices—