Comparative Programming Languages

CMPT 383, Summer 2025

Greg Baker

https://ggbaker.ca/prog-langs/

This Course

Comparative Programming Languages.

Instructor: Greg Baker. Office hours: Wednesdays 12:00–13:00 and Fridays 10:00–11:00 in CSIL (ASB 9840).

TAs: see the course home page for details.

This Course

Course web page: in CourSys https://coursys.sfu.ca/2025su-cmpt-383-d1/pages/.

Lecture slides: https://ggbaker.ca/prog-langs/.

Lectures in-person. Audio recordings provided (best-effort: technical problems happen).

This Course

Whoever you are, I'm glad you're here.

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

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)

Safe programming, ownership, and concurrency.

… with Rust as a language that helps with all of this.
How can a language ensure safe programs (and safe in what sense)?
The compiler can give us a lot of assurances, if the language is designed for that.

Grades

Where the marks come from:

Weekly Exercises: 10 × 1.5% = 15%
Assignments: 10% + 15% + 10% = 35%
Midterm Exam: 10%
Final Exam: 40%

Late penalty: 20%/day.

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.

See CourSys for exact dates.

Assignments

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

functional programming + Haskell (10%)
programming language features (15%)
safe programming + Rust (10%)

Exams

All in-person on paper.

Midterm exam: 10% in week 8, Wed July 2 in lecture time.

Final exam: 40%, as scheduled by Student Services.

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.
A pass on the weighted average of the stuff where we know for sure you're doing the work yourself: midterm + final exam.

Failure to do these may result in failing the course.

Expectations

That rule isn't intended to fail someone just because they get 49% on the exams: it will be applied on an individual basis with a judgement call on the question has this student has demonstrated that they understand the basic concepts of 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

You are expected to do the work in this course yourself (or as a group for the project). Whenever you submit any work at the University, you're implicitly certifying this is my own independent work.

I take academic dishonesty seriously and penalties will reflect that.

Expectations

Examples of things that are not okay and will be treated as academic dishonesty:

Using a tool (e.g. an LLM) to create some code, cleaning it up a little, and submitting it.
Finding a solution (online or from your friend), looking at it until you really, really understand it, changing enough you think I won't notice the similarity, and submitting it.
Sitting beside your friend and creating a single solution together, even though you're touching different keyboards.

Expectations

The quizzes are regular tests: individual work, closed book.

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.