CSCI400: Programming Languages
Where and When:
T/Th, 9:30-10:45, MZ 26
Office hours: T/Th, 8-9:15
This purpose of this course is to consider in detail the main constructs of modern programming languages, including abstraction mechanisms, sequence control, data control and storage management. The course will include a brief introduction to functional and logic programming. We'll also discuss some pragmatics of programming as time allows.
Why study principles of programming languages?
- To enhance your ability to learn new languages,
- To allow you to choose an appropriate tool for a given task,
- To gain an appreciation for the challenges involved in implementing a language,
- To expand your ability to express your ideas using a given language,
- To see some very different styles of programming (e.g., Ruby and Haskell),
- Because it's fun!
Miran Lipovaca, Learn You a Haskell for Great Good, Required (pdf available)
Flanagan & Matsumoto, The Ruby Programming Language, Recommended
Robert Sebesta, concepts of Programming Languages, Recommended
Course grading will be done on a plus/minus scale, with 93 to 100 as A, 90 to 92.9 as A-, 87 to 89.9 as B+, etc. I typically do not curve course grades. Participation score is based on class attendance, piazza posts, code sharing, submitting funny links, asking or answering questions in class, etc.
NOTE: Evaluation criteria modified this semester in response to student feedback.
Late Work and Grading Policy:
Late work is strongly discouraged. Late assignments will be penalized 10% per day and no assignments will be accepted more than 2 days late.
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 lots of hours. If piazza posts don't provide sufficient help, I will also look at your program. Don't wait til the last minute, though.
Piazza "Rules of Engagement" (thanks Randy B.)
Online forums can be quite intimidating. I'd like to suggest these guidelines:
- Be polite. This also applies to assignment clarifications (e.g., writing "This requirement makes no sense" may not be the best phrasing. Try something like: "I'm not clear what requirement X means. Should I do [x] or [y]?")
- A Piazza post is not a text message; use complete sentences and correct spelling, punctuation, and grammar.
- When asking a question, do not post large blocks of code. A single line of code, to clarify your question, may be appropriate. Before posting, ask yourself: would this be giving most of the answer to another student? Thinking about how to phrase the question may help you solve the problem.
- When answering a question, do not post the exact code
from your homework solution. Possible exception would be something
that takes one line and is primarily a syntax question.
E.g., to a question like "How do I set the
color of my rectangle" you might answer with something like
"You need to set the color before drawing. If
gis a Graphics object, you can do g.setColor(Color.CYAN);"
- Using pseudocode is an excellent way to answer questions.
We will make use of piazza for this course: https://piazza.com/mines/fall2014/csci400/home.
Collaboration Policy for Programming Projects in CS Courses
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:
- 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.
- 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.
Info on this page is also available on this syllabus, in case you prefer to print a copy.