Tom asked for a "layman's" explanation of the "expression" problem. In a nutshell: You can think of a large program as being comprised of new datatypes, and functions that operate on those datatypes.  As a programmer, maintaining and extending an existing program, you typically want to do one of two things: 1.  Add a new function that applies to the datatypes in your program. 2.  Add a new datatype that can be manipulated by the functions in your program. The goal is to add these new elements without having to rewrite your well-tested programming components that have already been developed. At the risk of oversimplifiying, functional programming makes it relatively easy to add new functions without modifying the other components of your program (but if you add a new datatype, you have to modify existing code by adding a new "cond" branch to all your functions that need to operate on this datatype). On the other hand, object-oriented programming makes it relatively easy to add new datatypes (aka objects) without modifying the other components of your program (but to add a new function, you have to edit the source of your existing objects to add a new "method" to those objects that will need to be able to handle this new functionality). One of the grand challenges of programming language design is to create a programming language that makes it equally easy to do both.  This is called the expression problem. In my view, this problem has been most satisfactorily solved by "multiple-dispatch" (aka multimethod) object-oriented languages (like Dylan, inspired by CLOS), but for various reasons, this solution hasn't really caught on.  But the quest to solve this problem is why many OO languages are being stretched to incorporate elements of functional programming, and vice versa. The PLT folks have used the expression problem as a springboard for thinking about big issues like, what does it mean to be a software component, and what are appropriate ways for reusing and extending a software component. --Mark