SIGPLAN Proposal

From CS2001 Wiki

Jump to: navigation, search

On May 28-29, 2008 SIGPLan held a workshop on Programming Languages in the Curriculum at Harvard.

The meeting addressed the widely perceived (among attendees, at least) problem that the topic Programming Languages was too lightly covered in the CC2001-CS Curriculum. Though a wide variety of remedies and revisions were discussed (and will likely be proposed in the future), one immediate revision suggestion was unanimously agreed upon. It is a change in the Core Knowledge areas of CS that has the attractive property of being “budget-neutral”, that is, it doesn’t change the total hours of core material.


It is proposed to add Functional Programming (FP) to the core curriculum topics. This change can be accomplished by the following budget-neutral change to CC2001-CS as follows:

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
Toyal 24 24

Rationale for Adding Functional Programming

Functional Programming, the programming language topic PL7 in CC2001-CS, has the following specification:

PL7. Functional programming


  • Overview and motivation of functional languages
  • Recursion over lists, natural numbers, trees, and other recursively-defined data
  • Pragmatics (debugging by divide and conquer; persistency of data structures)
  • Amortized efficiency for functional data structures
  • Closures and uses of functions as data (infinite sets, streams)

Learning objectives:

  1. Outline the strengths and weaknesses of the functional programming paradigm.
  2. Design, code, test, and debug programs using the functional paradigm.
  3. Explain the use of functions as data, including the concept of closures.

Though the content is unquestionably useful, the rationale for why to include it in the core transcends the content. The main arguments for inclusion concern the effects on the undergraduate education derived by learning FP:

  • A functional programming language illustrates a way of programming that departs dramatically from the procedural and OO languages typical of CS1 and CS2 courses, and so illustrates alternate ways of expressing computation, alternate models of computation, alternate ways of thinking about problems, etc. leading to a better educated graduate. Other languages – say, logic languages – could also serve this purpose; FP seems to have the highest leverage.
  • Studying a functional programming language introduces important computer science concepts – recursion, higher order functions, statelessness, sideeffects, lazy evaluation, etc. – that arise in many contexts and situations. It’s simply a good place acquire these ideas.
  • The substantial differences between the typical CS1/2 languages and FP illustrate a diversity among languages that shows students how selecting a programming language can affect the ease/difficulty of finding a solution to a programming problem, and implies that learning and applying new languages can be very advantageous.
  • Computer science professionals frequently use multiple languages, they must learn multiple languages over their careers as the field evolves, and they must assess the benefits of preferring another language. One’s second language is the first step on exploiting languages throughout one’s career.

There are also reasons often offered not to learn a functional programming language, and these should also be considered.

  • Functional languages are not used in practice. Such flat statements are obviously false, of course; the following have been cited as “languages used in industry”: Erlang (concurrent applications), R (statistics), Mathematica (symbolic math), ML, J and K (financial analysis), and domain-specific programming languages like XSLT (Items on this list can be confirmed to some extent by Web-available survey data.) Though, it’s true that functional languages do not dominate practice, the presence of XSLT alone gives them practical credibility.
  • Because functional languages are not used widely in industry, there’s no point to learning them. The justification for undergraduate education is not simply to prepare for one’s first job. Preparation for the evolution of one’s career is also a key goal, which the breadth afforded by learning a functional language justifies. No one knows what languages will be used in 20 years (mid career for present day graduates), and the benefits of functional languages for exploiting parallelism implies they may be candidates.
  • Teaching programming languages to computer scientists is unnecessary because they “can learn them on their own.” This view is surely true for learning related languages – Java then C# – but it is much more difficult to switch kinds. The issue is that a new model of computation must be learned, not simply a new syntax. A common result that reflects that the programmer didn’t learn the model is a program structured for the “first” language expressed in the syntax of the “second”. Once one appreciates how varied and rich languages are by learning dramatically different instances, and once one appreciates how critical the model of computation is to the language, the more likely it is that a programmer can quickly (and thoroughly) learn a new language.

Rationale for Adjustments

The rationale for the reductions is as follows:

  • PF4 The current recursion discussion is all taught in the imperative language context; it is overkill at 5 hours for imperative, so drop it to 2, and put 3 of the hours into programming the functional.
  • PF5 Event-driven can be taught in either imperative or functional. Split the time.
  • PL1, PL2 and PL3 is a lot of time for rather vague topics -- use the time productively in Functional Programming.
  • PL6 OO remains unchanged -- this isn't hurting anyone's sacred cow. The consequence would be that PL7 Functional Programming is made a core topic without adding any more hours.

To give feedback on this area of revision, go to here and use your ACM user name and login.

Copyright © 2008, ACM, Inc. and IEEE, Inc.

Personal tools