Syllabus

Goals

Successful course participants will:

  • Confidently define, describe, and apply the precise meaning of functional and object-oriented programs

  • Develop the skills necessary to learn new programming languages quickly

  • Master many specific language concepts such that they can recognize them in strange guises and use them effectively to build correct and elegant software

  • Learn to evaluate the power and elegance of programming languages and their constructs

  • Attain reasonable proficiency in the OCaml and Racket languages — and, as a by-product, become more proficient in languages they already know

Inclusiveness

You should expect and demand to be treated by your classmates and the course staff with respect. You belong here, and we are here to help you learn and enjoy a challenging course. If any incident occurs that challenges this commitment to a supportive and inclusive environment, please let the instructor know so the issue can be addressed. The Allen School also has a variety of ways to report problems and give feedback you should be aware of and use as needed.

Grading

  • Seven homework assignments, combined worth 70% of your final grade. Please make sure your homework submissions compile and run without crashing! Submissions that do not compile will be penalized 30%.

  • Two in-person exams (midterm and final), combined worth 30% of your final grade.

Late Policy


All homework is due at 5:00pm Pacific Time on the due date.


You can use up to two late days for each assignment. Submitting any time after the deadline uses at least one full late day. No credit will be granted after two late days. Course staff will not be answering homework questions on the discussion board during the two day period after it is due. They will answer questions during office hours, but if a homework is due on a Friday there will not be office hours during the next two days.


You are strongly advised to turn homework assignments in early to avoid any issues due to emergencies. Do not skip class or section to work on homework — this will cost you time in the long run.


If unexpected personal circumstances cause you to fall behind more than this lenient late-day policy allows, reach out to the instructor.

Collaboration Policy / Academic Integrity

You are encouraged to discuss the homework assignments with your classmates. However, the work you submit must be your own:

  • Do not look directly at anyone else's work or solution, including work found online or from students in previous versions of CSE 341.

  • Do not use AI-assistance such as GitHub Copilot, ChatGPT, etc.

  • Do not turn in work you did not complete yourself independently.

  • Do not show your work or solution to anyone else.

  • Do not put your work in a publicly available place.

Any attempt to misrepresent the work you did will be dealt with via the appropriate University mechanisms. Please also carefully review the UW College of Engineering Academic Misconduct Process which provides the following policy:


Engineering is a profession demanding a high level of personal honesty, integrity and responsibility. Therefore, it is essential that engineering students, in fulfillment of their academic requirements and in preparation to enter the engineering profession, shall adhere to the University of Washington’s Student Code of Conduct.


Any student in this course suspected of academic misconduct (e.g., cheating, plagiarism, or falsification) will be reported to the College of Engineering Dean’s Office and the University’s Office of Community Standards and Student conduct. (See CoE website for more detailed explanation of the academic misconduct adjudication process). Any student found to have committed academic misconduct will receive a 0-grade on impacted academic work (e.g., assignments, project, or exams).

If there is any chance you have violated any aspect of this policy, you must clearly indicate in your submission what work was not entirely your own. If you do, the worst that will happen is you may lose some points on an assignment. This is much better than the alternative.

Challenge Problems

  • Challenge problems are designed to have little (but some) impact on your grade whether you do them or not.

  • Challenge problems provide an opportunity to work on something interesting and optional.

  • Challenge problems will typically allow you to get approximately 5% of additional credit on an assignment, yet they will typically be much more difficult than this credit amount suggests.

  • You should only attempt a challenge problem after finishing the rest of an assignment.

  • Challenge problems may be less carefully specified and less carefully calibrated for how difficult/time consuming they are.

Attendance

Both lecture and section are designed for synchronous participation, i.e., you should plan to come to class and we expect you to be there. We will record lecture for your review and in case you need to miss class, and we post all the materials we use in class and section.

As much as synchronous participation is in some ways irreplaceable, you should not come to class if potentially contagious.

Based on many years of experience teaching this class, you will learn much more and enjoy the course much more if you attend every day and stay up-to-date on the material. Searching around for the information you need to complete the homework minimally will set you up to do poorly on the exams and, more importantly, miss the opportunity to learn what this course is about -- the material builds a "grand vision" of computer programs; it's not a pile of facts to be searched.

More Advice

  • Your instructor aims for lecture and section to be some of the most enriching hours of your college career. We will start promptly, and you should arrive punctually and well-rested.

  • In every course, there is a danger that you will not learn much and thus lose the most important reason to take the course. In 341, this danger is heightened because it is easy to get “distracted by unfamiliar surroundings” and never focus on the concepts you need to learn. These surroundings include new syntax, editors, error messages, etc. Becoming comfortable with them is only one aspect of this course, so you must get past it. When we use a new language or feature, you must spend time on your own “getting comfortable” in the new setting as quickly as possible so you do not start ignoring the course material.

  • If you approach the course by saying, “I will have fun learning to think in new ways,” then you will do well. If you instead say, “I will try to fit everything I see into the way I already look at programming,” then you will get frustrated. By the end, it will relate back to what you know, but be patient.

Accommodations

Please refer to university policies regarding disability accommodations or religious accommodations.

Topics (in rough order and subject to modest change)

  1. Syntax vs. semantics vs. idioms vs. libraries vs. tools

  2. OCaml basics (bindings, conditionals, records, functions)

  3. Recursive functions and recursive types

  4. Benefits of no mutation

  5. Algebraic datatypes, pattern matching

  6. Tail recursion

  7. Higher-order functions; closures

  8. Lexical scope

  9. Currying

  10. Syntactic sugar

  11. Equivalence and effects

  12. Parametric polymorphism and container types

  13. Type inference

  14. Abstract types and modules

  15. Racket basics

  16. Dynamic vs. static typing

  17. Laziness, streams, and memoization

  18. Implementing languages, especially higher-order functions

  19. Macros

  20. Eval

  21. Abstract types via dynamic type-creation and simple contracts

  22. Object-oriented programming is dynamic dispatch

  23. Pure object-orientation

  24. Implementing dynamic dispatch

  25. Multiple inheritance, interfaces, and mixins

  26. OOP vs. functional decomposition and extensibility

  27. Subtyping for records, functions, and objects

  28. Class-based subtyping

  29. Subtyping vs. parametric polymorphism; bounded polymorphism


To learn these topics using real programming languages and well-suited for them, we will use:

  • OCaml (a statically typed, mostly functional language) (approximately 5 weeks)

  • Racket (a dynamically typed, mostly functional language) (approximately 5 weeks)


There are thousands of languages not on this list, many programming styles not represented, and many language constructs and concepts that would be great to study, but 10 weeks is short! The languages above will serve as representatives for entire programming styles and paradigms.