Design and Implementation of Modern Programming Languages

If you want more information, scroll down to Overview. If you want to participate in the seminar, project, or both, then check the Timeline below and register on Moodle.

You can contact us on Moodle.

Timeline

• Registration (seminar & project)
  • 2024-10-14 12:00: Topics for WS 2024/25 available
  • 2024-10-18 13:00: Kickoff meeting (Zoom link in Moodle)
  • 2024-10-18: Registration deadline
  • 2024-10-24: Topic Assigment/Notification
• Seminar submissions:
  • 2024-11-xx: Sketch
  • 2024-12-xx: Draft
  • 2024-01-xx: Review
  • 2024-02-xx: Final paper
• Seminar presentations:
  • ca. 2025-02-12 - 2025-02-14: Presentation days
• Project deadline:
  • 2025-03-31: Report

Let us know if the presentation day and time conflicts with another course!

All submissions happen via Moodle. All deadlines are at 23:59. In doubt, the date and time in moodle counts.

Overview

DAIMPL consists of a Seminar and Project. You can do both together (usually on the same topic), only the seminar, or only the project. If you have previously taken the seminar, you can instead do a Teaching Internship ("20-00-0443-pl Praktikum in der Lehre - Softwaretechnik" in Tucan).

The seminar and project will be done in groups 2 or 3 students (the teaching internship is done alone). We have a limit on the number of groups we can accept (ca. 15 seminar, 10 project). If there are too many applicants, we will decide based on your motivation text (see Moodle for the registration). Due to the limitation in the number of groups, we strongly encourage you to sign up as a group of 2 or 3. If you apply alone, we may add you to another group and your chance of rejection is higher. We provide a Moodle forum for finding group members.

For the purposes of forming a group to do the seminar together, we encourage any form of self organization. Communication with supervisors happens via the questions forum in Moodle or by private message.

As an (unofficial) communication channel, you may try to find like-minded students here:

• TU Darmstadt Informatik Discord Channel

Project

The project reflects the open-ended practical aspect of the research process. Compared to the seminar, the focus is on you doing or implementing something yourself, rather than reading literature. Start with a research question but refine the question together with your supervisor while understanding the topic better while working on it. Note that the project does not have a fixed timeline, but we expect you to regularly work on the project during the semester and report/discuss with your supervisor. The expected workload is roughly 1 working day a week (6 CP). We will ask you to write a short article summarizing the results of your project (think: blog post).

Project Grading

The result has to “work” (i.e., if you write code, it has to run). It must have enough documentation such that you yourself could work on it again next year.

At the end of the project, write a short text with inline images summarizing the highlights of your results.

You will be graded on the quality of the implementation and how much of the research question you answered. High quality results that answer a small part are good. Rough results, answering a lot of interesting questions, are also good.

Seminar

The primary goal of the seminar is to introduce you to the scientific publication process. The secondary goal is the introduction to one research area in depth, and multiple other areas superficially.

The process is:

• Start with a topic and a couple of pointers to research papers about that topic.
• Expand your knowledge by finding new references.
• Create your own short paper about the topic, summarizing your findings.
• You will then review the papers written by other students and receive feedback on your own paper.
• Improve the paper based on the feedback.
• Along with the paper, submit a small piece of code that puts your topic to use or reimplements an algorithm you found during your research.
• Finally, give a presentation to the other students that serves as a high-level introduction to your topic.

Page and Presentation Time Limit

The page limit and the presentation time adapts to the size of the group:

• Two persons submit 6 pages and present 10 minutes.
• Three persons submit 8 pages and present 15 minutes.

The page limit takes the space needed for the title and any figures or tables already into account. If many or large figures or tables are included, we expect a slightly longer term paper to compensate for this. Please consult your advisor about this. References do not count towards the page limit. In addition to your starting papers, we expect at least 2–3 related references found per person.

Writing papers

The initial references provided with the topic chosen by you are only a first step; in your term paper, try not to summarize everything that's written therein or in the references' references. Instead, try to tell an engaging, coherent story about one aspect of the topic. (It helps to image oneself as a novice to the topic, who attends the talks or reads the term papers.) Also, search for further references on your own and point out connections between the various papers you researched.

• Also see: reading a computer science research paper by Philip W.L. Fong

Please present technologies, e.g., programming languages, with your own words and your own examples. If you merely copy the work of others, this means but one thing: no contribution; you will fail the seminar. This rule does not prevent you from quoting other researchers, however. It does require you to faithfully attribute quotations or other kinds of references, though.

Pick some interesting finding about your research area and focus on explaining that. Start with a motivation of the problem. Illuminate necessary terminology considering both being formally correct, providing informal intuition and concrete examples. Remember, your paper MAY summarize the papers you read, but pure summaries are boring – make sure to relate the summaries to each other and the overall story you want to tell.

All participants are required to use the same template:

• ACM article template
• Document header: \documentclass[sigplan, review, authorversion, nonacm]{acmart}.

In summary:

• Understand your research area.
• Summarize your understanding – motivate and define the problem and the solution, provide intuition and give examples.
• Do not copy text or figures verbatim from existing papers.
• Structure should reflect what you see in the papers you read, but you may also make your own choices if you think that improves the paper.

Writing reviews

We will send you a review template with specific details. See also:

• How to review a systems paper by Timothy Roscoe
• How NOT to review a paper: the tools and techniques of the adversarial reviewer by Graham Cormode

Typical reviews at conferences in our field are “double-blind,” so both the author's and reviewer's identities are kept secret to avoid any bias. For this seminar, we want at least the reviewers to stay anonymous, so please do not write your name on your reviews.

Giving scientific talks

With this seminar, we want to introduce you to core techniques of scientific work; each participant is thus required to give a talk about the topic chosen. This talk will be given during a Blockseminar at the end of the term.

Each member of the group should speak for an equal amount of time in the presentation. Please practice your talk several times; in particular, make sure that you do not miss the time limit by much, i.e., by at most 10%; this mimics the strict time limits of real-world conferences and workshops. Consequently, if a talk is significantly shorter or longer, then this fact will have a (negative) impact on the presenters' grade.

Some general advice on talks:

• The main goal should be to make the talk interesting.
  • Feel free to leave out parts of your work if you feel it does not fit the format.
  • Feel free to add things not part of the paper if it helps the talk.
  • Use illustrations to your advantage.
• Consider that most of the audience are other students, that have no clue about your topic. Focus on the motivation of the work you present: What is the setting? What are the interesting challenges? What properties are desirable by any solution? After the solution is presented, what are the impacts on the field?
• A generally rough guideline on talks is that they should be 40% motivation 30% technical contents, and 30% evaluation, conclusion, and outlook. You don’t have to stick to that precisely, but keep it in mind.
• Our talks are short, you don’t need a table of contents.
• Also see: How to give a good research talk by Simon L Peyton Jones, John Hughes, and John Launchbury.

Seminar Grading

The overall grade for the seminar is determined by:

• the final paper submission (paper and code) (60%)
• the talk given (30%)
• the review written (10%)

Furthermore, we will consider the effort placed into writing a good sketch, draft and changelog in the grade for the final paper submission to a small degree. And, we will consider your participation in the discussion following each talk; it counts towards the grade received for the talk.

Although the grade for the paper is given to the whole group, the final grade between members of a group may differ due to the individual grading on the talk and reviews.

Teaching Internship

To take the teaching internship, you must have taken the seminar previously. The internship gives 5 CP and involves holding office hours and giving feedback to the students taking the seminar, as well as proposing improvements in the organisation of the seminar.

You will be graded based on

• The quality of the feedback given to the seminar papers and
• a small, written report on the topic of organizing seminars.