Functional Programming and the ACM Curriculum

In May 2008, ACM SIGPLAN organized a workshop on Undergraduate Programming Language Curricula. One of the outcomes of this workshop was a proposal to put functional programming in the ACM core curriculum. This was Stuart Reges's brainchild, and Matthias Felleisen and I worked with him on it. We were very pleased to accomplish this in a “zero footprint” fashion.

Of course, this has earned a little (but surprisingly little) sniping from the vasty deep that is the Internet. Stuart and I wrote some prose not only explaining how we planned to accomplish the zero-footprint but, even more importantly, why this material belongs there. It should be useful reading for people who are stuck in the old-fashioned trap of “paradigms” (more on that later).

Because I don't know what will happen to this prose when it's incorporated into the final report from the workshop, I'm posting the original version of it here. If you're stuck in a discussion about this change, feel free to refer to this.

NB: This is co-authored with Stuart Reges, and inspired by some text from Larry Snyder, who both seem to have more sense than to have blogs of their own.

---

Rationale for the Change to the CS2001 Curriculum

The proposed change has the following structure:

Knowledge Unit                       Current Proposed
-----------------------------------------------------
PF4  Recursion                           5       2
PF5  Event-driven programming            4       2

PL1  Overview of PL                      2       0
PL2  Virtual Machines                    1       0
PL3  Language Translation                2       0
PL6  Object-oriented programming        10      10
PL7  Functional Programming              0      10
                                        --      --
     Total                              24      24

The changes have two key design goals:

1. To make the functional programming unit (FP), currently listed as PL7 in the curriculum, required rather than optional.
2. To account for this change in a "budget-neutral" way.

First we describe the high-level motivation for this change.

• Functional programming is not merely about a change in syntax; rather, it forces students to approach problems in a novel way. This increases their mental agility and prepares students for a life of practice in a world where languages continuously grow, morph, and sometimes shift their perspective. This is not just the academic community speaking: this advice comes from influential industrial practitioners including Joel Spolsky, Steve Yegge, Paul Graham, Eric Raymond, and Peter Norvig, who have all written vocally about it.
• The growth and change of languages, and the influence of functional programming, is not hypothetical. Virtually every significant mainstream language that has been designed, has gained prominence, or has been improved in the past decade, from JavaScript to Ruby to Java to C# to Visual Basic, incorporates notable features that used to be associated with functional programming. Datacenter programming techniques such as MapReduce grow directly out of functional programming. Microsoft has championed the use of functional constructs like closures in the .NET framework as the best way to express database and XML queries. The rise of multicore architectures is imposing new pressures on programmers to avoid the use of shared state whenever possible. Learning functional programming takes students directly to the source, without the overhead and pain of sometimes unwieldy encodings of these ideas.
• By exposing students to multiple languages before they graduate, we make a strong statement about what they can expect to see in practice. History shows that the dominant programming language changes roughly every seven years, and over two or three of these changes little stays the same other than syntax. Furthermore, modern systems are rarely built in a single language alone; developers find it advantageous, and sometimes necessary, to use a combination of languages of widely different styles. Therefore, exposing students to a variety of styles is an essential part of their education.

Below we discuss the rationale for changes to specific knowledge units.

• The topics in PF4 (Recursion) and PF5 (Event-driven programming) lend themselves naturally to coverage in both object-oriented and functional programming. Functional programming has traditionally made paradigmatic use of recursion, while the callbacks that guide event-driven programming are a natural fit when discussing closures. Furthermore, by seeing these topics in both contexts, students will be in a better position to compare and contrast their expression in different styles.
• The topics in PL1 (Overview of programming languages), PL2 (Virtual machines) and PL3 (Language translation) are important topics, but we find it difficult to say much of use within this little time. The result is an enumeration of jargon without any deep study of concepts. Students will be better served by a substantial exposure to a functional language that serves as a contrast to whatever object-oriented language they will also learn. This experience of learning two different languages is more important than a superficial coverage of these other PL topics.
• One of our major goals is to bring parity between the number of hours devoted to PL6 (Object-oriented programming) and PL7 (Functional programming) by requiring a substantial experience with each approach.

It is worth noting that the proposal is neutral about implementation. Some schools will choose to incorporate functional programming into their introductory sequence. Other schools might include it in an advanced programming course or a discrete structures course. And other schools will fit this into a required programming languages course.