1 / 20

CSE 341: Programming Languages, W inter 2004 Lecture notes: Monday 5 Jan 2004

CSE 341: Programming Languages, W inter 2004 Lecture notes: Monday 5 Jan 2004. Keunwoo Lee University of Washington klee@cs.washington.edu. Outline. Administrative info Homework What is this course about? Why study programming languages? Language design: goals, mechanisms, and principles.

gallia
Download Presentation

CSE 341: Programming Languages, W inter 2004 Lecture notes: Monday 5 Jan 2004

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 341: Programming Languages, Winter 2004Lecture 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 says Reading: • 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 • Languages are ways of thinking • Languages rank among the oldest and most thoroughly studied branches of computer science • Languages can be beautiful artifacts in their own right Hackish reasons • Languages in common use change over time • Nearly all large applications contain a domain-specific programming environment • 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 thought 2 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 Language design derives from human needs, so imagine human roles… low cost of development, timely delivery execution efficiency the end-user wants this from program… correctness portability …so the programmer might want this from language… ease of development (write-ability) ease of learning ease of debugging (error checking, tool support) control of machine resources ease of maintenance (readability, modularity) …and the language implementor might want this from the language. hiding or abstraction of machine resources ease of implementation (simplicity) clear language specification

  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

More Related