Comparative Programming Languages
.
Instructor: Greg Baker. Office hours: Thursdays 16:00–17:00, online.
TAs: to be announced.
Course web page: in CourSys https://coursys.sfu.ca/2020su-cmpt-383-d1/pages/
Welcome to online-only instruction.
My plan: change as little as possible from previous offerings.
Lectures will be pre-recorded.
In the lecture time, they will be available as a YouTube Premier
(≈ watch party) in ≈50 minute chunks. Greg (and the TAs?) will be available to answer questions during that time.
They will be available as regular YouTube videos for viewing later (for a limited time?).
Technology choices subject to change if they don't work, but my current plan:
Requirements for you:
Functional programming.
Programming language features.
Concurrent and parallel programming.
My big goals for the course:
Where the marks come from:
Compared to previous offerings: eliminated midterm and final exam; introduced quizzes and project.
There will be a short exercise due most Fridays: ten in total. Designed to reinforce basic ideas and force you to practice the concepts.
There will be one larger assignment for each major section of the course:
There will also be one quiz for each major section of the course, worth 8% each. Dates may change if necessary, but planned during lecture times:
The project will integrate ideas from the rest of the course.
It will involve creating a system with parts written in different languages and interacting with each other. You will need to choose appropriate languages to implement different components and have them communicate.
The project is new this semester.
Some optional books/references if you want them:
I'll add additional links to the course web site and/or lecture slides as appropriate.
To get credit for this course, I expect you to demonstrate that you know how to apply a variety of programming language concepts. That means:
Failure to do these may result in failing the course.
Academic Honesty: it's important, as always.
If you're using an online source, leave a comment.
def this_function(p1, p2):
# adapted from http://stackoverflow.com/a/21623206/1236542
...
If you work with another student, we shouldn't be able to tell from the results.
More details on course web site.
The quizzes are structured as regular tests: individual work, closed book, no outside references.
It will be hard to monitor that, but cheating on our quizzes will be treated as equivalent to cheating on an in-person exam, with corresponding penalties: I will be asking for a grade of FD in the course for any academic dishonesty on quizzes.
We're going to be looking at programming differently that you're (probably) used to, so we'll have to rethink our basic definitions too.
An old definition I used in CMPT 120:
An algorithm is an unambiguous sequence of instructions for solving a problem. A program is a description of an algorithm that a computer can understand.
i.e. a program is a sequence of instructions
.
Consider this instruction
in some programming language:
total = values.sum()
How is .sum() evaluated? Right to left? Left to right? In parallel on many cores?
There are many details of that instruction
that we didn't really specify. We left them to the language/library to figure out.
Some languages don't specify a sequence of steps. One you might be familiar with:
SELECT users.last_name, orders.date FROM users INNER JOIN orders ON user_id WHERE orders.date > today()
How does the database get you the results? You don't know (because it depends at least on the way the tables are indexed).
We will see more examples of languages that don't specify steps explicitly (in case you don't think SQL counts as programming
).
We are going to have to adjust our understanding of what a program
is.
The old
definition of programming was probably a good definition of imperative programming.
In an imperative program, the programmer gives an explicit series of steps that must be followed in order; variables represent the current state and are manipulated directly by the programmer.
e.g. C/C++, Java, C#, Python, JavaScript, …
But there's more to the world of programming. Previously-held assumptions that we'll see aren't always true:
In this course, we will explore some non-imperative languages. Declarative languages let you describe the results you want, but not the exact sequence of steps required to get there.
Examples of declarative (non-programming?) languages:
There is not a totally clear line between imperative and declarative languages.
That is, a programmer can often do declarative-like things in imperative
languages, and vice-versa.