Syllabus
Instructor
- Name: David Grisham (‘David’, ‘Grish’)
- Office: Brown Building, 282
- Email: dgrisham@mines.edu
Office Hours
Office hours will be held in Brown Building 280B
- Tuesdays, 3:00-4:00 pm
- Thursdays, 2:00-3:00 pm
If you can’t make these hours, email me and we can schedule another time.
TA/Grader
- Name: Minh Vu
- Email: minhtvu@mines.edu
Course Info
- CID: CSCI 400
- Lecture: TR, 9:30-10:45 am
- Room: CT B60
- Website: https://dgrisham.github.io
Grading
| Percentage | Grade |
|---|---|
[90,100] |
A |
[80,90) |
B |
[70,80) |
C |
[60,70) |
D |
[0,60) |
F |
Course Description
The purpose of this course is to consider in detail the main constructs of modern programming languages and several paradigms, including imperative, functional, and object-oriented. We’ll also discuss some pragmatics of progrmaming.
Why study principles of programming languages?
- Ability to choose an appropriate tool for a given tak
- Enhance your ability to learn new languages
- Appreciate the challenges involved in implementing a language
- Expand your ability to express your ideas in a given language
- Because it’s fun!
Textbooks
- Miran Lipovaca. Learn You a Haskell for Great Good. Required (Free online)
- Flanagan & Matsumoto. The Ruby Programming Language. Recommended
- Robert Sebesta. Concepts of Programming Languages. Optional
Post-class Recommendation
- Bryan O’Sullivan, Don Stewart, John Goerzen. Real World Haskell.
Student Evaluation
- Ruby + Haskell Assignments: 45%
- Ruby Exam: 20%
- Haskell Projects: 25%
- Haskell Quizzes: 5%
- Class participation: 5%
- Meetup presentation is 40% of this (2% of the total)
Late Policy
Late assignments will be penalized 10% per day. For small assignments (less than 10 points), the late penalty is 1 point per day. No assignments will be accepted more than 2 days late. In-class exercises should be turned in before the start of the next class period.
Programs submitted for grading must run. Do not submit a buggy program that doesn’t run! It is much better to submit a working program that only meets part of the requirements. You are strongly encouraged to ask for help via Piazza. This is good experience, and will avoid receiving a 0 on homework assignments when you’ve put in many hours. If Piazza posts don’t provide sufficient help, I will also look at your program – but don’t wait until the last minute.
Collaboration Policy for Programming Projects in CS
The following policy exists for all CS courses in the EECS department. This policy is a minimum standard; your instructor may decide to augment this policy.
- If the project is an individual effort project, you are not allowed to give code you have developed to another student or use code provided by another student.\ If the project is a group project, you are only allowed to share code with your group members.
- You are encouraged to discuss programming projects with other students in the class, as long as the following rules are followed: a. You view another student’s code only for the purpose of offering/receiving debugging assistance. Students can only give advice on what problems to look for; they cannot debug your code for you. All changes to your code must be made by you. b. Your discussion is subject to the empty hands policy, which means you leave the discussion without any record (electronic, mechanical, or otherwise) of the discussion.
- Any material from any outside source, such as books, projects, and in particular, from the Web, should be properly referenced and should only be used if specifically allowed for the assignment.
- To prevent unintended sharing, any code stored in a hosted repository (e.g., on Github) must be private. For group projects, your team members may, of course, be collaborators.
- If you are aware of students violating this policy, you are encouraged to inform the professor of the course. Violating this policy will be treated as an academic misconduct for all students involved. See the Student Handbook for details on academic dishonesty.