The biggest utility of Scheme for introductory programming is the same utility that you get from any functional language, really: referential transparency. Tr

The biggest utility of Scheme for introductory programming is the same utility that you get from any functional language, really: referential transparency. Transparency enables what SICP calls the "substitution model" of evaluation and application. The nice thing about that, in regards to pedagogy at least, is that it permits programmers to approach evaluation as a simple algebraic term-reduction system. Sit and evaluate an expression by substitution (there's only a handful of rules), and the similarity to solving and reducing algebraic equations will be obvious. This means that students can leverage the existing intuition they've developed for elementary algebra to quickly grok evaluation. Of course, once side-effects are introduced, that substitution model breaks down, and a new one must be picked up. But by then, the students ought to have become reasonably comfortable with the ideas of programming. I often hear smug Lisp weenies bragging about how simple the syntax is , which allows instructors to spend little time on syntactic rules and get at the meat of programming. But I'd argue that the simplicity of the semantics in the absence of side-effects is even more important. Any student with an eighth-grade[1] understanding of elementary algebra will be able to understand program evaluation quickly and easily. As to why Lisp specifically when any referentially transparent language or sublanguage thereof could provide the benefits of the substitution model just as well: try implementing a complete and fully-functional metacircular interpreter in something other than Lisp, as a literate program, in under 40 pages. Now do it again for a lazy version, a nondeterministic version, and a relational (a.k.a. logical, as in logic programming, e.g. Prolog) version. Some argue that a metacircular evaluator really has no business being part of an introductory course, but in my experience it's actually a good way to finally formalize the actual model of evaluation, while at the same time demonstrating that interpreters, compilers, etc. aren't magic black boxes, but actually relatively simple programs (though when I teach the material I like to point out that they can get pretty complex, depending on source/object languages and optimization... let that be a lesson to them!). [1]: This is the name for the educational status of typical twelve-to-thirteen-year-old students in the US.