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:

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.


Some time between now and Monday, April 15, submit a one-page ``pre-paper'' indicating the path you plan to follow: 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.


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.


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

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:
  1. Books published in the USA and articles published in archival journals.
  2. Other books from real publishers.
  3. Proceedings of national and international conferences.
  4. Articles from trade magazines or other lame sorts of journals that might not be archived.
  5. Proceedings of workshops or of regional conferences.
  6. University technical reports.
  7. 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...

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.

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 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 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?
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 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.
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?
Attempts to embody several major programming paradigms in a single language. You be the judge of its success.
Objects from Redmond. Could replace Visual Basic. Need I say more?
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 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 is designed to span a range from HTML through TeX to Scheme and beyond. How well does it succeed?
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.
An interseting language---perhaps a typed version of FORTH? Be sure to cover:
an application-oriented language for text adventure gaming. People who write interactive fiction swear it's the greatest thing ever. Why?
another application-oriented language for text adventure gaming. Is it better than Inform?
Embodies a particular style of concurrent programming (tough)
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.
pay particular attention to identifying datatypes and figuring out which ones are first-class. Also check out the strange approaches to control and modularity.
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.