ITEC 380 2019spring ibarland

home—lectures—recipe—exams—hws—D2L—breeze (snow day)

Programming Languages
ITEC380, 2019spring

ITEC380 is an introduction to the study of programming languages. Topics include:

• History of programming languages
• Brief survey of programming paradigms
• Functional languages, and functions as values
• Declarative, non-algorithmic languages
• Declaration models (binding, visibility, scope, and lifetime)
• Writing recursive function over recursive data (lists, trees)
• Parsing (concrete and abstract syntax, abstract syntax trees)
• Application of context-free grammars in recursive-descent parsing
• Assigning semantics to a parse tree

• Describe the salient characteristics of several language paradigms (procedural, object-oriented, imperative, declarative/logic, functional), and write small programs in each paradigm.
• Distinguish between syntactic issues and semantic issues in programming languages, use formal techniques (such as BNF) in the specification of language syntax and the construction of language parsers, and explain and modify code that assigns semantics to parse trees.
• Describe, and discuss the effects of, different forms of variable binding, scoping, and lifetime.
• Define type safety, static and dynamic typing, explicit and implicit type declarations and coercions, and function types; and describe their roles in program development

Course Information, 2019spring

• Time/Place: TH 14:00–15:15, Young 406.
• Instructor info Ian Barland, , Davis 230.

• Office hours: You don’t need an appointment to drop by during scheduled office hours. These hours (if printed) are subject to change; see the class web page for the most up-to-date times.
  

  MW	10:00–11:30
  MW	14:30–15:30
  Tu	15:30–16:30
  or email me some times that work better for you (incl. weekend breeze chat, possibly).

  You are encouraged to post (and answer) questions on the D2L discussion board, since you might get another student’s ideas within a few minutes, instead of my response perhaps a day or more later. If your question requires giving away part the answer (e.g. part of your solution), feel free to email me; please include “ITEC380” in the subject, thanks.

• See (and bookmark) D2L for: news, discussions, dropbox, quizzes, grades. This web page’s navbar links are intended for all handouts: mostly lectures and homework files. Announcements (including clarifications or changes to homeworks or course policies) will be made on the D2L discussion boards; you are expected to subscribe to them (click on the "Subscribed" star at the top of each forum).
• Text

  Author:	Michael Scott
  Title:	Programming Language Pragmatics
  Publisher:	Morgan Kauffman (Elsevier)
  Edition:	(see Note below)	4th ed	3rd ed	2nd ed
  ISBN:		978-0-1241-0409-9	978-0-1237-4514-9	978-0-1360-7347-5
  Note:	You are welcome (even encouraged) to get a used copy the textbook. Newer editions are improvements (mostly with more examples and self-exercises), but if your budget is tight you can get an older edition.
  optional text	How well do you know Java? The following has nearly 100 one-page puzzles, each illustrating how language design choices can have unintended consequences. Fun bedtime reading.
  Author:	Joshua Bloch and Neal Gafter
  Title:	Java Puzzlers: Traps, Pitfalls, and Corner Cases
  Publisher:	Addison Wesley
  ISBN:	978-0-3213-3678-1

• Evaluation:

  Exams (2) & Quizzes	40%
  Homeworks	60%

  Clarity counts in all work for this class (including spelling, grammar, and layout). All submitted material (hardcopy or electronic) must contain both your name and the hw/quiz/exam-number near the top. Any hardcopy submitted must be stapled. If something is due both on-line and hardcopy, the hardcopy must be turned in by the start of first lecture on/after the electronic deadline.

  Programs will be graded not only for the extent to which they produce the required results, but also for good style. In particular, the code should be well designed, straightforward and use meaningful identifier names. Every function should have a purpose-statement, signature, and unit tests. A program which does not compile/run might summarily get a 0. (Beware making a last-moment change right before submitting, without verifying that it still passes all unit tests.)

  There will be some short quizzes in class; fair game for these quizzes include definitions and examples from the assigned reading, as well as any previous homework problems.

  Final Exam: 2019.May.07 (Tue) 14:45, as per the final exam schedule. In case of inclement weather, the university may move the exam-slot to Friday, May.10.

• Late Policy: Any hardcopy is due at the start of class on the due-date. No late homework is accepted, except that hardcopy ≤10min late will be assessed a 5% penalty. If you know in advance you won’t be able to turn in homework on time (e.g. military duty, or university sports) you must get permission in advance to turn the homework in late. For significant illness, family crisis without advance notice (but with later documentation), contact the professor as soon as possible to arrange to catch up on the work.

  You cannot make up any missed in-class quizzes.

• Campus Closings In the event of a University-wide emergency or unscheduled close (as for inclement weather¹), we will instead hold class virtually via Breeze (link at top of class pages). In the case of a multi-day emergency or closure, the course policies on this page are subject to change. Monitor D2L and this course web page for any announcements.
• Honor Policy: As with all your RU classes, the university honor code governs all work done for the course. You are encouraged to discuss and interpret the homeworks and general approaches to solutions with your fellow students. However, you must be the direct, sole author of all your submitted work; everything submitted must come from your own head.

  You may not:

  • You may not: receive homework code from others (electronically or otherwise), have others type in any code for you, or show your code to other students for help (except as mentioned below),
  • You may not: copy/paste code or otherwise electronically copy from any source other than the course website (for the current semester only) and textbooks. Any old solution-sets to previous semester’s problems are off-limits, and should be mentioned to the teacher (even if anonymously).
  • You may not: allow others to copy your work (knowingly, or unknowingly due to not taking reasonable measures to secure your work — e.g. printing to a lab printer but not picking up the hardcopy promptly, or making your files readable to others on a filesystem that others have access to).
  • You may not: violate the standards of student conduct, in particular items 1–9 of Section 5D (pp.8–9).

  You may:

  • You may: ask others what a compiler message means, including (if needed) the one line causing the problem. (This provision is for syntax-errors only, not code-not-doing-what-you-want.)

  • You may: Search the web for solutions to small coding tasks (1–3 lines) which are not the gist of the assignment.
    (Even if finding code snippets on the web, you must type them in yourself from memory, not copy/paste them. This is to (a) help you process/think about the code you are typing, and also (b) help keep you from inadvertently copying so much that you’d violate the honor policy. If you think an exception is reasonable, check with the instructor (perhaps via the message-boards).)

    For example, if the assignment is to write a CPU simulation, and happens to involve reading/writing a preferences file, you can certainly search up a sample program which opens a file, reads or writes the words "hello file", and then closes the file (catching any exceptions).

    However, if one of the assignment’s problems is to write code which copies one file to another while filtering out all punctuation, up-casing all words, and adding a "#" in front of each numeral you should not search up a program which does all/most of that. (Combining samples that do each of these independently is fine.)

  • You may: talk through a homework problem with a friend, even writing down things. However you must re-write your solution entirely on your own, without referring to any notes/files from such sessions.

    Again, the ultimate requirement is that everything you end up writing should be coming from your own understanding, (not just writing from short-term memory, what somebody else said would work).

  • You may: freely access/use all material on this course’s web pages, any textbooks, general language/library references, and web-tutorials (but only copy/pasting things from the first two of these).
  • You may: discuss/show your code with the professor, other faculty, and on-duty peer instructors. (Cite, if you feel the contribution goes beyond general, reasonable understanding.)
  • You may: ask on the course’s D2L discussion boards, asking about how to approach a problem or why you might be getting a certain error or undesired behavior. Your question may include small bits of your code (1–2 lines), but not large sections.
  • You may: omit citations for examples/code-snippets/ideas from: lectures, the course web-site for the semester, the course textbook, and official language/library documentation. (You do need to cite sources such as wikipedia, stack overflow, and help from friends.)

  If you got significant advice which you’d like to credit somebody for (e.g. a stackoverflow answer²), cite them in your work with an inline comment which includes the URL.

  If you aren’t sure whether a certain level of help is acceptable, or feel that an exception to these rules is reasonable, stop—don’t give/receive such help until you've clarified it with the instructor. (Starting assignments early enough can give you better opportunity to get help/clarification, should it be needed.)

• Class Courtesy Please refrain from texting during lecture, and use a computer only for taking notes and looking up material related to lecture (e.g. looking up how foldr differs from foldl). Please do not: check email, browse other sites, check your phone, etc.. Other students can be distracted by your screen, and your inattentiveness detracts from the class experience for all.

• Other University Resources: Radford has many resources to help you in different ways, including the student counseling services (x5226), and the Harvey Knowledge Center (“HKC”, formerly “LARC”, x7704, radford.edu/hkc ) including access to tutorTrac.

  Students seeking academic accommodations under the Americans with Disabilities Act must register with RU’s Center for Accessibility Services (CAS) to determine eligibility. Students qualified for academic accommodations will receive accommodation letters and should meet with each course professor during office hours, to review and discuss accommodations. For more information, call 540-831-6350.

home—lectures—recipe—exams—hws—D2L—breeze (snow day)

This page licensed CC-BY 4.0 Ian Barland Page last generated

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu