Day, Time, Location Tuesday, Friday: 9:50 am–11:30 am, Ryder Hall 429
One side-effect of this course is that it usually creates a pool of knowledge in different niches of the programming languages within NUPRL. As the Abstract explains the course has two goals. This page describes the mechanics for achieving these goals.
Process I will present two themes (see Lectures) in the first couple of weeks so that you get an idea of what a theme is and how to present it.
PhD students propose three Themes of interest, each supported by at least one central citation. Everyone else propose two Themes. Send email with the theme proposals plus time slots when you are available for a meeting.
Due date Meet by the beginning of the second class meeting. You may set up a meeting as soon as you read this page.
Once a theme is approved, compile a list of up to ten major (but no fewer than three) articles on this theme. Read the introductory part of each article so that you can explain its role in the evolution of the theme.
Submit a list of references to the instructor. Each reference should consist of the author(s), the title, a PDF link, and a sentence or two that explains your understanding of the role of the paper.
If you are new to the idea of exploring themes, discuss how to go about this step during your first 1-1 meeting with the instructor.
Due date by the third class meeting.
Set up a meeting with the instructor to discuss the proposed sequence of articles. This meeting will decide which articles to use.
Due date between the third and fourth class meeting.
Write a short abstract, like those in Lectures, that explains the very basic steps of your theme’s evolution—
as represented by the chosen papers.
Due date as soon as possible after the selection meeting and before the presentation to the class.
Study the selected papers. Prepare an annotated bibliography of the chosen articles. Prepare a blackboard/whiteboard presentation.
Due date please have a draft of your presentation ready a week before your presentation. Then meet with the instructor if there are any questions on how to present the material. That way we can make changes in a timely fashion.
Presentations Ordinarily you would deliver a blackboard/whiteboard presentation.
If you can think of a better simulation of bb/wb lectures, let me know. This semester you will hand-write your presentation on a notepad (yes, paper and pencil!), scan the pages with your phone, and use those scans for the lecture. If you have a document camera or an electronic notebook that can deliver live writing, you may wish to use those and write as you speak.
The focus of this seminar is on ideas, not details. A slideshow makes it too easy to include silly proof details, superfluous benchmark measurements, or some random "people counting" tables. This form of copying-and-pasting material from a paper to a slideshow tool does not demonstrate understanding. Turning it into essential words for a blackboard presentation does.
Many PhD students want to become professors and that job includes teaching.
Learning to separate essential ideas from chaff is critical to teaching.
Learning to arrange material for a lecture and deliver it "freely" is
critical. Learning to adapt a presentation schedule on the fly—
Software developers often argue language and process details. In such one-on-one
or small-group discussions they teach. Having lectured before, helps you think
through chains of arguments, starting with the “big” idea and slowly refining
it to the details as needed—
Listening If you are not presenting, you will assess the lecture of your presenting peer and submit your Assessment to the instructor. Your assessments will provide feedback concerning both the content and the presentation.
Writing an assessment forces you to pay close attention. Reflecting on what you have seen and what you have heard will help you figure out how your own presentations can be improved.