CS152: Term paper

CS152 Term paper

Due Wedneday, May 15, at 5:10 PM in Maxwell Dworkin 133.

The purpose of the term paper is to give you an opportunity to integrate some of the varied topics we cover and to apply your integrated approach to something not studied in class. If there is a programming language you have always been curious about but have not had a chance to study in depth, the paper will also give you that opportunity.

The exact topic and format of your paper are up to you. Here are some suggestions:

Assess a language not covered in class. You should use the points of assessment discussed in class, but you should also point out any unusual features of the language you choose to cover, whether valuable or otherwise. You should not only assess the language you choose, but also compare and contrast it with languages we have covered in class. Don't overlook obvious relationships to languages from class!
In this kind of paper, you should take a position and defend it. Your position should be related to these kinds of questions:
- What kinds of problems is your language good at solving? What does it do well?
- What kinds of problems is your language not so good at solving? What does it do badly?
- How well are the features of your language integrated into a coherent whole?
(The last question is difficult to answer without extensive experience, and the answers are often difficult to defend with specific examples, so it is fine for you to focus on the first two questions.) Be sure to substantiate your opinions with examples or facts.
The main points of evidence for a paper of this kind should be information drawn from class and from a primary source (language reference manual, etc) describing the language.
I expect that many students will choose to write a paper of this kind. Suggested topics appear below.
Compare two languages. This kind of paper is essentially an assessment paper, but one that compares two or more languages. The languages should either be obviously similar or should be claimed to be good for the same purpose. For example, you might compare the two functional languages Haskell and Clean, or you might compare two scripting languages Tcl and Lua.
As compared to an assessment of a single language, a paper of this kind will normally be more focused. The idea is to zero in on the significant differences between languages. Some similarities may also be significant, but most can probably be dispensed with quickly.
The main points of evidence for a paper of this kind should be information drawn from class and from primary sources (language reference manual, etc) describing the languages in question.
I expect that many students will choose to write a paper of this kind. Suggested topics appear below.
Study a language in depth. Cover one aspect, or a set of related aspects, of a single language. It is up to you what aspects of what language you feel are worthy of deep study. You will have to make the case in your paper why these aspects are worth studying. For example, you might choose to study ``efficient compilation of Standard ML,'' on the grounds that the expressive power of first-class functions would be irrelevant if those functions could not be implemented efficiently. As another example, you might study the interactions of operator overloading (via type classes) and type inference in Haskell, on the grounds that the designers of Haskell seem to have integrated two apparently incompatible kinds of polymorphism.
The points of evidence for a paper of this kind should draw not just from a language definition but from all the available literature on your language.
Study a feature or problem in depth, across multiple languages. A look at the ways different language designers have addressed a single problem in language design. For example, you might study inheritance, looking at both class-based and prototype-based approaches, using examples from Smalltalk and Self to illustrate your points. As another example, you might consider approaches to operator overloading in languages as diverse as Ada, C++, and Haskell.
The points of evidence for a paper of this kind should draw not just from language definitions but from all the available literature on your languages.
Study a feature in depth, formally. Choose a language feature that interests you and describe it precisely and formally, using one of the theoretical tools discussed in class (operational semantics, denotational semantics, definitional interpreter, or a combination).
- You should choose a feature that requires you to go beyond the formal material presented in class.
- You should consider alternative designs or alternatives to the feature. Explain what the alternatives would do to your formalization. In other words, explore a small ``design space around the feature,'' not just the feature itself.
Examples of features that might be interesting from this point of view include default parameters (Ada and Modula-3), default fields (Modula-3), module initialization (Ada, Modula-3, C++, and others), or implicit parameters (Haskell, POPL'00).
Another topic of your choosing, subject to the instructor's approval. In particular, if you prefer to do some sort of implementation project and to produce a paper describing your project, you need prior approval.

This paper has no fixed length requirements. You should have something interesting to say, and you should say it at whatever length is appropriate to your material. As in real life, there is no minimum length. A cautionary note: this is a short paper, not a magnum opus---if you are thinking of more than 30 or 40 pages, you are taking on too much.

Procedure

Some time between now and Monday, April 15, submit a one-page ``pre-paper'' indicating the path you plan to follow:

Whether you are writing an assessment or some other kind of paper.
What language(s) you have chosen to study.
What major sources of information you will use.
On what aspects of the language(s) you intend to focus your readers' attention.

The pre-paper will not contribute anything to your grade. Its function is to make sure you have chosen a problem of manageable size and that you have a clear plan of attack. The course staff will return your pre-papers, with feedback, as quickly as possible.

You are encouraged to take a draft to the Writing Center for feedback.

Your final paper will be due Wednesday, May 15.

Criteria for the writing

The quality of your writing is as important as what you have to say. Spelling and grammar matter. Clarity and organization matter even more. As you finish coursework and go on to the real world (or graduate study), you will become known by what you write.

There are no particular length requirements for your paper. Take as much space as you need to say what you have to say, but no more.

Brevity is a virtue. Your grade soars with every clearly stated idea and with every observation substantiated with evidence. Your grade plummets with every vague claim or opinion unsupported by evidence. Your grade also decays with every unnecessary page you expend. Each page, and indeed each paragraph, should make a contribution commensurate with its length. A fine paper will make its observations and state its ideas clearly and succinctly, with no needless words.

Be particularly wary of long passages devoted to description; they will weaken an otherwise strong paper. Describe what is necessary, but do it concisely. The concepts we have covered in class give you a shorthand with which to describe programming languages: phrases like ``dynamically typed'' or ``nested functions with downward funargs only'' convey much information in few words.

You may want to consult Williams, Barzun, or Strunk and White for other tips on writing. My student writing page may also be useful.

Help with writing

The Writing Center exists in part to help you with assignments of this kind.

Audience

You should write for another student who has mastered CS 152 (i.e., done A-level work), but who may not be familiar with the language you have chosen. Write for a skeptical audience who will not believe your claims unless they are supported by clear and convincing evidence.

Sources

Here is a short guide to the professional literature on programming languages:

The premier journal in programming languages is the ACM Transactions on Programming Languages and Systems (TOPLAS). Unfortunately, TOPLAS papers are often highly theoretical, and TOPLAS is not likely to be a good source for CS 152 papers.
For general implementation, especially compilers, ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), formerly known as the Compiler Construction conference. This is the place for material about implementation, garbage collection, etc.
For theory, ACM SIGPLAN Conference on Principles of Programming Languages (POPL).
For object-oriented languages, ACM Conference on Object-Oriented Programs, Languages, and Systems (OOPSLA).
For functional languages, the following conferences:
- International Conference on Functional Programming (ICFP)
- LISP and Functional Programming
- Functional Programming and Computer Architecture
and the following journals:
- Journal of Functional Programming
- Higher-Order and Symbolic Computation (formerly LISP and Symbolic Computation).
ACM Computing Surveys sometimes contains useful material on programming languages (e.g., a well regarded tutorial by Paul Hudak).
The journal Software---Practice and Experience occasionally has interesting language papers. These are often at a good level for students, since they are aimed at practitioners, not at academics.
There are occasional random USENIX conferences, e.g., Very High-Level Languages or Domain-Specific Languages.
Lots of trade publications have articles on programming languages, but even the best (e.g., Byte, Dr. Dobbs) often have scant technical content.

Citing other work

The purpose of citation is to make it easy for your readers to identify and find your sources. Although you may have had teachers who are obsessed with the formatting of citations, in CS 152 only the content matters. While I prefer the author-date form of citation recommended by the Chicago Manual of Style (Grossman 1993), I will accept any standard or reasonable style. What is vitally important is that I be able to find the sources you use. That means sources are to be preferred in the following order:

Books published in the USA and articles published in archival journals.
Other books from real publishers.
Proceedings of national and international conferences.
Articles from trade magazines or other lame sorts of journals that might not be archived.
Proceedings of workshops or of regional conferences.
University technical reports.
Online sources.

If you locate things online, great, but try to find more archival sources. Be sure to give the URL or other method for locating online sources. (It is always helpful to give such a locator even for articles published in real places, when those articles are also available online.)

Under no circumstances should you cite unpublished material (like lecture notes) without the author's express written consent.

Suggested topics for a language assessment

If you choose to write a language assessment, you may write your paper on any programming language not discussed in class. If you're not sure where to start, you might find these suggestions helpful. The suggestions are rough; feel free to come to office hours to discuss them in more detail. I also suggest that you stop by office hours to ask about sources; in many cases, I can point you to papers or other documents that you might have a hard time finding on your own.

When reading these suggestions, keep in mind that what I'm writing here are opinions, not facts, with no evidence to back them up---exactly the style I'm asking you to avoid. But opinions are fun! Can you support these? Or even better, prove them wrong...

Haskell

A lazy functional language, a bit like ML, but has a substantially more sophisticated type system, including ``type classes,'' ``higher-order type constructors,'' ``polymorphic recursion,'' and more.

In my opinion, the Haskell community is today's single most fertile source of new language-design ideas. If you want to study a language that's got really cool stuff, Haskell would be a good choice.

Oberon

From that canny fellow who brought you Pascal and Modula-2, Oberon is one kind of extreme---the minimum possible systems programming language. It has been used to build operating-system kernels from the ground up, all the way to modern GUIs. Oberon systems are known for their lightning speed; an entire Oberon system can be compiled in seconds.

Modula-3

Modula-3 was an early-90s effort to express the programming-language features of the day (objects, threads, exceptions, data abstraction) in a traditional imperative setting. The goals are remarkably similar to C++: a systems programming language, providing unsafe code, but still capable of solving large problems. The Modula-3 designers followed Tony Hoare's advice to include only proven ideas, and to avoid untried ideas of their own. Modula-3 was never widely used, but it was highly influential in the design of Python, Java, and Java RMI (which was originally developed for Modula-3). What are the technical flaws in Modula-3 that prevented its wide adoption?

tcl

tcl is also based on substitution, but it has arithmetic, string-processing, procedure call, and a different approach to name spaces from TeX. More complex, but also more familiar---so it may feel less complex to use. Also, tcl has a much smaller set of data types. Pay special attention to embedding and memory-management issues. How does tcl support programming in the large?

Lua

The conventional wisdom on tcl says ``great idea, great library, terrible language.'' Lua is another player in the embedded-language game. It has been through several revisions and is quite mature; for example, it is used (I believe for character AI) in the popular game Baldur's Gate. To judge Lua, you'll have to evaluate two dimensions: fitness for scripting, and fitness for embedding into C programs.

If you want to study a language you might actually enjoy using, Lua would be a good choice.

TRAC

TRAC is an old language based on string rewriting. It had a second life as MINT in Russell Nelson's ``freemacs'' editor. (The name MINT stood for ``MINT Is Not TRAC.'') If you want to study a language with an unusual evaluation model, this is a good one.

libscheme

Compare Scheme with tcl and Lua as languages to be embedded in C programs. Look at libscheme paper. What features are missing from libscheme? What's the impact on embeddability of adding those features? How does the ease of embedding tcl compare with the ease of embedding libscheme? What are the costs of using tcl? Do you get what you pay for?

Leda

Attempts to embody several major programming paradigms in a single language. You be the judge of its success.

C#

Objects from Redmond. Could replace Visual Basic. Need I say more?

Ada

The designers of Ada had many of the same goals as the designers of Modula-3, but students of programming languages often say the two languages are very different. Why? What goals did they really have in common? How well does each language succeed in satisfying those goals?

TeX

TeX is based on that model beloved of theorists: substitution. It has been said (by someone whom I won't name) that Don Knuth tried very hard not to make TeX a programming language, but succeeded only in making it not a very good programming language. Explain the evaluation model and how it relates to the lambda calculus and to other languages studied in class. Languages based on substitution: TeX

Curl

Curl is designed to span a range from HTML through TeX to Scheme and beyond. How well does it succeed?

FORTH

FORTH breaks all the rules, but it still reigns supreme as a way of controlling tiny devices. The Open Boot Firmware standard for bringing up big hardware is based on FORTH.

PostScript

An interseting language---perhaps a typed version of FORTH? Be sure to cover:

Language vs primitives

Implementation considerations, especially regarding Level 1 vs Level 2

Inform

an application-oriented language for text adventure gaming. People who write interactive fiction swear it's the greatest thing ever. Why?

TADS

another application-oriented language for text adventure gaming. Is it better than Inform?

Occam

Embodies a particular style of concurrent programming (tough)

Python

Python draws from several sources including Modula-3 and Icon, and it is now touted for embedding. A tough choice because the language is big and doesn't hang together well.

perl

pay particular attention to identifying datatypes and figuring out which ones are first-class. Also check out the strange approaches to control and modularity.

Java

All the rage these days. Despite a superficial resemblance to C++, it is more closely related to Modula-3. Be sure to cover the relationships with both languages. Also, try to find some others if you can.

The very strongest papers often pick two or more closely related languages, assess them individually, and compare them.

I have read all too many papers on Inform, TADS, Java, perl, and tcl, whereas I'm quite eager to read a paper about curl, FORTH, Haskell, PostScript, TeX, or TRAC. I'm not eager to read papers about C#, but it probably would be good for me.