Language Excursion Guidelines

Presentation schedule

From the syllabus:

In addition to the core languages of the class, we will have intermittent student-led language excursions. These give us the chance to explore the world of programming languages in its wonderful and mind-boggling breadth. For each language excursion, a pair of students will make an in-class presentation, approximately half an hour long, introducing the class to a language and highlighting a few of its particularly interesting details.

I will assign you a date and a programming language (sorry, you don’t get to choose!), and you will present that language to the class.

Your goal is to convey the feeling of the language and highlight some interesting details. The class will not learn about all of the language’s features, much less know how to implement a real project in it. This is an excursion, not a tutorial. After your presentation, the class should understand your language’s general characteristics, be able to read some of its basic syntax, get a sense of the texture and taste of code written in your language, and learn about an interesting detail or two that distinguishes it from what they have seen before.

I suggest the following general structure, which you may modify to taste:

  • (< 1 min) Concise summary of salient characteristics, e.g. “Ruby is a dynamically typed, object-oriented language that emphasizes expressiveness and metaprogramming.”
  • (1–2 min) Brief history: Who created this language? When? Why?
  • (5–10 min) Show us a few simple code examples, and help the class read them. Give an understanding of the basic syntax. Point out fundamental constructs.
  • (10–15 min) Delve into just a few particularly striking features, something that makes your classmates say, “Huh! Wow! Fascinating!” For each language, I will tell you something I want you to highlight. You will also have some latitude to pick your own topics of interest.

How long? Aim for 25 minutes total, not including follow-up questions. Presentations and discussion often run longer, but aim for 25 minutes and we’ll go from there.

Slides, live coding, or both? Whatever works best for you. I recommend preferring live coding on the screen: it’s much more exciting, and does a better job of conveying the feel of a language. However, some things are better shown as a diagram, and some things take too long to type. Either way, I recommend practicing with a timer to get a sense of how fast you move through your material. Short is good!

  • If you do some live coding: Please plan and run through your code examples before class. Live-coding is good! Live puzzling it out, however, is usually not so successful. Plan. Practice.

  • If you do use some slides: Please be advised that I particularly dislike bullet point driven presentations. Please use slides for a purpose other than restating what you are saying. Slides that complement, illustrate, and contextualize you are saying are great! Slides that highlight important points or help navigate the structure of your presentation are great. Code-only slides are great. Blank slides are great if you want to talk or write on the whiteboard. What’s not great are slides that read like an outline of your talk, giving us a mountain of text to read at the same time we are trying to listen.

  • ~2 weeks before: install language and start playing with it
  • ~1 week before: meet with me about what specific things you’ll highlight in your presentation
  • 1-3 days before: practice your presentation on me if you have time, or at least share a quick overview.

It is your responsibility to keep track of this schedule, give yourself ample time to prepare, and schedule your meeting with me.