1 / 58

preparation

preparation . start drscheme set language level to Beginner open in Presentations length1.ss length2.ss icons.ss planets0.ss convert.ss add teachpack convert.ss. How to Produce the Best OO Programmers: By Teaching Program Design. Matthias Felleisen Rice University Houston, Texas.

clarke-chan
Download Presentation

preparation

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. preparation • start drscheme • set language level to Beginner • open in Presentations • length1.ss • length2.ss • icons.ss • planets0.ss • convert.ss • add teachpack convert.ss

  2. How to Produce the Best OO Programmers:By Teaching Program Design Matthias Felleisen Rice University Houston, Texas

  3. Current Practice in Introductory Courses • teach the syntax of a currently fashionable programming language • use Emacs or commercial PE • show examples of code and ask students to mimic • discuss some algorithmic ideas (BigO)

  4. Current Practice: Syntax and PEs pointer manipulation In you favorite C++ or Java programming environment: wage_per_hour * number_of_hours = total_wage

  5. Current Practice: Design vs Tinkering/O • syntax: tinker until it works • design: tinker until it works, too • teaching standard algorithms doesn’t replace a discipline of design • analyzing algorithms doesn’t say how we should design programs

  6. Lessons: The Trinity • simple programming language • programming environment for beginners • a discipline of design: classes of data

  7. TeachScheme! We have developed this trinity for Scheme

  8. TeachScheme! is not MIT Scheme! • not MIT’s Scheme • not MIT’s programming environment • most importantly: not MIT’s non-design • SICP fails the normal student • SICP fails to convey the central role of design • SICP has an outdated idea of OO programming

  9. Part I: The Programming Language

  10. Programming Language: Scheme • Scheme’s notation is simple: • (, operation, operands, ) • Scheme’s semantics is easy: • it’s just the rules of mathematics: 1+1 = 2 • With Scheme, we can focus on ideas

  11. Programming Language: Scheme Again simple syntax simple semantics powerful PE rich language it’s a lie! more lies! do you believe this? so where are the GUIs?

  12. algebraic syntax length1 returns 0, no matter what input

  13. more algebraic syntax an error message concerning procedures, whatever those things are

  14. Syntax is a Problem • simple notational mistakes produce strange results -- without warning • simple notational mistakes produce error messages beyond the students’ knowledge • … and even in Scheme there are just too many features

  15. Programming Languages: Not One, Many • language 1: first-order functional PL • function definition and application • conditional expression • structure definition • language 2: local function definitions • language 3: functions and effects • higher-order functions • set! and structure mutation • begin

  16. Programming Languages • arrange programming language in pedagogic layers • put students into a knowledge-appropriate context • focus on design ideas relative to this context

  17. Part II: The Programming Environment

  18. On to the Programming Environment • one PE for all language levels • the PE must allow instructors to supplement code at all levels --- even if the code does not conform to the level • the PE must enable interactive exploration

  19. DrScheme: Beginner Level • error message due to restricted syntax • check syntax • pictures are values [if time] • teachpacks

  20. Part III: Design Recipes

  21. Program Design for Beginners • foster basic good habits • the design is rational • its steps explain the code’s structure • the design focuses on classes of data • the process is accessible to beginner

  22. Design Recipes to be designed in out How do we wire the “program” to the rest of the world? IMPERATIVE: Teach Model-View Separation

  23. Design Recipes • the programming environment must support extreme separation of view and model • demonstrate temperature conversion

  24. The Basic Design Recipe • data analysis and class definition • contract, purpose statement, header • in-out (effect) examples • function template • function definition • testing, test suite development

  25. Design Recipes: Class Definitions • use rigorous language, not formalism • naïve set theory • basic sets: numbers, chars, booleans • intervals on numbers • (labeled) products, that is, structures • (tagged) unions • self-references • vectors (much later)

  26. Design Recipes: Class Definitions (2) (define-struct spider (name size legs)) A spider is a structure: (make-spider symbol number number)

  27. Design Recipes: Class Definitions (3) • A zoo animal is either • a spider • an elephant • a giraffe • a mouse • … • Each of these classes of animals has its own definition

  28. Design Recipes: Class Definitions (4) • A list of zoo animals is either • empty • (cons animal a-list-of-zoo-animals) • Let’s make examples: • empty (by definition) • (cons (make-spider ‘Asterix 1 6) empty) • (cons (make-spider ‘Obelix 99 6) (cons … …))

  29. Design Recipes: Class Definitions (5) (define-struct child (name father mother)) • A family tree is either • ‘unknown • (make-child symbol a-family-tree a-family-tree-2) Many, if not most, interesting class definitions are self-referential.

  30. Design Recipes: Templates • a template reflects the structure of the class definitions (for input, mostly) • this match helps designers, readers, modifiers, maintainers alike

  31. Design Recipes: Templates (2) is it a basic class? is it a union? is it a structure? is it self-referential? “domain knowledge” case analysis extract field values annotate for recursion

  32. Design Recipes: Templates (3) • A list of zoo animals is either • empty • (cons animal a-list-of-zoo-animals) ;; fun-for-zoo : list-of-zoo-animals -> ??? (define (fun-for-zoo a-loZA) … ) is it a union?

  33. Design Recipes: Templates (4) • A list of zoo animals is either • empty • (cons animal a-list-of-zoo-animals) ;; fun-for-zoo : list-of-zoo-animals -> ??? (define (fun-for-zoo a-loZA) (cond [ <<condition>> <<answer>> ] [ <<condition>> <<answer>> ])) what are the sub-classes

  34. Design Recipes: Templates (5) • A list of zoo animals is either • empty • (cons animal a-list-of-zoo-animals) ;; fun-for-zoo : list-of-zoo-animals -> ??? (define (fun-for-zoo a-loZA) (cond [ (empty? a-loZA) <<answer>> ] [ (cons? a-loZA) <<answer>> ])) are any of the potential inputs structures?

  35. Design Recipes: Templates (6) • A list of zoo animals is either • empty • (cons animal a-list-of-zoo-animals) ;; fun-for-zoo : list-of-zoo-animals -> ??? (define (fun-for-zoo a-loZA) (cond [ (empty? a-loZA) … ] [ (cons? a-loZA) … (first a-loZA) … … (rest a-loZA) … ])) is the class definition self-referential?

  36. Design Recipes: Templates (7) • A list of zoo animals is either • empty • (cons animal a-list-of-zoo-animals) ;; fun-for-zoo : list-of-zoo-animals -> ??? (define (fun-for-zoo a-loZA) (cond [ (empty? a-loZA) … ] [ (cons? a-loZA) … (first a-loZA) … … (rest a-loZA) … ]))

  37. Design Recipes: Defining Functions • templates remind beginners of all the information that is available • which cases • which field values, argument values • which natural recursions are computed • the goal of function definitions is • to compute with the available values • to combine the computed effects

  38. Design Recipes: Overview • basic data, intervals of numbers • structures • unions • self-reference in class description • several different cases [all one recipe] • mutual references • generative recursion • special attributes: • accumulators • effects • abstraction of designs

  39. Design Recipes: Conclusion • get students used to discipline from DAY ONE • use scripted question-and-answer game until they realize they can do it on their own • works well as long as class definitions are “standard”

  40. Part IV: From Scheme to Java Training OO Programmers

  41. On to Java: What is OO Computing?

  42. Scheme to Java: OO Computing focus: objects and method invocation basic operations: creation select field mutate field select method via “polymorphism” structures and functions basic operations: creation select field mutate field recognize kind f(o) becomes o.f()

  43. Scheme to Java: OO Programming develop class and interface hierarchy allocate code of function to proper subclass develop class definitions allocate code of function to proper cond-clause

  44. Scheme to Java: Class Hierarchy List of zoo animals Empty Cons: animal list of zoo animals • A list of zoo animals is either • empty • (cons animal a-list-of-zoo-animals)

  45. Scheme to Java: Code Allocation List of zoo animals Empty: Cons: animal list of zoo animals ;; fun-for-zoo : list-of-zoo-animals -> ??? (define (fun-for-zoo a-loZA) (cond [ (empty? a-loZA) ] [ (cons? a-loZA) … (first a-loZA) … … (rest a-loZA) … ]))

  46. Scheme to Java: Ketchup & Caviar abstract class List_Zoo_Animal { int fun_for_list(); } class Cons extends List_Zoo_Animal { Zoo_Animal first; List_Zoo_Animal rest; int fun_for_list() { return 1 + rest.fun_for_list(); } } class Empty extends List_Zoo_Animal { int fun_for_list() { return 0; } }

  47. Scheme to Java: Ketchup & Caviar abstract class List_Zoo_Animal { int fun_for_list(); } classCons extends List_Zoo_Animal{ Zoo_Animal first; List_Zoo_Animal rest; intfun_for_list() { return 1 + rest.fun_for_list(); } } classEmpty extends List_Zoo_Animal{ intfun_for_list() { return 0; } }

  48. Scheme to Java • the design recipes work step for step for the production of OO programs • the differences are notational • the differences are instructive

  49. Why not just Java first? • complex notation, complex mistakes • no PE supports stratified Java • design recipes drown in syntax

  50. Part V: Experiences

More Related