Squeak: Object-Oriented Design with Multimedia Applications (Paperback)

by Mark J. Guzdial (Author)

Editorial Reviews

Book Info
(Pearson Education) Teaches the object-oriented programming language, Squeak. Focuses on the basics and uses case study examples to cover the entire process of object-oriented development. The CD-ROM contains Squeak, compatible with Windows 95+, Macintosh, Linux, Solaris, and some others. Softcover. DLC: Object-oriented programming (Computer science).

From the Inside Flap
Preface

The primary goal of this book is to help the reader create multimedia projects in Squeak. The book helps with other goals, too, but the reader-as-student is the primary audience here. "Student" will get swapped for "reader" in many places. The structure of this book is aimed at the undergraduate computer science student, though the content is more generally on multimedia projects in Squeak.

Whatever brings you to this book, the assumption is that you're trying to do projects, serious efforts requiring pages of code. This book provides the information needed to get going with objects, user interface, and multimedia in Squeak. The assumption is that you are using Squeak, and that you're actively trying to figure things out. This book gives you the tools to do that.

However, this book is not a reference to Squeak, in part because such a thing (on paper, at least) would be impossible, as suggested by Alan Kay in his foreword. Furthermore, the tools are in Squeak to serve as a form of dynamic reference (as seen in the Tools and Strategies sections of the book). But most importantly, making this book a reference would be a different task from the one I set out with: To create a tool for learning through Squeak projects.

This book was started in Squeak 2.5; at the time of this writing, Squeak Central was about to release Squeak 2.8. Most of the examples will work with all these versions of Squeak, but they are all tested against Squeak 2.7, and that's the version that is recommended for use with this book. APPROACH OF THE BOOK

When many American universities were established in the late 1800s (e.g., Stanford, the University of Chicago, and others), they were designed to be a mixture of the English college, with its focus on undergraduate education, and the German university, with its focus on research. The goal was for the research to motivate, and even inspire, both students and faculty to be better learners and teachers. While this works in the best cases, it has most often led to a higher priority on research than on teaching. (For a fascinating analysis of this tension, see Larry Cuban's How the Scholar Trumped the Teacher, Columbia Teacher's Press, 1999.)

The approach of this book is to be the reverse—hopefully, closer to the aims of the original inventors of the American university system. The book aims to integrate the diverse areas of knowledge needed to create successful projects. The pedagogy of this book is based on research in the learning sciences, on how people learn. The content of this book is based on my research, and that of my students, in developing collaborative multimedia in Squeak. The case studies in the latter half of the book are real projects that we designed, implemented, and then evaluated with real users to test the usability and effectiveness of our software.

The structure and approach of the book may be uncomfortable to some. It may even seem intuitively wrong to some. Intuition can sometimes be a dangerous thing—science has shown that measurement sometimes leads to findings that are contrary to "common sense." Science has come up with many ideas that seemed intuitively wrong, like disease being caused by small things too small to be seen by the naked eye, and that all objects fall at the same rate. As the methods of science have been applied to learning, similar non-intuitive lessons have been learned.

I attempted to apply the lessons about learning to the design of this book. I recognize, though, that research's lessons are not obvious—they require interpretation. My interpretations may be controversial, and even outright wrong. The responsibility for these interpretations is my own, not the original researchers'. Start from Where the Students Are

There is a school of thought that says that students should be taught the abstractions necessary for proper execution in a domain before they are taught the actual execution. The argument is that the students' minds are then prepared to learn the "right" way to do things. This argument has been used to push for theory ahead of practice, design before implementation, and learning algorithms and development methodologies before actually doing any programming.

One of the unfortunate realities of our cognitive system is that we're very bad at transferring knowledge from one domain to another, even when the two domains are tightly connected. We've known since the 1920s that students develop "brittle knowledge" (Alfred North Whitehead) that can be applied for a given exam or given course, but that seems to disappear outside of the original class. The formal study of "brittle knowledge" arguably began in mathematics education research, where students were found to become experts at one kind of equation, but were totally confused by the addition of a single extra term. The phenomenon was also noted in physics students, who could get A's with their tight explanations of acceleration and energy in a thrown ball, but who would explain outside of class that a ball falls because the atmosphere pushes on it. In my own research, I've been amazed to find that engineering students seem to forget almost all of their Calculus when they get to the junior and senior years.

If students do not see the connections between areas of knowledge, then they won't transfer the knowledge. If they do not understand what they're learning, they can't see the connections. But if students do understand material, if they can see lots of relations between what they're learning and what they've known before, the knowledge is more likely to transfer to other disciplines and to be retained longer.

Case-based reasoning, one theory for how our cognitive systems work, has an explanation for all of this. As information comes into a mind, it becomes indexed. When a new event appears, the mind uses its indices to figure out if it's ever seen anything like this before. If it has, then a connection is made. If our indices are developed well, we can match things as being similar. But if we learn things with indices that say "This is a fact for a specific course," as opposed to "This relates to design of programs," then we don't apply the information appropriately. It is possible to reindex things later, and it is possible to learn abstract things with appropriate indices, but it's easier to learn new things as variations of known things, and then extend the indexing schemes.

The goal of connecting to what students already know is to meet the students where they are. While a student can memorize and even learn to reason with abstract material, this is a sign of the intellectual capabilities of the student, not the usefulness of the material. The real test is whether the students can use the knowledge later. The odds of having usable knowledge are improved if the material is presented when it makes sense to students and can easily be related to knowledge that the students already have.

Academics, researchers, and other smart people often disbelieve this point. They reflect on their own learning and note that they often prefer to get the abstractions first. There are several responses to this kind of reaction. First, self-introspection is not necessarily the best way to come up with lessons about learning. People do fool themselves. (For example, people often believe that shortcut keys are faster than menus, but all explicit laboratory measurements show that mousing over menus is always faster—see Bruce Tognazzini's Tog on Interface, 1992, Addison-Wesley, for a review of this research.) But perhaps the more significant response is that smart people are already smart. They've picked up all kinds of concrete and abstract knowledge already. They're excellent learners who know how to figure out connections to new knowledge. As my advisor, Elliot Soloway, likes to say, "20% of the people will learn whatever you do to them. It's the other 80% that you have to worry about."

For these reasons, the order of events in this book is concrete and easily understandable first, and abstract and more general later:

Squeak is first introduced as being like other languages that students might know, and then the new and original features are introduced. Two chapters on Squeak programming appear before the chapter on design of object-oriented pro