Why Undergraduates Should Learn the Principles of Programming Languages

The linked document is the first public release of a document discussing the value of programming languages principles for undergraduate CS majors.  The intended audience is computer scientists who are not specialists in programming languages.  Please leave comments on how well you believe it meets its goals and with suggestions for improvements.


Abstract:¬†Undergraduate students obtain important knowledge and skills by studying the pragmatics of programming in multiple languages and the principles underlying programming language design and implementation. These topics strengthen students’ grasp of the power of computation, help students choose the most appropriate programming model and language for a given problem, and improve their design skills. Understanding programming languages thus helps students in ways vital to many career paths and interests.
This entry was posted in Uncategorized. Bookmark the permalink.

9 Responses to Why Undergraduates Should Learn the Principles of Programming Languages

  1. Dan Grossman says:

    As a member of the Board that helped produce this document (though others did all the heavy lifting), I’m excited to see it out for public comment. I’d like to re-emphasize that what convinces PL researchers is probably quite different from what convinces other computer scientists. This document is a broad attempt for the former to communicate to the latter via concrete examples.

  2. Tony says:

    I agree with the claims made.

    But I’m confused about the audience. Is it those who teach, those who set curriculum, those who supervise interns, general engineers in industry, or undergrads themselves?

    I know no one with just an undergrad degree who puts on a resume that they’re a “computer scientist”. At best, they have a CS degree.

    Is the goal to ensure that programming language theory be in a required curriculum, or to encourage CS undergrads to take a PL theory course as an elective? Or to persuade employers to look at the presence of a PL theory course when considering new graduates for positions?

  3. Curt Sampson says:

    I’m very pleased with this paper; I think it makes an excellent argument. However, I feel it would be nice, since it appears to be aimed at those developing undergraduate CS curricula, to give some suggestions as to just how in particular one should teach undergraduates the principles of programming languages.

    For example, I can think of three things one could do off-hand: 1) have a requirement for a one-semester overview of different programming language styles, 2) have a requirement to do a series of more in-depth comparison courses based on something like Van Roy and Hardi’s _Concepts, Techniques, and Models of Computer Programming_ (but still based on a single, albeit they claim multi-paradigm, language), and 3) have a requirement to learn, in a fairly in-depth way, two or three languages picked one from each of several groups (one group might contain Java, another Haskell, OCaml and ML–there are many different ways to divide things up). Which of these techniques, or combinations and variations thereof, should one use? What are their advantages and disadvantages?

    Perhaps this is really the topic for another paper or series of papers, but even so it strikes me as a failing of this paper that it doesn’t even start to address this. Telling someone “it’s good to go this way” is much more useful if one gives them a few tools to start figuring out how to make the move.

  4. Eugene Doma says:

    Very inspiring position paper, thank you for inviting comments. I have a few, in no particular order:

    * The distinction between ‘computer science’ and ‘software engineering’ needs greater emphasis. The CS focus, in my mind, is more mathematically oriented and based upon principles. Whilst the SE focus is on building information and communications systems using software and computing hardware. Both areas involving PL, but in very different ways.

    * When we speak of ‘programming languages’ we tend to lump in the libraries that make it useful. For example, Java as language can be learnt in a week or so, but most people only master a small portion of the APIs available, even after years of programming with it. This issue is one of the key stumbling blocks with teaching virtually every language. And there are the compilers, linkers, etc which are also most confusing

    * Programming languages are positioned at many different levels of abstraction. Some, like MatLab, at high levels and others like assembly language at low level. But presently the hardware is predominantly based upon the von Neumann stored architecture. It is the lack of understanding the fundamentals of the platform that lead to much misaligned beliefs and practices. The chemist and chemical engineer need to understand the significance of the periodic table and its encoding of valence bands, amongst many other things. So too, the budding computer scientist needs a solid grounding in how the underlying ‘engine’ for computations works.

    * In practical terms, model based software engineering is the key to higher productivity and quality systems. Domain specific languages, especially the embedded or internal form, together with generative programming techniques need greater exposure during the formative years of CS/SE education.

    * The syntax of many programming languages is most confusing for beginning programmers. The notations and many rules of syntax detract from the underlying principles. Personally, I favour Python as the first language since it is the closest to ‘executable pseudo code’ and the standard libraries make it is easy to use for introductory projects. Having things work is an essential early motivator. The second language could be Lisp (Scheme) due to its ‘syntax free’ form which allows us to focus on mathematical like rigour.

    * Introducing DSLs early, embedded in Lisp or Python, allows us to focus on domain specific solutions. Followed by more advanced languages, Haskell, OCaml, Erlang, etc. Such a progression would clarify how those languages are tailored to better support specific architectural paradigms.

  5. ross says:

    I only had time to skim read the article, however it reminded me of subject / text book I studied at university called “Principles of programming languages”. I sat that subject in 1991 :-)

    And I must say that I recall it being one of the most interesting and useful subjects I took in my degree.

  6. Michael R. Dunlavey says:

    I notice all the authors are in academia. I have no particular beef with the document as it stands. Rather, I have a beef with the broader context of C.S. education, namely that it is not taught like engineering, and that it lacks quality control feedback from industry. Here’s a discussion of those points: http://stackoverflow.com/questions/2976590/cs-education-where-was-it-where-is-it-now-where-is-it-going/3019575#3019575

  7. Hans Boehm says:

    The paper has a nice collection of anecdotes and illustrations of how
    programming languages design permeates Computyer Science.
    I found bullet 3 particularly convincing, and would have liked
    to see that brought up earlier.

    I think it’s important to publicize these. But I also have a few
    concerns about the paper:

    1. Echoing Curt Sampson’s comment, I think it would be good to be clearer
    about exactly what’s being advocated. I’m not up on what’s normally taught
    in such a course these days. There are a number of topics I personally
    consider important that I suspect are on the periphery of this topic, and not
    really addressed in the paper. For example: How might one specify a
    language with enough precision to be able to accurately reason about programs?
    What about constructs and techniques for mainstream languages that
    are unlikely to be covered in a basic programming class (e.g. C++ template
    metaprogramming, which is both widely used and interesting)?
    What are the algebraic properties of arithmetic types in various
    programming languages?

    2. Some of this, particularly bullet one in the paper, reads a bit too much
    like an often repeated argument that one should learn Latin to make it easier
    to understand other natural languages. I don’t think the argument
    carried. I’d like to see bullets 3 and 4 moved up.

    3. My sense is that in many industry settings, the set of acceptable
    programming languages is small and probably more static than it was
    a few decades ago. And in many contexts, there are very good economic
    reasons for that. Thus I’m not sure that the ability to choose between
    OCaml and Scala is currently perceived as critical. However, I think there
    is a strong tendency for interesting concepts to eventually migrate into
    that small set of mainstream programming languages. For example,
    we seem to be getting some variant of function closures (lambda expressions)
    in all of them. And it’s important that past CS graduates hopefully
    already know what those are.

  8. Michael L. Scott says:

    As a PL instructor and textbook author, I’m delighted to see this document,
    and find it generally quite good.

    My principal meta-comment is that I think the doc could have a stronger
    “practical” bent. This would, I think, make it persuasive to a larger
    audience. For example, in the abstract I’d mention that it’s much
    easier to debug programs and to tune them for better performance if one
    has a deep understanding of language design and of the mapping from
    source code to object code. I’m reminded here of Bryant & O’Hallaron’s
    approach to computer architecture, as embodied in their innovative
    text (Computer Systems: A Programmer’s Perspective), which approaches
    architecture and organization largely in terms of its impact on systems
    programmers. A similar approach to programming languages can make the
    material feel more “alive” and relevant to students. This need not
    demote language theory to a service role; done right, it makes the theory
    all the more compelling.

    Several paragraphs of the doc speak to programming that is more
    “effective”, “appropriate”, or “suitable”. It’s generally unclear to me
    what objective function is meant to be implied. Intuitive appeal?
    Amenability to formal proof of correctness? Ease of maintenance and
    extension? Likelihood of fast execution? More clarity on this point
    would add “punch”.

    There’s a lot of emphasis in the doc on functional programming (see, for
    example, the last full paragraph on p. 2). While I’m a huge fan of the
    functional style, I think the discussion would be stronger if similar
    emphasis were placed on additional styles that can be encouraged by a
    programming language, e.g. object orientation, constraint satisfaction,
    nondeterministic choice, or design patterns and code reuse based on

    The top half-paragraph on p. 3 sounds a lot like point (2) below it.

    The first full paragraph on p. 3 might be stronger if it used the words
    “safety” or “security” explicitly.

    In the first full paragraph on p. 5 I’d be inclined to name some
    languages explicitly: HPF, SQL, Erlang, …

    There’s a grammar typo in the 3rd full paragraph on p. 5:
    “understanding” should be “to understand” (to parallel “to have” in
    the subsequent phrase).

    The Ruby v. Scala example on p. 6 seems weak to me. Ruby’s functional
    features aren’t as good as Scala’s, but they’re not bad: higher-order
    functions, continuations, unlimited extent, lambda expressions (more or

    In the 3rd paragraph on p. 6 one could cite many other real world
    success stories that hinged on the right choice of language. I’d be
    inclined, for example, to mention Erickson’s success with Erlang for

    Again, my thanks to the authors for putting this together.

    Michael L. Scott
    Univ. of Rochester

  9. Arthur Fleck says:

    I commend the Board for its effort to advocate on behalf of programming language principles. However, I was disappointed to find no reference to logic programming in the document. Logic programming places a much greater focus on code correctness than other paradigms. For instance, using only satisfiability of propositional logic, one can express numerous famous (NP-complete) computational questions. This is just one illustration of the high level of abstraction and tight integration with problem solving.

    Logic programming also provides a bridge to other language topics relevant to programming in the broad sense. For one thing, it relates closely to specification languages. There are a variety of these (e.g., Z, UML, Statecharts) with important connections to programming. It also has a close association with query languages. Finally, logic programming provides the epitome of the pattern matching style of program layout that has been so beneficial in simultaneously improving both the succinctness and clarity of programs in numerous languages.

    With the continued development of the discipline, the topic set for the CS undergrad major has become overcrowded. A serious assessment of all the contenders is in order. I encourage the Board to refine and improve its initial effort on an assertion of significance, and make its visibility as broad as possible. Surely, advocates for other topic areas will respond in kind, and a well-informed debate can ensue to establish an appropriate balance of emphases.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>