Comparative Programming Languages

CMPT 383, Summer 2020

Greg Baker

https://coursys.sfu.ca/2020su-cmpt-383-d1/pages/

This Course

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/

Online Offering Strategy

Welcome to online-only instruction.

My plan: change as little as possible from previous offerings.

  • Don't remove material; don't add material.
  • Keep what can be done online.
  • Adapt the rest as best possible.

Online Offering Strategy

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?).

Online Offering Strategy

Technology choices subject to change if they don't work, but my current plan:

  • Lectures: YouTube.
  • Discussion forum: Piazza.
  • Office hours by video chat: Zoom (or ask in discussion).

Online Offering Strategy

Requirements for you:

  • A PC with a webcam.
  • … that is powerful enough to run a VM: at least 8 GB memory, 20 GB disk, reasonably decent processor (not too old, not a Celeron or other low-spec).
  • Windows, Mac, Linux all good.
  • A stable Internet connection.
  • Occasional participation during lecture time for quizzes. (∼3 times)

Topics (1)

Functional programming.

  • … with Haskell as the primary language.
  • What is functional programming?
  • Basics of Haskell and functional programming techniques.
  • Why is functional programming interesting?

Topics (2)

Programming language features.

  • What are the important differences between programming languages?
  • What factors might influence choice of language?
  • Why are there so many programming languages?

Topics (3)

Concurrent and parallel programming.

  • … with Go as an example where the language can help.
  • Why is concurrency hard? Does it have to be? How does the design of the language help/​hinder?

Overall Goals

My big goals for the course:

  • The world of programming languages is more interesting than just C++ and Java. It's good for you to see that.
  • Learning other programming languages can make you a better programmer, even if you only use Java/C++.

Grades

Where the marks come from:

  • Weekly Exercises: 10 × 1.5% = 15%
  • Assignments: 10% + 15% + 10% = 35%
  • Quizzes: 3 × 8% = 24%
  • Project: 26%

Compared to previous offerings: eliminated midterm and final exam; introduced quizzes and project.

Weekly Exercises

There will be a short exercise due most Fridays: ten in total. Designed to reinforce basic ideas and force you to practice the concepts.

Assignments

There will be one larger assignment for each major section of the course:

  1. functional programming + Haskell (10%)
  2. programming language features (15%)
  3. concurrent programming + Go (10%)

Quizzes

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:

  1. July 2 (Thursday of week 8)
  2. July 23 (Thursday of week 11)
  3. August 6 (Thursday of week 13)

Project

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.

References

Some optional books/​references if you want them:

I'll add additional links to the course web site and/or lecture slides as appropriate.

Expectations

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:

  • A pass on the weighted average of the stuff where you demonstrate programming ability: exercises + assignments + project.
  • A pass on the average of the quizzes.

Failure to do these may result in failing the course.

Expectations

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.

Expectations

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.

What is a program?

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.

What is a program?

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.

What is a program?

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.

What is a program?

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).

What is a program?

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.

Imperative Programming

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, …

Imperative Programming

But there's more to the world of programming. Previously-held assumptions that we'll see aren't always true:

  • Programs are made of statements/​instructions that are followed in order.
  • The programmer indicates what values to store in memory.
  • Programs are composed of functions/​methods/​procedures and classes/​objects.

Declarative Programming

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.

Declarative Programming

Examples of declarative (non-programming?) languages:

  • SQL: describe the records you want, joins to make, etc. The DB server figures out how to get those results.
  • XSLT: describe transformations on an XML document.
  • HTML, CSS, SVG, Makefiles, HTML template languages.

Declarative Programming

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.