Samth.github.io

From Principles to Practice with Class in the First Year We propose a bridge between functional and object-oriented programming in the first-year curricu-lum. Traditionally, curricula that begin with functional programming transition to a professional,usually object-oriented, language in the second course. This transition poses obstacles for students,and often results in confusing the details of development environments, syntax, and libraries withthe fundamentals of OO programming that the course should focus on. Instead, we propose to beginthe second course with a sequence of custom teaching languages which minimize the transition fromthe first course, and allow students to focus on core ideas. After working through the sequence ofpedagogical languages, we then transition to Java, at which point students have a strong command ofthe basic principles. We have 3 years of experience with this course, with notable success.
Many universities and colleges aim to teach their students proficiency in an industrial object-orientedprogramming language by the end of the students’ first year. The most common approach to achievethis aim is to teach an industrial language in the first course, often Java, starting on the first day. Othercurricula take a more indirect route by teaching functional programming in the first semester, followedby a second semester in Java. The latter approach is an improvement over the first, as pointed out bynumerous observers but both suffer serious flaws.
As an example, Northeastern University teaches introductory programming in the first semester using How to Design Programs followed by object-oriented programming using How to DesignClasses in the second semester. This sequence was designed to provide a smooth path for incomingstudents with a competence in high-school level algebra to reach proficiency in Java by the end of theirfirst year It was a major improvement over the previous Java-first curriculum in terms of studentsuccess, attrition, and preparation for subsequent courses However, significant problems remain; inparticular, the second semester course violates the designers’ own principles (as recalled in 1. introduce only those language constructs that are necessary to teach programming principles, and 2. choose a language with as few language constructs as possible, and one in which they can be The problem is that the first semester ends with an advanced pedagogical functional language and the second semester starts with Java, although it focuses on a side-effect free subset. Despite this focusedsubset, this transition is too abrupt to meaningfully bridge the gap between functional and object-orientedprogramming, because several other significant transitions happen in concert: • from a highly regular and minimal syntax to a complicated irregular syntax, • from an untyped language to a typed language, • from a pedagogical programming environment (DrRacket) to a professional programming envi- From Principles to Practice with Class in the First Year • from a language with numeric values corresponding to mathematical objects to a language with numeric values corresponding to common machine • from a language with image literals and graphical libraries to one in which graphical programming • from an interaction-oriented language and tool suite to a compiled, batch-oriented language.
This abrupt transition has several negative consequences which we have experienced first-hand: the principles of object-oriented programming are obscured and de-emphasized, struggling with the pro-gramming environment is frustrating and can cause potentially good students to leave the program, itfavors students with prior exposure to the particular tools (a set that is demographically skewed), it in-hibits students from experimenting by allowing them to rely upon past skills, and it creates the falseimpression that courses are discrete units of instruction that can be discarded after successful completionrather than being part of a continuous and cumulative educational experience.
We contribute an alternative approach to the second semester that overcomes these problems and provides a gradual introduction to object-oriented programming. Our approach starts the second semesterby introducing only the concept of programming with objects, while all other aspects of the course remainwhere they were left off in the previous semester. This allows other concepts to be introduced at the pointat which they are relevant and motivated. Despite this more gradual approach, the course accomplishesthe goal of reaching industrial language competence by the end of the semester, covering a super-set ofthe concepts and topics covered in the How to Design Classes-based course.
The remainder of this paper is organized as follows: section provides background on How to Design Programs and the context and constraints involved in the first year at Northeastern. Section describes our approach to the second semester, which starts with a small shift in perspective to bridgethe gap between functional programming and object oriented programming. Section describes thepath from our pedagogical languages to an industrial object-oriented programming language. Section discusses the relation to existing work and section concludes.
At Northeastern, the College of Computer & Information Science (CCIS) requires a four course introduc-tory sequence for Computer Science majors in the first year. The first semester features both a course ondiscrete mathematics and an introduction to programming following the How to Design Programs cur-riculum. The second semester follows with a course on object-oriented programming and one featuringformal reasoning about programs, both on paper and with the ACL2 theorem prover After the first year, students take a wide variety of follow-up courses, ranging from a required course in “Object-oriented design” to architecture, operating systems, robotics, and programming languages.
No standard language is used in these courses.
More significantly, Northeastern distinctively emphasizes experiential education, with almost all Computer Science majors participating in a 6 month “co-op” internship after their third semester. Theseco-ops take place at a wide variety of companies, and while most students do some software develop-ment, there is no single platform or set of tools that commands majority use. In particular, there is wide 1While this may seem like a minor point, details of numeric representation can crop up quickly in a Java-based course—for example, 1/3 cannot be represented by any Java numeric types.
variation in the languages students use while on co-op. This combination sets the constraints under whichwe designed our approach.
In the first semester, students are introduced to the “design recipe”, a step-by-step process for going fromEnglish descriptions of problems to working programs. The design recipe involves six steps: 1. Analyze the information involved in the problem and express how to represent it as data.
2. Write down a function signature, a summary of the purporse of the function, and a function stub.
3. Illustrate the signature and the purpose statement with some functional examples.
4. Take an inventory of the input data that can be used to compute an answer.
6. Verify the behavior of the program against the functional examples given earlier.
Students explore program design using this process in the context of a series of successively richer pedagogical programming language levels that are included in the DrRacket (formerly DrScheme)programming environment The language and environment include several tools in support ofthe design recipe. For example, functional examples can be written as executable tests by writtingcheck-expect expression an algebraic stepper and REPL are provided to interact with programsat each step of the design process.
Finally, the first semester course makes extensive use of a library for developing interactive anima- tions and games using functional programming and functional graphics After the second course, students should both (a) be prepared for subsequent courses in the curriculum,which expect familiarity with Java and standard Java libraries, (b) be prepared for co-ops in which theywill use professional-grade languages and tools which will almost certainly be object-oriented. Moresignificantly, we aim to teach the key insights behind the object-oriented approach to program design.
These constraints, while in detail specific to Northeastern and the CCIS curriculum, are broadly similar to the requirements for the first year at many universities. Our course also attends to smaller andmore idiosyncratic elements of our curriculum, ranging from formal reasoning to algorithmic analysis,as described in the following sections.
On the first day of the second semester, we introduce a single linguistic concept to an otherwise un-changed context of the previous semester: the idea of an object. An object is a new kind of value thatcan, as a first cut, be understood as a pairing together of two familiar concepts: data and functionality.
• An object is like a structure in that it has a fixed number of fields, thus an object (again, like a structure) can represent compound data. But unlike a structure, an object contains not just data,but functionality too; • An object is like a (set of) function(s) in that it has behavior—it computes; it is not just inert data.
From Principles to Practice with Class in the First Year This suggests that objects are a natural fit for well-designed programs since good programs are orga- nized around data definitions and functions that operate over such data. An object, in essence, packagesthese two things together into a single programming apparatus. This has two important consequences: 1. Students already know how to design programs oriented around objects.
Since objects are just the combination of two familiar concepts that students already use to designprograms, they already know how to design programs around objects, even if they have never heardthe term “object” before.
2. Objects enable new kinds of abstraction and composition.
Although the combination of data and functionality may seem simple, objects enable new formsof abstraction and composition. That is, objects open up new approaches to the construction ofcomputations. By studying these new approaches, we can distill new design principles. Becausewe understand objects are just the combination of data and functionality, we can understand howall of these principles apply in the familiar context of programming with functions.
To begin with, we introduce the notion of a class definition, which can be thought of at first as a structuredefinition in that it defines a new class of compound data. A class is defined using the define-classform: This is similar to the define-struct form of the first semester, used as follows: An object is a value that is a member of this class of data, which can be constructed with the new keyword, a class name, and the appropriate number of arguments for the fields of the object: An object understands some set of messages. Simple structure-like objects understand messages foraccessing their fields and messages are sent by using the send keyword, followed by an object, a messagename, and some number of arguments: (send (new posn 3 4) x) ;=> 3(send (new posn 3 4) y) ;=> 4 The send notation is simple, but syntactically heavy. Once students are comfortable with send, we in-troduce shorthand to make it more convenient, writing (x .
n) is shorthand for (send (send x m) n). (The approach of introducing a simple, uniform syntax and later introducing a convenient shorthand that would have been confusingto start with follows the approach of first introducing cons and then later list and quote in the firstsemester.) It is possible to endow objects with functionality by defining methods, which extend the set of mes- sages an object understands. A method definition follows the same syntax as a function definition, butis located inside of a class definition. Here is a more complete development of the posn class with twomethods: ;; A Posn is a (new posn Number Number),;; which represents a point on the Cartesian plane(define-class posn (fields x y) ;; dist : Posn -> Number;; Distance between this posn and that posn(check-expect ((new posn 0 0) . dist (new posn 3 4)) 5)(define (dist that) ;; dist-origin : -> Number;; Distance of this posn from the origin(check-expect ((new posn 0 0) . dist-origin) 0)(check-expect ((new posn 3 4) . dist-origin) 5)(define (dist-origin) This class definition defines a new class of values which are posn objects. Such objects are comprised of two numeric values and understand the messages x, y, dist, and dist-origin. Unit tests have beenincluded with each method definition, following the principles of the design recipe studied in the firstsemester. Although check-expect forms can appear within class definitions, they are lifted to thetop-level when a program is run.
Methods can be defined to consume any number of arguments, but they are implicitly parameterized over this, the object that received the message.
Unions, and recursive unions in particular, are a fundamental kind of data definition that students arewell-versed in from the previous semester. A fundamental early lesson is how to represent (recursive)unions using classes and how to write recursive methods. As an example, figure defines binary trees ofnumbers (an archetypal recursive union data definition) using the Beginning Student language (BSL) asused at the start of the first semester, and also using the Class language of our course.
The structure of this program is analogous to the approach of the previous semester but this example brings to light an important difference with the functional approach. The method for computing the sumof a leaf is defined in the leaf class, while the method for computing the sum of a node is in the nodeclass. When a tree object is sent the sum method, there is no function with a conditional to determinewhether the object is a leaf—instead, the object itself takes care of computing the sum based on its ownsum method. This shift in perspective is at the core of object-orientation: objects contain their ownbehavior and the case analysis previously done in functions is eliminated.
At Northeastern, Programming in the first semester is often oriented around interactive event-drivenvideo games. The basic design of a video game involves defining a data representation for states of thegame and functions for transitioning between states based on events such as clock ticks, keyboard input,or mouse events. The design of a game thus involves the design of data and operations on that data; From Principles to Practice with Class in the First Year ;; sum : -> Number;; sums the elements of this tree ;; sum : Tree -> Number;; sums the elements of the given tree Figure 1: Binary tree sum in Beginning Student and in the Class language in other words, the game involves the design of objects. We therefore continue in the second semesterwith the use of programming video games but supplement the course with a library for doing so in anobject-oriented style. Figure gives an example written in both the functional style and object-orientedstyle.
The key difference between these two programs is that the functional program uses the 2htdp/universe library, which provides a big-bang form that consumes the initial state of the world and has a declarativeform of associating event-handler functions, while the object-oriented program uses an alternative librarydeveloped for our class: class/universe. It also provides a big-bang form but it consumes a singleargument, the initial state of the world represented as an object. Event handlers are simply methods ofthis object; for example, clock ticks trigger the on-tick method.
The program on the left is the first program of the first semester, while the one on the right is the first program of the second semester. Our approach is able to make the conceptual connection betweenfunctional and object-oriented programming quite clear while appealing to the familiar event-driveninteractive programs developed throughout the year.
;; A World is a (new world Number)(define-class world ;; on-tick : -> World(define (on-tick) (circle 10 "solid" "red") (circle 10 "solid" "red") The move to object-oriented style immediately and naturally leads to designs that are enabled by organizing programs around objects. For example, the state pattern becomes useful almost imme-diately. The programs in figure animate a rocket (rendered as a circle in this example) taking off. Anillustrative follow-up exercise is to animate a rocket that lands. The natural design is to have two variantsfor states of the rocket: one for descending rockets and one for landed rockets (an example is given inappendix While in the functional approach it is easy to use the state-pattern for the data representinga rocket, it is more difficult to have states of behavior. The typical solution adds conditionals to all ofthe event handlers. In the object-oriented approach, states of behavior are just as natural as data. It istherefore straightforward to design programs with easy to observe invariants such as “a landed rocketnever changes position.” In the functional approach, even such simple properties are more involved toestablish, because all event handlers must be inspected.
This approach also leads naturally to discussion of inheritance. Often programs with multiple states wish to share the implementation of some methods. We first show that this can be accomplished at thecost of minor boilerplate with delegation, and then show how inheritance allows the programmer to avoidduplication and boilerplate entirely. Once inheritance is able to group identical methods, overriding is anatural next step when some but not all of the implementations are identical across the variants.
Our introduction to object-oriented programming is built on a series of “language levels”, each of whichintroduces additional features, adding complexity to the programming model and expressiveness to theprograms. Each language is class/N for some N, with features appearing in the following order.
From Principles to Practice with Class in the First Year Several commonalities run through all of these languages. First, they are all purely functional; we do not introduce imperative I/O or side-effects until after transitioning to Java in the second half ofthe course. Second, they all are a super set of the Intermediate Student language from How to DesignPrograms, meaning that they support higher-order functional programming and lists.
One key principle that we adhere to in the design of the language levels is that no features of the language are added purely to support “software engineering” concerns such as specification mechanisms.
Not only does that language not support declaring types or contracts, but interfaces are described purelyin comments.
This is not to say that interfaces and contracts are optional; in fact, they are mandatory. But the focus of the first part of the course is on the fundamentals of object-orientation. Teaching the use of softwareengineering tools such as type systems, while vital, is a topic which we defer to the second half of thecourse when we transition to Java.
We made this decision after experience in which students were confused about the relationship be- tween explicit interface specifications, type systems, and the informal data definitions and contractswhich students are required to write for all methods. After removing interfaces from the language andmaking them purely a specification construct, this confusion disappeared.
The transition from custom teaching languages to a professional language takes place about half-waythrough the course. At this point, students already have experience with many of the essential conceptsof object-oriented programming. In particular: objects, classes, fields and methods, dynamic dispatch,inheritance, and overriding.
From this point, almost any language that students might encounter in future co-op positions, summer internships, or upper-level courses would be an appropriate follow-up. Our course transitions to Java,but C#, Python, Ruby, Eiffel, or JavaScript would all work naturally. The key lesson of the transitionis that the fundamental principles underlying object-oriented programming remain the same betweenlanguages, and that learning a new language is primarily a matter of mapping these concepts to specificconstructs in the new language. Of course, particular languages also use unique specific mechanismswhich need to be taught to use the language effectively, but these are rarely as vital as the cross-languageprinciples.
We chose the half-way point as the time for transition based on experience with earlier versions of this course. In particular, we found that a later transition, while allowing us to present additionalconcepts in a controlled environment, did not give students sufficient time and experience with Java.
Subsequent classes found that students were strong on fundamentals but weak on Java practice. Theother alternative, transitioning earlier, would not provide sufficient time to cover the fundamental topicsbefore the transition.
The transition begins with replicating the object-oriented style of our teaching languages in Java. In par-ticular, we do not introduce mutation, for loops, or mutable data structures such as arrays or ArrayListsuntil later in the semester. Instead, students design data representations using classes, with interfacesrepresenting unions of data. Additionally, we avoid mention of the distinction between primitive andother values in Java, which is made easier by not using standard libraries early. An example of this styleof programming is presented in figure repeating the binary tree sum from the previous section.
Comparing this figure to the previous example illustrates a number of the differences that students are exposed to upon transition to Java.
1. Explicit representation of unions and interfaces in the language. Previously, interfaces were simply described in stylized comments, following the How to Design Programs approach.
2. Types are now specified as part of the program and are (statically) enforced. Data definitions and interfaces can be transformed from the stylized comments into interface definitions and methodsignatures annotated with types. Students are taught the benefits of type systems, which imposesyntactic restrictions sufficient to prove objects meet (the structural aspects of) their interface defi-nitions. Students also encounter the downside of types when they discover the type system cannotalways follow valid reasoning about program invariants and may reject perfectly good programs.
3. Java syntax is substantially different and more verbose. For example, constructors must be defined 4. The testing environment is somewhat different, and requires additional boilerplate, although we are able to use the JavaLib framework to support testing with structural equality.
There are other differences which cannot be seen from a code snippet.
5. Students must use a new development environment and compiler. In class, we primarily develop in a text editor and run the Java compiler at the command line. In labs and on homeworks, studentstypically use the Eclipse IDE.
6. Installing and configuring libraries is now required. Because we use a custom library for testing, students must cope with library installation and class paths on the first day.
All but the first two of these changes are unrelated to the fundamental lessons we hope to teach—the rest merely present additional hurdles for students. However, at this point in the semester, the studentsare far better equipped to meet these challenges. They are already familiar with objects, classes, andthe other concepts we have covered. They are also fully engaged in the class, instead of making thetransition in the midst of the transition between semesters. Finally, they have now been programming for50% longer than they had at the start of the semester.
Thanks to the preparation in the first half of the course, we can cover OO programming in a functionalsubset of Java in a just a few lectures. We then increase the subset of the language we use to encompassmutation, loops, and mutable data structures and introduce the underlying design principles. We presentArrayLists, followed briefly by arrays. Students use, and then implement, hash tables as well as othermutable and immutable data structures. Conventional input and output are treated only very briefly, aswe focus instead on both fundamentals and exercises making use of real APIs such as hashing functions From Principles to Practice with Class in the First Year // sums the elements of this treeInteger sum(); Integer v;Leaf(Integer v) { this.v = v; }public Integer sum() { return this.v; } Tree left; Integer v; Tree right;Node(Tree l, Integer v, Tree r) { return this.left.sum() + this.v + this.right.sum(); t.checkExpect(new Leaf(7).sum(), 7);t.checkExpect(new Node(new Leaf(1), 5,new Node(new Leaf(0), 10, new Leaf(0))).sum(), Figure 3: Binary tree sum in the style of How to Design Classes or Twitter posting. Finally, while, for, and for-each loops are presented, following the methodology ofHow to Design Classes which connects loops to stylized use of recursive functions with accumulators, atechnique the students now have used for two semesters.
Finally, at the end of the course, we are able to build on the two major segments to examine less-well-explored topics in object-oriented programming. Typically, we cover the basics of representing objects ina functional language, advanced OO techniques such as mixins and prototypes, and a new OO languagesuch as Ruby or JavaScript. Additionally, we emphasize the ability to embed functional programming inan OO context, using techniques such as the command pattern and the visitor patterns. Again, the keymessage is the transferability of concepts across languages.
Teaching programming principles in a functional style has a long history, with Abelson and Sussman’sStructure and Interpretation of Computer Programs being a prominent example. Our work follows inthe tradition of the Program by Design (PbD) (previously known as the TeachScheme! project),which emphasizes a systematic approach to program construction.
Since the introduction of functional-first curricula, and more specifically in the Program by Design framework, numerous courses have tackled the problem of transition. Typically they, as we, transition toJava in the second course. We discuss first the approach developed by some of the principal creators ofPbD, and then other approaches.
The Program by Design project initially focused only on the first course, with the second course typicallytaught in Java in institution-specific ways. Subsequently, the pedagogical approach was extended to Java,but without the tool support and textbook of the first course. An example of this approach is describedby Bloch , who presents the experience integrating these courses at Adelphi. He reports that “manyof Java’s concepts could be introduced more easily in a second course than a first.” With these lessons in mind, the PbD project set out to apply the lessons of teaching languages and IDE support to Java, as well as to present the approach to object-oriented programming in textbook form.
ProfessorJ is the resulting system, accompanying the draft textbook How to Design Classes Inparallel to our course, Northeastern teaches the remainder of its computer science majors following thisapproach.
ProfessorJ and How to Design Classes maintain many of the ideas of the first course. In particular, ProfessorJ brings language levels to Java, in an attempt to smooth the transition for students from the firstcourse and provide more helpful feedback. ProfessorJ is also embedded in the DrRacket IDE, increasingfamiliarity for the students and supporting tools such as an interactive read-eval-print loop.
However, the “day 1” transition from the student languages used with How to Design Programs to ProfessorJ is too abrupt and too large. Most significantly, changing languages from the first semesterimmediately rather than simply adding a new concept confuses too many issues for students. On thefirst day of a How to Design Classes-based course, students see object-orientation, a new programming From Principles to Practice with Class in the First Year paradigm; Java, a new language with new syntax, and a static type system, a crucial but orthogonalconcept. In contrast, our course presents just one of these concepts on the first day, but covers all of themby the end of the semester.
ProfessorJ also takes on the the dual challenges of implementing Java as well as subsetting it. This ultimately resulted in both a limited Java environment as well as the eventual abandoning of the toolsince it was too difficult to maintain, let alone keep up with advances in Java.
Committing to Java on the first day, regardless of the environment provided to students, has signifi- cant limitations. First, the syntactic and semantic heaviness of Java is a burden for beginning students,and discourages interactive and experimental programming. The very first chapter of How to DesignClasses discusses the fixed size of Java integers, a topic avoided entirely in the first course. Second,by committing to a particular industrial-strength language, it closes off possibilities in the curriculum.
Third, it commits entirely to the new paradigm, making it more difficult for students to compare theapproaches.
Since ProfessorJ is no longer available, students are faced with an even starker change on the first day.
Even with a student-oriented environment such as DrJava or BlueJ students must learn an entirelynew tool, along with new libraries. If the course uses a typical professional development environmentsuch as Eclipse, students must also contend with compilation, loss of interactivity, and subtle issues suchas classpaths, none of which are fundamental to the concepts that the course focuses on.
Not every curriculum that begins with How to Design Programs transitions to Java after the first course.
Ragde describes a second course that includes both more advanced work in Scheme beyond teaching-oriented languages as well as low-level programming in C, taught to computer science majors at Uni-versity of Waterloo. Radge’s course intentionally does not use student-oriented languages, although therecently-developed C0 language could provide such a language. Other discussions of functionalprogramming in the first year do not discuss the problems of transition.
The problems of teaching Java in introductory courses have been well-explored; we mention only a fewrelated directions here. DrJava and BlueJ are introductory environments for Java, whichalleviate some but not all of the drawbacks we have outlined. For example, both of these systems im-mediately present students with (1) type systems and (2) Java syntax, and (3) do not support the imagevalues and exact numeric values that we rely on in our course.
Several teaching-oriented graphics libraries for Java have been proposed but these are signif- icantly more complex than the graphics and interaction libraries we are able to use in the introductorylanguage we present.
We have now completed the third iteration of this course, teaching approximately 35 students each time.
Our experience has been uniformly positive, and the students have gone on to significant success inthe subsequent courses, despite the curriculum differing from what the bulk of Northeastern Universitycomputer science majors take. Anectodally, the class has also had notable success in the recruitment and retention of female students, as compared to the other versions of the second-semester course. However,the classes are sufficiently different as to make a precise comparison impossible.
The course has provided a vantage point to introduce topics that will be taken up later in the cur- riculum. We present types, contracts, invariants, and properties of functions, all of which tie into boththe concurrent course on logic and computation, as well as later classes on formal methods. The empha-sis on representation-independence and interfaces both tie into later classes on software engineering, aswell as preparing students for algorithms and data structures courses. Finally, the use of interactive anddistributed systems connects to later courses on operating systems and networks.
Despite our success, much remains to be done. Type systems are a fundamental concept, but their introduction accompanies the rest of Java. Developing a typed version of our introductory languageswould allow a smoother introduction of this idea.
Our class’s use of Eclipse could also be improved by first transitioning to a pedagogically-oriented Java environment, but we have not evaluated the specific options. Alternatively, introducing Java-likesyntax for the teaching languages we have developed would help tease apart the difficult transitions stillpresent in the course.
Finally, the Java portion of the class does not continue the use of “World”-style interactive graphical programming, although a version of the “World” library has been developed for Java Instead,our course focuses on coverage of standard Java libraries, as well as introductory algorithmic and datastructure topics. Continuing to use World-style programming in motivating examples might be valuablefor continuity between the two halves of the course.
Matthias Felleisen’s approach to pedagogy and passion for undergraduate teaching has inspired thiswork from the beginning. CCIS Dean Larry Finkelstein entrusted two postdocs with the redesign of akey undergraduate course, which made this experiment possible. Our teaching assistants, Dan Brown,Asumu Takikawa, and Nicholas Labich, as well as the tutors and graders, contributed enormously to thesuccess of our courses. Finally, and most importantly, our students at Northeastern for the last three yearshave put up with a curriculum in progress, and the opportunity to teach them has been truly rewarding.
[1] Harold Abelson and Gerald J. Sussman. Structure and Interpretation of Computer Programs. MIT [2] Eric Allen, Robert Cartwright, and Brian Stoler. DrJava: a lightweight pedagogic environment for java. SIGCSE Bull., 34(1):137–141, 2002.
[3] Carl Alphonce and Phil Ventura. Using graphics to support the teaching of fundamental object- oriented principles in CS1. In Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, OOPSLA ’03, pages 156–161. ACM,2003.
[4] Ian Barland, Matthew Flatt, and Robby Findler. The design of a functional image library. In Workshop on Scheme and Functional Programming (SFP), 2010.
[5] Stephen A. Bloch. Scheme and java in the first year. J. Comput. Sci. Coll., 15(5):157–165, 2000.
From Principles to Practice with Class in the First Year [6] Kim B. Bruce, Andrea Danyluk, and Thomas Murtagh. A library to support a graphics-based object-first approach to CS 1. In Proceedings of the thirty-second SIGCSE technical symposium onComputer Science Education, volume 33 of SIGCSE ’01, pages 6–10. ACM, 2001.
[7] Manuel M. T. Chakravarty and Gabriele Keller. The risks and benefits of teaching purely functional programming in first year. J. Funct. Program., 14(1):113–123, 2004.
[8] Matthias Felleisen, Robert B. Findler, Matthew Flatt, and Shriram Krishnamurthi. How to design programs: an introduction to programming and computing. MIT Press, 2001.
[9] Matthias Felleisen, Robert B. Findler, Matthew Flatt, and Shriram Krishnamurthi. The structure and interpretation of the computer science curriculum. Journal of Functional Programming, 14(4):365–378, 2004.
[10] Matthias Felleisen, Robert B. Findler, Matthew Flatt, and Shriram Krishnamurthi. A functional I/O system or, fun for freshman kids. In ICFP ’09 Proceedings of the 14th ACM SIGPLAN InternationalConference on Functional programming, pages 47–58. ACM, 2009.
[11] Matthias Felleisen, Matthew Flatt, Robert Bruce Findler, Kathryn E. Gray, Shriram Krishnamurthi, and Viera K. Proulx. How to Design Classes (Draft). 2012. URL [12] Robert B. Findler, John Clements, Cormac Flanagan, Matthew Flatt, Shriram Krishnamurthi, Paul Steckler, and Matthias Felleisen. Drscheme: a programming environment for Scheme. JFP, 12(02):159–182, 2002.
[13] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1994.
[14] Kathryn E. Gray and Matthias Felleisen. Linguistic support for unit tests. Technical Report UUCS- [15] Kathryn E. Gray and Matthew Flatt. ProfessorJ: a gradual introduction to java through language levels. In Companion of the 18th annual ACM SIGPLAN conference on Object-oriented program-ming, systems, languages, and applications, OOPSLA ’03, pages 170–177. ACM, 2003.
[16] James I. Hsia, Elspeth Simpson, Daniel Smith, and Robert Cartwright. Taming java for the class- room. SIGCSE Bull., 37(1):327–331, 2005.
[17] Matt Kaufmann, J. Strother Moore, and Panagiotis Manolios. Computer-Aided Reasoning: An Approach. Kluwer Academic Publishers, 2000.
[18] Michael K¨olling, Bruce Quig, Andrew Patterson, and John Rosenberg. The BlueJ system and its pedagogy. Journal of Computer Science Education, 13(4), 2003.
[19] Frank Pfennig. C0 reference, 2011. URL [20] Viera K. Proulx. Javalib, 2012. URL [21] Viera K. Proulx and Kathryn E. Gray. Design of class hierarchies: an introduction to OO program design. In Proceedings of the 37th SIGCSE technical symposium on Computer science education,SIGCSE ’06, pages 288–292. ACM, 2006.
[22] Prabhakar Ragde. The chilling descent: making the transition to a conventional curriculum. In Proceedings of the 2008 international workshop on Functional and declarative programming ineducation, FDPE ’08, pages 13–20. ACM, 2008.
From Principles to Practice with Class in the First Year #lang class/1(require 2htdp/image class/universe) ;; A World is one of;; - (new landed-world);; - (new downworld Number)(define-class landed-world ;; to-draw : -> Image(define (to-draw) (circle 10 "solid" "red")390 200 (empty-scene 400 400)))) ;; on-tick : -> World(define (on-tick) ;; to-draw : -> Image(define (to-draw) (circle 10 "solid" "red")(this . w) 200 (empty-scene 400 400))) ;; on-key : KeyEvent -> World(define (on-key k) (new world 400)))

Source: http://samth.github.io/tfpie.pdf