[ ^ CSE 341, Winter 2004 home page ]

Extra credit projects

Due dates:
Proposal: Mon 8 Mar 2004
Final project: Wed 17 Mar 2004, at final exam

Instructions

Devise a project that you estimate will take somewhere between 8-16 hours of work (about 2 days of solid work) per student, or select an instantiation of one of the project classes below. Your project should be designed to teach you something about programming languages.

Projects may be done individually, or in groups of 2 or 3. Somewhat more work will be expected of a group than an individual.

Once you have selected a project, email Keunwoo with your project proposal. Your proposal should include a list of deliverables (what you will submit at the completion of the project). Each project must be different from the rest. Projects will be allocated using first come, first serve scheduling.

Extra credit projects will add variable amounts to your grade, depending on the quality and scope of the project. It is better to do a small project, and produce a very polished document describing what you did and what you learned, than to choose a big project that's a messy pile of hacks.

Your grade will not be penalized in any way for not doing an extra credit project. The presence of extra credit projects will not bias the curve; any extra credit adjustments will occur after the curve has been determined.

Project ideas

• Download a Haskell implementation, teach yourself Haskell, and write some interesting classes using Haskell. Take advantage of type classes and laziness. Write a short report describing your experiences.
• The Squeak programming tools are cool, but they are not the end of the story. Devise some new programming tool for Squeak. For example, you might devise a visual class browser that shows the inheritance graph pictorially, or some new way of browsing methods. Implement this tool. Produce a fileOut of your code that runs on a stock Squeak 3.6 image, and document your tool on the wiki with screenshots and explanatory text. Your tool should be task-centric: you should explain what programming task your tool is meant to help with. Describe a scenario in which your tool would become part of a programmer's workflow. This does not need to be a huge addition or a whole new paradigm for browsing code --- some interesting extension of the existing browsers is sufficient to get some credit.
• Learn to use the SableCC parser generator. Design an original little language of your own, and implement an interpreter with a read-eval-print loop. Name your language and document its design on the wiki. Your language need not be a breakthrough in language design (those are pretty hard to come by). Borrow ideas from previous languages where appropriate.
• As above, but instead of designing your own language, implement an interesting subset of some language you know, e.g. Smalltalk.
• Teach yourself about iterators in either the CLU or Sather languages. Learn the details of how Ruby blocks can work as iterators (with retry, redo, break, and next). Then compare these iterators with Smalltalk's lambda-based control structures for collections. Write a tutorial that will teach a student these various styles of iteration over collections. What are the important tradeoffs? What is made easier in one style or another?
• Find some language that you do not already know, and that we are not covering in this course (besides C, C++, or C#). Write a tutorial that introduces this language to a student who has taken 341. What are the interesting features? How do they relate to features in some of the languages we have studied? Do not attempt to cover the entire language; choose some subset of the features to explain. Post your tutorial on the wiki. (For this one, you should email me and reserve a language nobody else has selected. First come, first serve.) Your tutorial should be approximately long enough that it would fill a complete lecture if it were taught in a class.
• Write a research paper on the historical development of some programming language(s) of your choice. You should use a reasonable academic style of presentation, including citations to primary sources where you can find them. Your paper should have something to say besides a list of names and dates. Why is the development of the language(s) you discuss interesting? Ben Dugan's paper on Simula and Smalltalk is a possible example of this sort of paper, although your paper does not need to be as long as his to get credit.
• Read Paul Wilson's uniprocessor garbage collection survey paper. Write a tutorial explaining how one or more garbage collection algorithms work, including strengths and weaknesses. Use your own words and your own illustrations --- do not simply copy out of Wilson's paper. Post your tutorial on the wiki.