DOCSLIB.ORG

Smalltalk and Object Orientation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Smalltalk and Object Orientation Smalltalk and Object Orientation: An Introduction John Hunt JayDee Technology Ltd, Hartham Park Corsham, Wiltshire , SN13 0RP United Kingdom Email: [email protected] http://www.jaydeetechnology.co.uk Preface This book was originally written to support an introductory course in Object Orientation through the medium of Smalltalk (and VisualWorks in particular). However, it can be used as a book to teach the reader Smalltalk, to introduce object orientation as well as present object oriented design and analysis. It takes as its basic premise that most Computer Scientists / Software Engineers learn best by doing rather than from theoretical notes. The chapters therefore attempt to intro duce concepts by getting you the reader to do things, rather than by extensive theoretical discussions. This means that these chapters take a hands -on approach to the subject and assume that the student/reader has a suitable Smalltalk environment available to them. The chapters are listed below and are divided into six parts. The reader is advised to work through Parts 1 and 3 thoroughly in order to gain a detailed understanding of object orientation. Part 2 then provides an introduction to the Smalltalk environment and language. Other chapters may then be dipped into as required. For example, if the reader wishes to hone their Smalltalk skills then the chapters in Part 4 would be useful. However, if at that point they wish to get on and discover the deligh ts of graphical user interfaces in Smalltalk, then Part 5 could be read next. Part 6 presents some more advances subjects such as metaclasses and concurrency which are not required for straight forward Smalltalk development. Content Summary Part 1: Introduction to Object Orientation Chapter 1: Introduction to Object Orientation The aim of this chapter is to provide an introduction to the range of concepts and ideas which make up object technology. It presents the background which led to the acceptance of object orientation as a mainstream technology and discusses the pedigree of the Smalltalk language. Chapter 2: Elements of Object Orientation This chapter provides a more formal definition of the terminology introduced in Chapter 1. It also considers the advantages and disadvantages of an object oriented approach compared to more traditional procedural approaches. Chapter 3: Constructing an Object Oriented System A typical problem for many people when being introduced to a new approach is that they understand the terminology and the concepts but not how to use them. This chapter aims to alleviate this problem by presenting a detailed worked example of the way in which an object oriented system may be designed and constructed. It does so without reference t o any particular language so that language issues should not confuse the discussion. Part 2: The Smalltalk Language Chapter 4: An Introduction to Smalltalk The aim of this chapter is to provide some background on the history of Smalltalk and the developm ent environments which are available to support it (such as the VisualWorks system). It also considers some of the tools the reader will encounter. Chapter 5: A Little Smalltalk This chapter presents a number of other tools such as the inspectors and debu ggers available in VisualWorks. It then uses a worked example to help the user to use some of the development tools available. Chapter 6: Smalltalk Building Blocks The chapter introduces the basic elements the Smalltalk language, it discusses the concep t of classes in Smalltalk and how they are defined. 2 Chapter 7: Smalltalk Constructs This chapter presents further details of the Smalltalk language including the representation and use of numbers, strings and characters. Chapter 8: An Example Smalltalk Class In Chapter 7, the reader is presented with a detailed worked example of software development in Smalltalk. This example presents a very simple class definition which uses only those concepts which have been introduced at this stage. The intention is t o illustrate how the constructs and language elements can be combined in a real (if simple) program. Chapter 9: Control and Iteration This chapter introduces how control and iteration are achieved in Smalltalk. To do this a number of concepts which are un ique to Smalltalk are also discussed (such as the block object). To simplify this process for the reader, equivalent C constructs are illustrated beside Smalltalk constructs (where they exist). Chapter 10: The Collection Classes This chapter discusses pro bably the most widely used class hierarchy in Smalltalk; the collection class hierarchy. It presents the hierarchy in general and some of the commonly used collection classes. It also illustrates how these classes can be used to construct other collection style classes such as queues and stacks. Chapter 11: Further Collection Classes This chapter concludes the examination of the collection classes available in Smalltalk and presents an application constructed using these classes. Chapter 12: An Object Oriented Organizer This chapter presents a detailed example application constructed using the collection classes. The Organizer is intended as an electronic personal Organizer. It therefore possesses an address book, a diary (or appointments section) and a section for notes. The remainder of this chapter describes one way of implementing such an Organizer. Chapter 13: Streams and Files This chapter discusses the second most used class hierarchy in Smalltalk; the Stream classes. The Stream classes are used (amongst other things) for accessing files. The Binary Object Streaming Service for storing objects in files is also discussed. Chapter 14: The Magnitude Class Hierarchy This chapter considers the magnitude class and those classes which inherit from it. This includes the Number hierarchy. The classes Character, Time and Date are also considered. Chapter 15: Some More Tools of the Trade This chapter introduces the use of breakpoints in Smalltalk, the purpose of the change list file and how to file in and file out Smalltalk code. Part 3: Object Oriented Design Chapter 16: Object Oriented Analysis and Design This chapter introduces the concepts of object oriented analysis and design. It reviews a number of the more popular techniques such as OOA, OMT, Objector y and Booch. It also briefly considers the unification of the OMT and Booch notations. Chapter 17: The Unified Modeling Language The Unified Modeling Language (or UML for short) is a third generation object -oriented modeling language which adapts and exte nds the published notations used in the Booch, OMT and Objectory methods. It is intended that the UML will form a single, common, widely usable modeling language for 3 a range of object oriented design methods (including Booch, Objectory and OMT). It is also intended that it should be applicable in a wide range of applications and domains. This chapter (and the next) summarize the UML notation. Chapter 18: UML: Dynamic Modeling and Deployment This chapter continues the description of the Unified Modeling Lan guage (UML) started in the last chapter. Chapter 19: The Object Modeling Technique This chapter, and the next, discuss the influential design method referred to as the Object Modeling Technique (OMT). It summarizes the main phases of OMT using the UML not ation. One extension to OMT is the introduction of use case models from Objectory to improve the requirements analysis process. This is motivated by the inclusion of use case diagrams in the UML. Chapter 20: More Object Modeling Technique This chapter continues the description of the Object Modeling Technique (OMT). Chapter 21: Frameworks and Patterns for Object Oriented Design The aim of this chapter is to introduce the concept of frameworks and in particular patterns. This is still a relatively new idea within Object Orientation, but one which is growing in popularity at an incredible rate. Part 4: Testing and Style Chapter 22: Testing Object Oriented Systems Object oriented systems may make code easier to reuse and may be supported by object oriented analysis and design methods, but they do not guarantee that the code is correct. This chapter looks at some of the issues behind testing object oriented systems. Chapter 23: Method and Class Testing The last chapter discussed the problems facing the test er of an object oriented system (and in particular a Smalltalk system). This chapter considers current best practice in testing object oriented systems. Chapter 24: Smalltalk Style Guidelines The aim of this chapter is the promotion of readable, understan dable, concise and efficient Smalltalk code. A point to note is that style guidelines for languages such as Pascal do not cover many of the issues which are important in Smalltalk. As in any programming language there are a number of acknowledged bad pract ices which are not specific to Smalltalk, for example the use of global variables! Such guidelines are familiar to programmers of most languages. This section will therefore try to concentrate on those style issues which are specific to Smalltalk. Part 5: Graphical Interfaces in Smalltalk Chapter 25: The Perform and Dependency Mechanisms In this chapter the use of perform to provide an alternative method for sending messages is considered. This is followed by a practical discussion of the dependency mecha nism. This includes what the dependency mechanism is, why you might want to use, how you construct a dependency and the effect that it has. Chapter 26: The Model-View-Controller Architecture The Model-View-Controller (or MVC) architecture is the basis upon which user interfaces are constructed in Smalltalk. The architecture separates out the application from the user interface. This chapter introduces the MVC architecture and explains the motivation behind it. A worked example is presented to illustrate the theoretical description. Chapter 27: Graphic User Interface Construction Tools 4 The user interface construction facilities in Smalltalk are subject to the widest variation between dialects of any aspect of the language.
Load more

Recommended publications
  • The Development of Smalltalk Topic Paper #7
    The Development of Smalltalk Topic Paper #7 Alex Laird Max Earn Peer CS-3210-01 Reviewer On Time/Format 1 2/4/09 Survey of Programming Languages Correct 5 Spring 2009 Clear 2 Computer Science, (319) 360-8771 Concise 2 [email protected] Grading Rubric Grading Total 10 pts ABSTRACT Dynamically typed languages are easier on the compiler because This paper describes the development of the Smalltalk it has to make fewer passes and the brunt of checking is done on programming language. the syntax of the code. Compilation of Smalltalk is just-in-time compilation, also known Keywords as dynamic translation. It means that upon compilation, Smalltalk code is translated into byte code that is interpreted upon usage and Development, Smalltalk, Programming, Language at that point the interpreter converts the code to machine language and the code is executed. Dynamic translations work very well 1. INTRODUCTION with dynamic typing. Smalltalk, yet another programming language originally developed for educational purposes and now having a much 5. IMPLEMENTATIONS broader horizon, first appeared publically in the computing Smalltalk has been implemented in numerous ways and has been industry in 1980 as a dynamically-typed object-oriented language the influence of many future languages such as Java, Python, based largely on message-passing in Simula and Lisp. Object-C, and Ruby, just to name a few. Athena is a Smalltalk scripting engine for Java. Little Smalltalk 2. EARLY HISTORY was the first interpreter of the programming language to be used Development for Smalltalk started in 1969, but the language outside of the Xerox PARC.
    [Show full text]
  • Filename Extensions
    Filename Extensions Generated 22 February 1999 from Filex database with 3240 items. ! # $ & ) 0 1 2 3 4 6 7 8 9 @ S Z _ a b c d e f g h i j k l m n o p q r s t u v w x y z ~ • ! .!!! Usually README file # .### Compressed volume file (DoubleSpace) .### Temp file (QTIC) .#24 Printer data file for 24 pin matrix printer (LocoScript) .#gf Font file (MetaFont) .#ib Printer data file (LocoScript) .#sc Printer data file (LocoScript) .#st Standard mode printer definitions (LocoScript) $ .$$$ Temporary file .$$f Database (OS/2) .$$p Notes (OS/2) .$$s Spreadsheet (OS/2) .$00 Pipe file (DOS) .$1 ZX Spectrum file in HOBETA format .$d$ Data (OS/2 Planner) .$db Temporary file (dBASE IV) .$ed Editor temporary file (MS C) .$ln TLink response file (Borland C++) .$o1 Pipe file (DOS) .$vm Virtual manager temporary file (Windows 3.x) & .&&& Temporary file ) .)2( LHA archiver temporary file (LHA) 0 .0 Compressed harddisk data (DoubleSpace) .000 Common filename extension (GEOS) .000 Compressed harddisk data (DoubleSpace) .001 Fax (Hayes JT FAX) (many) .075 75x75 dpi display font (Ventura Publisher) .085 85x85 dpi display font (Ventura Publisher) .091 91x91 dpi display font (Ventura Publisher) .096 96x96 dpi display font (Ventura Publisher) .0b Printer font with lineDraw extended character set (PageMaker) 1 .1 Unformatted manual page (Roff/nroff/troff/groff) .10x Bitmap graphics (Gemini 10x printer graphics file) .123 Data (Lotus123 97) .12m Smartmaster file (Lotus123 97) .15u Printer font with PI font set (PageMaker) .1st Usually README.1ST text 2 .24b Bitmap
    [Show full text]
  • A Survey of Technologies for Building Collaborative Virtual Environments
    The International Journal of Virtual Reality, 2009, 8(1):53-66 53 A Survey of Technologies for Building Collaborative Virtual Environments Timothy E. Wright and Greg Madey Department of Computer Science & Engineering, University of Notre Dame, United States Whereas desktop virtual reality (desktop-VR) typically uses Abstract—What viable technologies exist to enable the nothing more than a keyboard, mouse, and monitor, a Cave development of so-called desktop virtual reality (desktop-VR) Automated Virtual Environment (CAVE) might include several applications? Specifically, which of these are active and capable display walls, video projectors, a haptic input device (e.g., a of helping us to engineer a collaborative, virtual environment “wand” to provide touch capabilities), and multidimensional (CVE)? A review of the literature and numerous project websites indicates an array of both overlapping and disparate approaches sound. The computing platforms to drive these systems also to this problem. In this paper, we review and perform a risk differ: desktop-VR requires a workstation-class computer, assessment of 16 prominent desktop-VR technologies (some mainstream OS, and VR libraries, while a CAVE often runs on building-blocks, some entire platforms) in an effort to determine a multi-node cluster of servers with specialized VR libraries the most efficacious tool or tools for constructing a CVE. and drivers. At first, this may seem reasonable: different levels of immersion require different hardware and software. Index Terms—Collaborative Virtual Environment, Desktop However, the same problems are being solved by both the Virtual Reality, VRML, X3D. desktop-VR and CAVE systems, with specific issues including the management and display of a three dimensional I.
    [Show full text]
  • The Grace Programming Language Draft Specification Version 0.5. 2025" (2015)
    Portland State University PDXScholar Computer Science Faculty Publications and Presentations Computer Science 2015 The Grace Programming Language Draft Specification ersionV 0.5. 2025 Andrew P. Black Portland State University, [email protected] Kim B. Bruce James Noble Follow this and additional works at: https://pdxscholar.library.pdx.edu/compsci_fac Part of the Programming Languages and Compilers Commons Let us know how access to this document benefits ou.y Citation Details Black, Andrew P.; Bruce, Kim B.; and Noble, James, "The Grace Programming Language Draft Specification Version 0.5. 2025" (2015). Computer Science Faculty Publications and Presentations. 140. https://pdxscholar.library.pdx.edu/compsci_fac/140 This Working Paper is brought to you for free and open access. It has been accepted for inclusion in Computer Science Faculty Publications and Presentations by an authorized administrator of PDXScholar. Please contact us if we can make this document more accessible: [email protected]. The Grace Programming Language Draft Specification Version 0.5.2025 Andrew P. Black Kim B. Bruce James Noble April 2, 2015 1 Introduction This is a specification of the Grace Programming Language. This specifica- tion is notably incomplete, and everything is subject to change. In particular, this version does not address: • James IWE MUST COMMIT TO CLASS SYNTAX!J • the library, especially collections and collection literals • static type system (although we’ve made a start) • module system James Ishould write up from DYLA paperJ • dialects • the abstract top-level method, as a marker for abstract methods, • identifier resolution rule. • metadata (Java’s @annotations, C] attributes, final, abstract etc) James Ishould add this tooJ Kim INeed to add syntax, but not necessarily details of which attributes are in language (yet)J • immutable data and pure methods.
    [Show full text]
  • The Grace Programming Language Draft Specification Version
    The Grace Programming Language Draft Specification Version 0.1 Andrew P. Black Kim B. Bruce James Noble June 4, 2011 1 Introduction This is a specification of the Grace Programming Language. This spec- ification is notably incomplete, and everything is subject to change. In particular, this version does not address: • whether to support object nesting (Beta, Scala, Newspeak) or not (Smalltalk, Python). • collection syntax and collection literals • tuples vs multiple values vs multiple returns • static type system • encapsulation system • module system • metadata (Java's @annotations, C] attributes, final, abstract etc) • purity and non-nulls. • reflection • assertions, data-structure invariants, pre & post conditions, contracts • regexps • test support • libraries For discussion and rationale, see http://gracelang.org. Where this document gives \(options)", we outline choices in the lan- guage design that have yet to be made. 1 Id: spec.tex 127 2011-06-03 06:52:00Z kjx 2 2 User Model All designers in fact have user and use models consciously or subconsciously in mind as they work. Team design. requires explicit models and assumptions. Frederick P. Brooks, The Design of Design. 2010. 1. First year university students learning programming in CS1 and CS2 classes that are based on object-oriented programming. (a) The courses may be structured objects first, or imperative first. Is it necessary to support \procedures first"? (b) The courses may be taught using dynamic types, static types, or both in combination (in either order). (c) We aim to offer some (but not necessarily complete) support for \functional first” curricula, primarily for courses that proceed rapidly to imperative and object-oriented programming.
    [Show full text]
  • The Evolution of Smalltalk from Smalltalk-72 Through Squeak
    The Evolution of Smalltalk From Smalltalk-72 through Squeak DANIEL INGALLS, Independent Consultant, USA Shepherd: Andrew Black, Portland State University, USA This paper presents a personal view of the evolution of six generations of Smalltalk in which the author played a part, starting with Smalltalk-72 and progressing through Smalltalk-80 to Squeak and Etoys. It describes the forces that brought each generation into existence, the technical innovations that characterized it, and the growth in understanding of object-orientation and personal computing that emerged. It summarizes what that generation achieved and how it affected the future, both within the evolving group of developers and users, and in the outside world. The early Smalltalks were not widely accessible because they ran only on proprietary Xerox hardware; because of this, few people have experience with these important historical artifacts. To make them accessible, the paper provides links to live simulations that can be run in present-day web browsers. These simulations offer the ability to run predefined scripts, but also allow the user to go off-script, browse thedetailsof implementation, and try anything that could be done in the original system. An appendix includes anecdotal and technical aspects of how examples of each generation of Smalltalk were recovered, and how order was teased out of chaos to the point that these old systems could be brought back to life. CCS Concepts: · Software and its engineering → General programming languages; · Social and pro- fessional topics → History of programming languages. Additional Key Words and Phrases: Smalltalk, Squeak, Alto, NoteTaker, OOZE, BitBlt, Morphic, EToys, Objects, Blocks, Bytecode, Interpreter, Virtual Machine, Bootstrap 85 ACM Reference Format: Daniel Ingalls.
    [Show full text]
  • Utena VM Virtual Machine for a Dynamic-Interactive Object System
    Utena VM Virtual Machine for a dynamic-interactive object system Gnuxie Lulamoon [email protected] June 18, 2021 Contents 1 Introduction 3 1.1 Project Overview . .3 1.2 Project Aims . .3 2 Background Research 4 2.1 Virtual Machines . .4 2.1.1 Java Virtual Machine . .4 2.1.2 Termite Scheme . .5 2.1.3 JavaScript . .5 2.1.4 Smalltalk . .5 2.1.5 Newspeak . .5 2.1.6 Self Virtual Machine . .5 2.2 Development Environment . .6 2.2.1 Systems Language . .6 2.2.2 Meta-circular implementation . .6 2.2.3 Existing Dynamic-Interactive System . .6 2.3 Development Process . .7 2.3.1 Rapid-Prototyping . .7 2.3.2 Continuous Integration . .7 2.3.3 Continuous Improvement . .7 3 Design 8 3.1 Overview . .8 3.2 Objects & Messages . .8 3.2.1 Objects . .8 3.2.2 Machine . .9 3.3 Operations . 10 3.3.1 Methods and Instructions . 10 3.4 Primitives . 11 3.4.1 Boxed primitives . 11 3.4.2 Standard Object . 11 3.4.3 Methods & Blocks . 12 3.5 Dynamic Environment . 14 3.6 Modules as Objects . 15 4 Software Engineering Approach and Testing 16 4.1 Style Guide . 16 4.2 Issue Management & Continuous Improvement . 16 4.3 Testing . 17 1 4.3.1 Continuous Integration . 17 4.3.2 Relation to Issue Management . 18 5 Implementation 19 5.1 The Object Map . 19 5.1.1 Lookup . 19 5.1.2 Transition . 19 5.2 Primitive Boxes . 20 5.2.1 Shared Behavior . 20 5.2.2 Boxing .
    [Show full text]
  • The Grace Programming Language Draft Specification Ersionv 0.3.53
    Portland State University PDXScholar Computer Science Faculty Publications and Presentations Computer Science 8-14-2013 The Grace Programming Language Draft Specification ersionV 0.3.53 Andrew P. Black Portland State University, [email protected] Kim B. Bruce James Noble Follow this and additional works at: https://pdxscholar.library.pdx.edu/compsci_fac Part of the Programming Languages and Compilers Commons Let us know how access to this document benefits ou.y Citation Details Black, Andrew P.; Bruce, Kim B.; and Noble, James, "The Grace Programming Language Draft Specification Version 0.3.53" (2013). Computer Science Faculty Publications and Presentations. 93. https://pdxscholar.library.pdx.edu/compsci_fac/93 This Working Paper is brought to you for free and open access. It has been accepted for inclusion in Computer Science Faculty Publications and Presentations by an authorized administrator of PDXScholar. Please contact us if we can make this document more accessible: [email protected]. The Grace Programming Language Draft Specification Version 0.353 Andrew P. Black Kim B. Bruce James Noble April 3, 2012 1 Introduction This is a specification of the Grace Programming Language. This spec- ification is notably incomplete, and everything is subject to change. In particular, this version does not address: • collection syntax and collection literals • tuples vs multiple values vs multiple returns • nested static type system (although we've made a start) • encapsulation system (privacy annotations) • module system • metadata (Java's @annotations, C] attributes, final, abstract etc) • purity and non-nulls. • reflection • assertions, data-structure invariants, pre & post conditions, contracts • regexps • test support • libraries, including more Numeric types For discussion and rationale, see http://gracelang.org.
    [Show full text]
  • Homework 3: Introductory Smalltalk Programming Due: Problems 1-3 and 5 on October 2, 2003; 6-10 on October 9, 2003
    Com S 541 — Programming Languages 1 September 24, 2003 Homework 3: Introductory Smalltalk Programming Due: problems 1-3 and 5 on October 2, 2003; 6-10 on October 9, 2003. The purpose of this homework is to ensure basic skills in Smalltalk programming, and to help you explore the literature a bit. This is an individual homework; that is, for this homework, you are to do the work on your own, not in teams. For all Smalltalk programs, you can run your code with either Squeak or VisualWorks Smalltalk, although we recommend using Squeak. See the “running smalltalk” web page off the course web page. Hand in a printout of the “file out” of your code and your testing. For classes you write, you can file out the entire class by selecting the Classes menu in the class browser, then choosing “file out ...”. You can also do this for a whole category. For code you add to an existing class, just file out the new or changed methods (from the Methods menu in the browser, choose “file out ...”). This is also a good way to save your work. For testing, save your work first! Then test your programs in a workspace; if your program has textual output, use “print it” from the Smalltalk menu and then save the workspace in a file (using the File menu, and choosing “Save As ...”). Don’t write code that looks like C! We’ll take points off for poor style. Unless we specifically direct you to edit an existing Smalltalk class, don’t edit existing classes.
    [Show full text]
  • Smalltalk Solutions 2008 Report, ESUG 2008 Report, VAS Report
    Smalltalk Conferences between June and September 2008 1 Smalltalk Conferences between June and September 2008 This document contains my reports of • the Smalltalk Solutions conference in Reno June 18 - 21, 2008 • the ESUG conference in Amsterdam, August 25 - 29, 2008 (and brief info of the Camp Smalltalk 23rd - 24th and Seaside Sprint 29th - 31st) • the VASmalltalk User Group conference in Frankfurt, September 23, 2008 I have combined my three conference reports into a single document. They follow in the order in which conferences occurred. An initial section ‘Shared Keynotes’ gives two talks that were given at both ESUG and Smalltalk Solutions. Style ‘I’ or ‘my’ refers to Niall Ross; speakers (other than myself) are referred to by name or in the third person. A question asked in or after a talk is prefixed by ‘Q.’ (sometimes I name the questioner; often I was too busy noting their question). A question not beginning with ‘Q.’ is a rhetorical question asked by the speaker (or is just my way of summarising their meaning). Author’s Disclaimer and Acknowledgements These reports give my personal view. No view of any other person or organisation with which I am connected is expressed or implied. The talk descriptions were typed while I was trying to keep up with and understand what the speakers were saying, so may contain errors of fact or clarity. I apologise for any inaccuracies, and to any participants whose names or affiliations I failed to note down. If anyone spots errors or omissions, email me and corrections may be made. My thanks to the conference organisers and the speakers whose work gave me something to report.
    [Show full text]
  • Grace Draft Specification
    The Grace Programming Language Draft Specification Version 0.3.1261 Andrew P. Black Kim B. Bruce James Noble August 14, 2013 1 Introduction This is a specification of the Grace Programming Language. This specifica- tion is notably incomplete, and everything is subject to change. In particular, this version does not address: • the library, especially collection syntax and collection literals • nested static type system (although we’ve made a start) • module system James Ishould write up from DYLA paperJ • metadata (Java’s @annotations, C] attributes, final, abstract etc) James Ishould add this tooJ Kim INeed to add syntax, but not necessarily details of which attributes are in language (yet)J • immutable data and pure methods. • reflection • assertions, data-structure invariants, pre & post conditions, contracts Kim IPut into dialects section?J • Dialects • regexps • libraries, including more (complex?) Numeric types and testing For discussion and rationale, see http://gracelang.org. Where this document gives “(options)”, we outline choices in the language design that have yet to be made. 1 2 Revision 1261 committed on 2013-08-14 00:06:00Z by kim 2 User Model All designers in fact have user and use models consciously or subconsciously in mind as they work. Team design . requires explicit models and assumptions. Frederick P. Brooks, The Design of Design. 2010. 1. First year university students learning programming in CS1 and CS2 classes that are based on object-oriented programming. (a) The courses may be structured objects first, or imperative first. Is it necessary to support “procedures first”? (b) The courses may be taught using dynamic types, static types, or both in combination (in either order).
    [Show full text]
  • The Grace Programming Language Draft Specification Version 0.132
    The Grace Programming Language Draft Specification Version 0.132 Andrew P. Black Kim B. Bruce James Noble October 22, 2011 1 Introduction This is a specification of the Grace Programming Language. This spec- ification is notably incomplete, and everything is subject to change. In particular, this version does not address: • whether to support object nesting (Beta, Scala, Newspeak) or not (Smalltalk, Python). • collection syntax and collection literals • tuples vs multiple values vs multiple returns • nested static type system (although we've made a start) • encapsulation system • module system • metadata (Java's @annotations, C] attributes, final, abstract etc) • purity and non-nulls. • reflection • assertions, data-structure invariants, pre & post conditions, contracts • regexps • test support • libraries, including more Numeric types For discussion and rationale, see http://gracelang.org. Where this document gives \(options)", we outline choices in the lan- guage design that have yet to be made. 1 2 Id: spec.tex 195 2011-10-21 19:24:33Z kjx 2 User Model All designers in fact have user and use models consciously or subconsciously in mind as they work. Team design. requires explicit models and assumptions. Frederick P. Brooks, The Design of Design. 2010. 1. First year university students learning programming in CS1 and CS2 classes that are based on object-oriented programming. (a) The courses may be structured objects first, or imperative first. Is it necessary to support \procedures first"? (b) The courses may be taught using dynamic types, static types, or both in combination (in either order). (c) We aim to offer some (but not necessarily complete) support for \functional first” curricula, primarily for courses that proceed rapidly to imperative and object-oriented programming.
    [Show full text]