Computing and Information Technology Interactive Digital Educational Library


Syllabus Collection >
Syllabus >

Please use this identifier to cite or link to this item:

Title: â€œAn Introduction to Programming Languages!”
Authors: Brown University Department of Computer Science
Issue Date: 
Publisher: Brown University Department of Computer Science
Abstract: CS 173 “An Introduction to Programming Languages!” * Home * Textbook * Assignments * Reading Group * Syllabus * Missive * Honesty * Staff * Software * Newsgroup Syllabus We will not be publishing a day-by-day lecture schedule for this course. A day-by-day schedule doesn’t make sense given that some lectures will invariably run over or will need revisiting, and it’s hard to predict a priori which ones these will be. As a student, you should prefer a schedule that doesn’t force the professor to move on irrespective of whether or not you have understood the material well enough! For the assignment schedule, consult the assignments page. Staying Current You are responsible for keeping track of all assignments and other material posted to the course’s newsgroup, brown.cs.cs173, and to its Web site. Please read the newsgroup regularly, because we will post notification of major changes to the Web site there. Contacting the Staff To communicate with us, please send mail directly to We will direct our answers to the newsgroup if we think the questions and answers should be of general interest. Please don’t post directly to the course newsgroup or send mail to us individually in addition to mailing the alias listed above. We will remove your name from the questions if we think it appropriate (so you need not feel embarassed about asking “easy” questions), while also giving credit where it’s due. Assignment Due Time Assignments are always due at 2:00AM on the listed date. Why 2AM? Because we want you to attend class and to be reasonably alert when you do so. Past experience indicates that making assignments due at the start of class leads to a largely somnambulist audience that day. Those classes are fun for neither the student nor the professor. Turning in Assignments For programming assignments, you should use the electronic handin program. From the directory containing the files for the assignment you wish to hand in, execute /course/cs173/bin/cs173handin asgn-name where asgn-name is specified in the table on the assignments page. For written assignments, print or neatly write your solutions and put them in the handin bin on the second floor of the CIT. * For both written assignments and essays, write your login at the top of every page (this is helpful in case the pages become separated), staple the pages together, and place them in the cs173 handin bin on the second floor of the CIT. Teams need only turn in one copy of their solution. * For written assignments, please solve each problem on a separate page and print single-sided, so the TAs can easily divide your work for grading. * For team assignments, each member of the team should turn in a complete copy of the team’s work using the correct procedure from above. Late Assignments We will not accept late assignments. Assignments are often timed to be due for a classroom discussion on the assigned material because you can better follow a difficult topic if your struggles are fresh in your head. The class will sometimes even discuss solutions to the homework problems. Once we do this, we can no longer accept your solution. If you really need or want to turn in an assignment late, you must get the professor’s permission to do this at least 24 hours before the assignment deadline. When we do accept a late submission, we will use this formula to compute your net grade: (define (net-grade gross-grade number-of-penalty-units) (* gross-grade (expt 0.9 number-of-penalty-units))) A penalty unit is a 24 hour period or part thereof after the due time. Even a minute after the due time incurs a penalty unit. So if you have permission to handin late, relax; sleep; attend class; and submit something polished later in the day. Non-Team Project Collaboration The purpose of assignments in this class is to help students learn key ideas in programming languages. Some (not all) assignments require a certain insight, or at least careful analysis, that is much harder to generate or perform than to merely replicate. We believe that doing it for yourself, though harder, is the only way to truly understand that insight or analysis. Having said that, we also want you to be able to work with each other, learning from one another’s successes and failures. Therefore, we will permit you to discuss assignments with your classmates (in addition to the course staff). Note that you may only discuss possible approaches; you may not share answers, unless explicitly permitted by the assignment. What’s an answer? We consider it to be any key insight, technique or piece of code without which the assignment seems difficult but with which the assignment becomes solvable or routine. This includes literal code and text. Obviously, this concept is impossible to define precisely, so you’ll have to use your discretion. If in doubt, ask us first before you share so you may avoid trouble later! Please also read our message about honesty. Team Project Instructions This year, most of the assignments for this class will be done in teams (pairs, with a single triple if enrollment is an odd number). Our assignments tend to be short on code but long on thinking, so this will give you the opportunity to fully discuss a solution with another person. You will work with three different people over the course of the semester. Programming in teams does not mean each person writes part of the code and the team simply pastes together these contributions. Each person is responsible for every line of code, documentation, etc. turned in. This responsibility includes getting or losing points for its quality, being able to explain it, and also incurring penalties in case of plagiarism or other violations. That is, all team members will get the same grade, and face the same sanctions: we will not partition credit or responsibility. For team projects, you may not discuss the assignment with a student not on your team. Since each team member must separately run the handin script for each programming assignment, we consider running the script the equivalent of signing the code. By handing in code, you acknowledge your responsibility for it in its entirety. Be sure your teammate has not changed or added anything without your knowledge prior to handing in. We recommend that teams develop the software together using pair-programming techniques (of the form preached by Extreme Programming), though this is a suggestion, not a requirement. Pair-programming in a nutshell: * Both programmers share a single computer, monitor, and keyboard. * One person is the typist, the other watches what is being typed and critiques it. * Programmers switch roles at regular intervals. (Note that this is also good for preventing RSI!) * Both programmers jointly own every single line of code, regardless of who typed it. While this does require that you schedule times to work with your team, we think that pair-programming will increase your productivity and aid you in taking responsibility for all of your code. Assignments are broken into groups. You will work with the same team for every assignment in a single group, and you may not work with anyone you worked with in a previous group. Once you have selected a partner please inform the course staff. If you are having difficutly finding someone to be your partner, please contact the course staff, and we will attempt to match you with another student. Coding Style We are very serious about requiring you to write clean, well-documented code. 20% of your grade for programming assignments will depend on your design, style, and comments. Since we expect that you document and test your code anyway, we think of this as giving you a free 20% for each assignment. Not already knowing Scheme or having learned Scheme with a different style are not excuses for not following these requirements. We are using the coding style from How To Design Programs for this course. * All functions must have a purpose statement that fully explains, in a sentence or two, what the function does. * All functions must have contracts. * If you need to use a new type, define a new datatype to represent it. Do not overload lists. Understand the difference between lists and datatypes. Lists are homogenous collections of unlimited extent. In contrast, datatypes are heterogenous collections with a fixed number of members. * As a general rule, all functions should be no longer than what fits on a screen. We will of course relax this for functions with a lot of pattern matching (parse comes to mind) and in that case recommend that each match case fits on a screen. * Assume that your reader understands Scheme, so, in any inline comments, explain why you wrote the code, don’t explain what you wrote. We consider define-type to be self-documenting. * Only use Scheme primitives that we have taught in this course. For example, use first and rest instead of car and cdr. Likewise, use local instead of let. Test Cases All functions must have tests that exercise non-trivial cases. We require this to encourage good software development skills, but, more importantly, to force you to show us that you know what your code is supposed to do and that you’re not getting a correct answer by guessing. We will not give full credit to untested functionality, even if it is correct! Good test cases: * Test a single aspect of a single feature. Therefore, you will need multiple test cases per feature to ensure its correctness. * Have a comment to explain their purpose. When writing test cases, resist the temptation to make them massive and complicated (the “this must be testing something” thinking). Instead, write small, clean tests with clear purposes. While a mega-test can be good for exposing errors you didn’t think to write focused tests for, make sure that, should your mega-test fail, you figure out what aspect of it triggered an error and write a smaller test for that. Codewalks We will use codewalks, a common practice at software companies, to evaluate some of your programs. A codewalk is a presentation where you, the programmer, convince us, a jury, of specific properties of your program. You accomplish this by presenting your program and answering questions about it We are most interested in * correctness: does it do the right thing?, * extensibility: how adaptable is it to related tasks?, * robustness: is it built like a house of cards?, and * performance: does it avoid poor implementation decisions?. Full Details…
Appears in Collections:Syllabus

Files in This Item:

File SizeFormat

All items in DSpace are protected by copyright, with all rights reserved.


Valid XHTML 1.0! DSpace Software Copyright © 2002-2006 MIT and Hewlett-Packard - Feedback