Syllabus

About This Course

Description

This course explores how to design a new programming language. In particular, we’ll focus on “Domain-Specific Languages”—languages designed for people who want to use a computer to perform a specialized task (e.g., to compose music, or query a database, or make games). Through readings, discussions, and programming, we’ll investigate why and how you would create a domain-specific language. The course also features a project that asks you to propose, design, and implement your own domain-specific language.

We’ll also investigate questions about how Computer Science and programming languages relate to society, including:

  • What counts as programming?
  • What counts as a programming language?
  • Who gets to call themselves a programmer?
  • How (much) does language influence thought?
  • How do we make software that other people will find useful?

This course follows a “studio model”, where all work-in-progress is made public, and we rely on each other’s critiques to improve our work. Sample solutions are published at the beginning of the assignment, you’ll often work in teams, you’ll have access to everyone else’s work throughout the assignment, and every assignment has a peer-review component.

Learning Objectives

This course has two broad aims, each with specific objectives:

Aim 1: To familiarize you with the purpose, design, implementation, specification, and evaluation of domain-specific languages.

Objectives:

  • Compare and contrast the benefits and drawbacks of a domain-specific language versus a general-purpose language.
  • Analyze a domain and identify its semantic model(s) and linguistic abstractions.
  • Design language-based user interfaces.
  • Evaluate language design choices.

Aim 2: To give you the opportunity to explore a wide variety of high-level language-implementation techniques.

Objectives:

  • Identify the properties of a general-purpose host language that make it (un)suitable for implementing a domain specific language.
  • Explore, compare, and contrast techniques for implementing an internal versus an external DSL.
  • Learn to program in Scala.

Because DSLs are a powerful and flexible programming tool, we will explore the topic systematically and broadly, building up concepts and code that should be useful to you in your end-of-course project and in your future studies and careers.

Instructor

My name is Ben Wiedermann. I’m a professor of Computer Science at Harvey Mudd College, in Claremont, California. I research the design and implementation of programming languages.

Style and Approach

One of the things I want to explore in this course is design and the design process: how do we make something that other people find useful? To answer this question for a programming language, we’ll take a studio design approach.

In our studio, all work in progress is made public [John Seely Brown]. Assignments, critiques, grading, and projects will be viewable by everyone in the class, all the time. Much of our work will be to comment on, critique, improve upon, and be improved by one another.

Resources

Communication

All communication outside of meeting-times will be conducted on the Pioneer LMS (Learning Management System), Schoology. As per the student agreement, use of email to communicate with the professor mentor during the program is strictly prohibited. If you have problems using the Pioneer LMS, contact your designated Pioneer program manager.

Feedback is an important part of any learning. During this course I will be asking you to give me feedback on your learning in implicit ways (e.g., exercises and assignments) as well as explicit ways (e.g., “How’s the class going for you?”). This is your class, and I want to make sure you get the most out of it. Please let me know right away when something we discuss is not clear. If you don’t understand something, chances are that other people feel the same way. You are always free to interrupt me — don’t let me get away with glossing over any topic. I also welcome any feedback about the structure, tone, and nature of this course. I ask that you give me this kind of feedback outside of class, via a message on Schoology. If you would like to give me anonymous feedback, you can send anonymous email.

Materials

Forum: We’ll use Schoology’s discussion forum to ask questions about the course. I’ll also post announcements there. You’re required to keep up with announcements on the forum.

GitHub repository: All the assignments will live on GitHub, where we’ll also comment on and critique each other’s work.

Scala: During the part of the course, we’ll be programming in Scala. We’ll cover key parts of the language in meetings and assignments, and there are also lots of good online resources for learning Scala.

Books: There is one recommended (but not required) book for the course.

  • Scala for the Impatient by Cay Horstmann. This book is a good reference for the Scala programming language, which we’ll be using a lot during the first half of the course. I’ll point out parts of the book that might be useful for particular assignments. It is available in the Oberlin online library.

Collaboration

This course is highly collaborative: we’ll discuss things as a group, and all work-in-progress is public. Although everyone else’s work (and often, the solution) will be available at all times, you must do your own work. You can be inspired by others, but you should look at someone else’s work only after doing your own work. If you are inspired by someone else’s solution, you can incorporate into your own, with attribution. Use your good judgement here. If you have any questions about what’s acceptable, please talk with me about it.

Coursework and Grading

Your work in this course will be a combination of:

Assignments (20%)

We will have five assignments during the first part of the course (after that, you’ll be working on your project). The assignments will have reading, writing, and programming components. Additionally, each assignment will have a “critique” component, where you help evaluate someone else’s work. Assignments will typically be given out after a group meeting, with the submission due four days before our next group meeting and the critique the day before the next meeting.

Project (80%)

You will complete one large project that asks you to design, implement, and evaluate your own domain-specific language. Though the project will be due at the end of the course, I will provide milestones and guidelines throughout the course, to help you stay on track. Each milestone is graded separately. For more details about the milestones and their due dates, see the instructions for the project.

Attendance / participation

This class—and your design process—thrive on open discussion and critique. You’re expected to attend all the required sessions and to participate by asking questions, offering your thoughts, and participating in discussions. Much of this work is built into the course and its grading (e.g., via the critiques); however, grading penalties will apply if you consistently miss or do not participate in sessions.

Notices

Rescheduling sessions

Group sessions cannot be rescheduled once confirmed by the student in writing. If a student misses a group session, Pioneer will endeavor to make a recording of the session available to the student. However, Pioneer cannot guarantee a recording will be available due to occasional technical issues.

During the one-on-one sessions, a student can request up to two sessions be rescheduled if he or she provides a written request to both Pioneer and his or her professor with more than 48 hours notice before the meeting time. Cases of student illness or other emergencies will also be considered with less than 48 hours notice. Once a student has altered two meeting times, he or she may not alter other agreed-upon meeting times in advance of the meetings, regardless of whether he or she continues to provide notice.

Technical support

For any technical issues relating to program software, the Pioneer LMS or the Oberlin College library system that are not urgent, students should contact their designated program manager. For all issues that require immediate attention, message Pioneer Academics on WeChat. A Pioneer staff member will respond to help resolve any problem quickly.

Writing Center

You can (and should!) use the Pioneer Writing Center to review up to four drafts of your paper. The Pioneer Writing Center guarantees feedback within 48 hours of submission. Students can submit drafts by sending their work to writingcenter@pioneeracademics.com.

Pioneer research support trainings

All students are required to take part in the research support trainings. The research support trainings will cover the following topics:

Topics covered in research support training #1

  • How to better interact with a professor
  • Tips on how to get the most out of the program

Topics covered in research support training #2

  • Good research practices
  • How to evaluate the credibility of online sources
  • How to access and use the Oberlin College Library and Databases
  • What is a literature review?
  • How to use the Pioneer Writing Center

Topics covered in research support training #3

  • How to write a research proposal
  • How to write a thesis statement
  • How to write an effective paper outline
  • How to cite sources and write a bibliography
  • How to avoid plagiarism

Topics covered in research support training #4:

  • TBD based on progress of and questions from students