1

CSE 341: Programming Languages, Winter 2004

Lecture notes: Monday 5 Jan 2004

Keunwoo Lee

University of Washington

klee@cs.washington.edu

2

Outline

• Administrative info

• Homework

• What is this course about?

• Why study programming languages?

• Language design: goals, mechanisms, and principles

3

Administrative info

• Official policies linked from web page:

http://www.cs.washington.edu/

education/courses/cse341/04wi/• Summary:

– You are responsible for knowing the course policies– HW: up to 4 late homework days over whole quarter– All work must be done individually unless otherwise noted– Exams: 1 midterm, 1 final; maybe pop quizzes (maybe never)– You are responsible for subscribing to the mailing list and checking

email once a day

4

Administrative info: people

• Lecturer: Keunwoo (pronounced, roughly “canoe”), klee@cs– Office hrs: Wed 10:30-11:30 am, Thu 2-3 pm,

and by appt. (don’t be shy)

• Grad TA: Sandra, sbfan@cs

• Undergrad TA: Andrew, stoneman@cs

5

Homework for Wed

Micro-Homework 1:• Go to the course web page• Find the Micro-Homework 1 assignment

and do what it saysReading:• From Ullman textbook:

– Chapter 1: skim whole chapter– Chapter 2: read up to end of Section 2.3

6

What is this course about?

• Programming languages, of course…– Syntax: surface form– Semantics: meanings of these forms

• …but also of programming systems, which encompass both languages and the following “pragmatics” which surround the language proper:– Programming environment: editor and tools– Standard library– “Culture”: common idioms, community

• Naturally, we will focus more on languages

7

Approximate course schedule

• ML: 3 weeks

• Scheme/DrScheme: 1 week

• Smalltalk/Squeak: 2 weeks

• Ruby/scripting: 1 week

• General topics: 2 weeks

• Recent languages research: 1 week

8

Why study (odd) programming languages?

Intellectual reasons

1. Languages are ways of thinking

2. Languages rank among the oldest and most thoroughly studied branches of computer science

3. Languages can be beautiful artifacts in their own right

Hackish reasons4. Languages in common use

change over time5. Nearly all large

applications contain a domain-specific programming environment

6. Need to evaluate competing programming tools

9

1. Languages as ways of thinking

Sapir-Whorf hypothesis: language determines the possible range of thought– Discredited for natural languages (Sapir & Whorf were

linguists), but may be true for PL

– Programmers labor under engineering constraints: limited resources may prevent expression in a given language

• e.g., Windows XP probably could not have been written in assembler, given human society’s resources ca. 2002

10

Language designs and thought2 examples of ways that language design shapes thought:

• Where does the language give the user control, and where does the language take it away?– Power entails the burden of responsibility

– E.g., with automated memory management, the programmer gives up some power, but gains freedom to ignore deallocation

• Where does the language enable the user to divide labor?– Humans manage complexity by dividing it into simpler pieces

– Languages’ primary tools for tackling complexity are their various abstraction mechanisms: for example, a function abstracts some computation, dividing use from definition

11

2. Languages & computer science

• Languages have been around almost as long as programming itself:– Individual languages embody a wealth of useful

design and engineering knowledge– Can learn from the successes and mistakes;

lessons applicable to many types of systems, not just traditional programming languages

– The field is mature, so much of this knowledge consists of “enduring truths”

12

3. Languages and beauty

• Some languages are beautiful and interesting artifacts in their own right.(There is no real way I can explain this to you; you simply must recognize it on your own, someday.)

13

4. Coping with evolution of programming practice

• Someday, languages in mainstream use today will be superceded by others…– 1993: Java does not exist.

– 1997: Massive Java section at Barnes & Noble

• The features that new languages incorporate are almost always old features from other languages

• Learning fundamental concepts of all languages enables you to quickly pick up new languages

14

5. Embedded and domain-specific languages

• Failed applications die. Successful ones grow until they become domain-specific programming environments…– office apps: MS Office/VBScript– web browsers: JavaScript– web servers: PHP, ASP, Apache modules, …– games: UnrealScript, QuakeC, …– user environments/shells: bash, VB, AppleScript, …– graphics/multimedia: GIMP Script-Fu, Shockwave/Flash, …– text editors and development tools: Emacs, Eclipse

• Language inevitably constitutes part of this programming environment

• Someday, when you lead a project team, what will you do?

15

6. Evaluating competing programming technologies

• Snake oil abounds in programming tools• Choosing the right tools can make a huge

difference in productivity• How can you evaluate programming technologies?

– Vendor “literature”?– The ill-informed, fad-obsessed technology press?– The opinion of your friends?

• A broad understanding of languages is crucial to enable you to judge for yourself

16

Language design:Fundamental questions

• What should a language accomplish?

• How can those goals be achieved?– What mechanisms can be applied? – What principles guide the selection and

application of these mechanisms?– Since not all goals are simultaneously

achievable, how do we compromise among them?

17

Language design goals

the end-user wants this from program…

Language design derives from human needs, so imagine human roles…

correctnessexecution efficiency

portability

…so the programmer might want this from language…

ease of implementation

(simplicity)

…and the language implementor might want this from the language.

clear language specification

low cost of development, timely

delivery

ease of debugging

(error checking, tool support)

ease of development (write-ability)

ease of maintenance (readability, modularity)

ease of learning

control of machine resources

hiding or abstraction of

machine resources

18

Language design mechanisms• Control:

– Local control: sequences, branches, loops– Non-local control: exceptions, continuations– Control abstractions: functions, dynamic dispatch– Recursion– Parallelism: threads, futures, …– Backtracking

• Data:– Primitives: integers, etc.– Compounds: tuples, vectors/arrays, records– Data abstractions: user-defined data types, objects– Recursive data types– Polymorphism– Static typing, dynamic typing, type inference– Eager/lazy evaluation

19

Language design principles (1)

• Readability/writeability• Simplicity

– “Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.” --- Scheme R5RS

20

Language design principles (2)

• Orthogonality– A + B = A + B. When you have two distinct concepts, combining

them should be possible, and yield a natural result.

– Avoid overlapping concepts. A language with two similar concepts should eliminate one, or merge the two. Each concept should “do one thing, and do it well” (to quote the classic Unix design principle).

• Expressiveness– Programmer should be able to say all (s)he wishes to say

– Programmer should not have to say more than (s)he wishes to say