CSE 341 -- Why?

Besides a good introduction to a number of novel programming paradigms, CSE 341 intends to introduce you to a number of important concepts related to programming language design.

Why study programming languages?

To imagine a language is to imagine a form of life.

-- Ludwig Wittgenstein

The language we use ... determines the way in which we view and think about the world around us.

-- The Sapir-Whorf hypothesis

If you cannot be the master of your language, you must be its slave.

-- Richard Mitchell

What follows is a whirlwind tour of some of the concepts/topics we'll touch on throughout the quarter.

Control Abstractions

By the end of the course you should be comfortable with most of the following vocabulary.
Primitives
If, case, while, for, etc.
Procedural Abstraction
A group of statements that acts like a single statement
Functional Abstraction
Code that acts like an expression
Recursion
Functions that call themselves.
Parameter passing techniques
Call-by: value, result, value-result, reference, name. More here.
Higher order functions
Functions as first-class citizens: functions as data which can be dynamically created, passed around, invoked
Message dispatch in object oriented languages
Function call == selecting proper code to invoke based upon class of receiver(s)
Others
Parallelism, exceptions, iterators, concurrency

Data Abstractions

Primitives
User defined data types (ADTs)
Objects

Memory organization

Static, stacks, heaps, garbage collection. More here.

Types

Scoping

Static (lexical) vs. dynamic scoping. More here.

Evaluation

How do we evaluate a given programming language?

External Evaluation Criteria

The actual users of languages (industry, engineers, scientists, students, managers, secretaries) have certain demands on the languages they use. Most of these demands find their origins in the bottom line of the industrial world: money. One legitimate way to evaluate languages is to ask whether a given language meets the needs of a given user community.
Rapid development
Programmers are more expensive than machines, so they'd better be able to make fast progress.
Easy maintinence
Maintinence is expensive.
Reliability and safety
When computers go down, planes crash, phone systems break, nuclear reactors melt down, cash machines close. We'd like to avoid this.
Portability
I'd like my program to run on many different platforms, with minimal rewriting.
Efficiency
The compiler should be fast. The code itself should be fast.
Low training time (learnability)
The language should be easy to learn. Training is expensive.
Reusability
Writing software components once is cheaper than writing them twice.
Pedagogical value
The language should support and enforce the concepts you want to teach.

Internal Evaluation Criteria

Although the above demands are all important, we should still ask what makes a good language, independent of the demands of its users. This is a little like the question "What makes a good artwork?" as opposed to "What makes a good Hollywood movie?" Here are some qualities of a good language.
Readability
Understand what you, or someone else has written.
Writeability
Say what you mean, with a minimal amount of noise words.
Simplicity
The language should have a minimal number of primitive concepts/features.
Orthogonality
The language should support the combination of its concepts/features in a meaningful way.
Expressiveness
The programmer should be able to express their algorithm naturally.
Abstraction
The language should support a high level of data and control abstraction.

We will generally make use of these and other internal evaluation criteria when comparing languages.

dugan@cs.washington.edu (Last Update: )