Recent Changes - Search:
ECG Home






Spring 2017

Older Courses

Fall 2016

Spring 2016

Fall 2015

Spring 2015

Fall 2014

Spring 2014

Fall 2013

Spring 2013

Fall 2012

Spring 2012

Fall 2011

Spring 2011

Fall 2010

Spring 2010

Fall 2009

Spring 2009

Fall 2008

Spring 2008

Fall 2007


edit SideBar


Home Assignments Lecture Blog Resources Project Discussion Group

Exam 2 is Fri Mar 31 in Ball 214

COMP.3010 Organization of Programming Languages, Spring 2017

Prof. Fred Martin (201 section),, Mon/Wed/Fri, 12p – 1250p, Olsen 503

office hours M 2–3p (Olney 524); R 1–2p (Olney 524); F 1–2p (Olsen 302)


Kavya Kumar Vallurupalli (grading students with last names beginning with A to G)
Narasimha Prasanth Chintarlapalli Reddy (last names from H to O)
Conor Finegan (last names N to Z)

Grader Office Hours:

Conor is available to meet with any student 2–5p Wed in quiet computer lab

Consider this syllabus as a contract between the professor (me) and the student (you).
You are responsible for understanding everything here.
Ask questions if you are unsure about anything.

We will be using the following book:

Structure and Interpretation of Computer Programs (2nd edition, 1996, ISBN 0070004846)
Hal Abelson and Jerry Sussman

The Abelson/Sussman book is freely available at HTML pages at the publisher's site here. There is a complete PDF version on Github (which is better-formatted than what's at the publisher's site). If you like holding a book in your hands, used hard copies are available at around $50. Make sure to get the 2nd edition, published in 1996. Here are links: bigwords, alibris, amazon, bookfinder

Catalog description

Analytical approach to the study of programming languages. Description of the salient features of the imperative, functional, logical, and object-oriented programming paradigms in a suitable metalanguage such as Scheme. Topics include iteration, recursion, higher-order functions, types, inheritance, unification, message passing, orders of evaluation, and scope rules. Elementary syntactic and semantic descriptions. Implementation of simple interpreters.


There are four categories of work that will be assessed:

  • Programming assignments 20%. The assignments are the primary way for learning the course material.
  • Two mid-semester exams 10% each x 2 = 20%.
  • Final exam 30%.
  • Term project 30%. A significant part of the class will be an independent implementation project, which you will specify and carry out, primarily over the last month of the semester. We'll start conceptual work on the project earlier than that. I will expect the project to represent a significant work effort.
You will apply the ideas developed in the class in an original software implementation. You may thus connect the ideas of the class with your own interests—music, robotics, art, databases, the web, networking, gaming, etc. The learning goal of the project is to have you find some real-world relevance of the ideas in the class.
Projects will be done in teams. The team must divide each project into approximately equal shares of work for each partner.

The Bottlenose Autograder

Programming assignments will be submitted to Bottlenose, the department's autograding system (at

The autograder will assign a provisional score to your work, based on determining that your functions produce the proper outputs given particular test inputs. Then, your work will be reviewed by a course assistant, and the score will be adjusted up or down as appropriate.

Example 1. A problem requires you to write a recursive function that uses an iterative (looping) structure. You submit a function that computes the correct result, but uses a recursive implementation structure. The autograder will pass your code as correct, but the course assistant discovers that your code did not use the required approach. Thus, you lose these points.
Example 2. A problem involves you writing a narrative explanation in a comment block and setting a machine-readable flag to #t (“true”) to indicate that you have included the explanation. The autograder only checks the flag and gives you credit. The course assistant then reviews your answer and decides if those points are warranted.
Example 3. Your implementation shows significant effort and contains partially correct code structures. But, the autograder marks you as simply wrong. The course assistant reviews your work and adds points.

You can submit multiple times to the autograder without penalty. (You are encouraged to do this.)

Only the final submission will be reviewed by the course assistant.

Late Policy

Assignments are due at 11p on the day that is specified.

Assignments will lose 20% of their value per day that they are late. 11:01p counts as a whole day. After the fifth day, they will not receive any score. (You may still submit them to the autograder for feedback, but the grade will automatically be set to 0, and the course assistants will not review them.)

Collaboration and Academic Integrity Policy

You are welcomed and encouraged to discuss ideas in the class with your peers. However, pair programming or other side-by-side work that involves sharing of code is not allowed.

The instructors are fully aware that solutions to many of the homework problems are available on the internet.

In addition to manually inspecting your code, the course assistants will routinely submit code to the Stanford MOSS system (“Measure of Software Similarity”).

If your code appears to have been copied from online solutions (or another student's solutions), you will be called into office hours to defend your work in an oral examination.

If you cannot adequately explain how the code works, the instructors will take appropriate action per the university's academic integrity policies (undergrads; grads)

In short: By turning in an assignment, you attest that you have written the new code that it includes.

No Posting of Solution Code Policy

You are not allowed to post solution code to problem sets assigned in this class in public places (e.g. Github). This includes your own solutions as well as solutions that may be provided by the instructors.

This policy is a courtesy to future students, who — to the fullest extent possible — should have the opportunity to struggle with the problems in the same way that you do.

Please note that this is typical policy at premier computer science departments. E.g.:

  • Princeton COS 126. “Your work must never be shown or communicated to anyone who is taking COS 126 now or who might take COS 126 in the future. ... You must never place your work in any public location (including websites, leaving printouts in a classroom, etc.). ... The rules ... continue to apply even after this semester is over.”
  • Harvard CS50. “Not reasonable: Providing or making available solutions to problem sets to individuals who might take this course in the future.”
  • MIT 6.01. Students should never share their solutions (or staff solutions) with other students, including through public code repositories such as Github.” (emphasis in the original)

Non-compliance will be pursued rigorously per UMass Lowell's academic integrity policy.

Attendance Policy

Students are responsible for all material covered in class, and are expected to attend all class meetings. Attendance will not be taken.

Exams will be announced at least one week before they are administered. In-person participation of final project presentations is required. Make-up opportunities will be made only in the case of emergencies, not scheduled conflicts (e.g., work).

Recordings of lecture content will be available at

Discussion Group / E-Mail List

We will use Google Groups for class conversation and announcements. Please request to join the group at!forum/uml-opl-spr17.

Edit - History - Print - Recent Changes - Search
Page last modified on March 19, 2017, at 12:08 PM