This innovative book teaches object-oriented programming using Squeak—a powerful, freely available language that is highly effective for learning object-oriented programming. The book covers the whole process, while focusing on the basics and compelling case studies. Includes a rich description of object-oriented process. Emphasizes historical perspectives. Introduces simple UML. For readers wanting to learn more about object-oriented programming.
FREE Two-Day Shipping for Students. Learn more |
Book Description
Special Offers and Product Promotions
- Buy $50 in qualifying physical textbooks, get $5 in Amazon MP3 Credit. Here's how (restrictions apply)
Frequently Bought Together
Editorial Reviews
Review
"In Squeak, you have your hands in one of the most late bound, yet practical, programming systems ever created. It is also an artifact which is wide, broad, and deep enough to permit real scientific study, creation of new theories, mathematics, engineering constructions, and even its own successor! Please use this book to learn how to do all of the above."--Alan Kay, V-P Research, Disney Imagineering "The text presents OO concepts in the context of Smalltalk (Squeak), which is by far the best environment and language in which to learn the concepts. The author is clearly enthusiastic about the subject matter!authoritative in explaining the basics of Smalltalk."--Keith R. Pierce, St. Paul Companies
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 programs. Technical details of building user interfaces are presented before interface design principles. Learning involves Testing and Failure
Noted cognitive scientist Roger Schank has promoted the importance of "failure-based learning." If you're always successful, you don't learn much. But after you've failed, you're in the perfect position to learn a lot. Someone who has just failed is now interested in reading, in exploring theory, and in engaging in inquiry in order to understand the failure and how to avoid it next time. In order to fail, you must face a "test" of some kind. The test doesn't have to be of the paper-and-pencil type. It doesn't have to be formal at all. But if there isn't an event that tests your knowledge and provides the opportunity to fail, then the failing and the learning will never occur.
Computer scientists are well familiar with this process of testing, failing, and learning from the failure. We even have invented a nice word for it: debugging. Debugging is such an important part of computer science that computer scientist and educator Gerald Sussman has been quoted as saying, "Programming is debugging a blank sheet of paper."
But when it comes to user interfaces, computer scientists tend to shy away from a real test. The buttons get pushed, and the menus get dragged, and success is declared. However, the design of the user interface should be based on what the user wants, not whether the buttons can be pushed. To really test the design, one has to face the users. This is called user-interface evaluation.
Students cannot learn design without evaluation. Otherwise, it's almost impossible for the design to fail, and thus learning cannot occur. The evaluation does not have to be very sophisticated. The "discount usability methods" of Jakob Nielsen and others work because the real problems of user interface design tend to be right up front and pretty easy to see.
The chapter on user-interface design includes sections on evaluation. But more importantly, each of the case studies in the back of the book includes an evaluation with real users. Some of the evaluations are survey-based, others are observational with interviews, and still others use recordings of user events to figure out what happened. In every case, there is some testing of the design assumptions. Generation and inquiry, not Transmission
Even though people speak of "transmitting" or "delivering" material in a classroom, that isn't how learning works. Cognitive science has known for decades now that all real learning is constructivist: It's an active process of figuring things out and relating them to other knowledge. The goal of education is to motivate students to think about things, and thus learn.
The goal of a book, then, is not to deliver facts, but to provide methods of generating knowledge and fuel for students' inquiry. A list of phrases to be memorized doesn't lead to learning. But if a book explains how to do something, and then provides some interesting somethings to do, then the setting for learning is prepared.
There are sections of this book explicitly labeled Tools and Strategies that are meant to show how to dig into Squeak, how to study the exercises, and how to build your own things in Squeak. The rest of the book is meant to fuel inquiry, that is, students' exploration of things of interest. Inquiry can take lots of forms in lots of different directions. The goal of this book is to provide starting places for many of these: From a historical or technical perspective; from object-oriented design or user interface design; from building objects to building interfaces. CONTENT OF THE BOOK
This is a book about using Squeak to build multimedia programs. It is not a general book about object-oriented design, interface design, or multimedia design. Rather, it's meant to be a book about using a particular programming language (that has a rich history and is particularly well suited for use in computer science education) to build projects that cross diverse areas of knowledge. In order to build multimedia programs in Squeak, students need to know the following things:
How to program in Squeak, from both a language and an environment perspective; How to design programs for Squeak; How to build user interfaces in Squeak; How to design and evaluate user interfaces in Squeak; How to do multimedia in Squeak; Four detailed examples that describe how to do all of the above, with a particular emphasis on design and evaluation.
In short, that's the content of the book.
Readers who aren't interested in all six of these topics may want to take one of these other paths:
If you already know Smalltalk and want to learn Squeak: Chapter 2 is an overview of Squeak, Chapter 5 (especially Sections 5.3 and 5.4) introduces user interfaces in Squeak, and Chapter 7 discusses multimedia. The case studies will also all be useful. If you are focused on object-oriented design: Chapter 3 is the transition from the focus on programming (in Chapter 2) to object-oriented design. Chapter 4 is the main chapter on object-oriented design issues, though the case studies also present object-oriented designs and evaluations of those designs. If you are focused on HCI: Chapter 5 tells how to build user interfaces in Squeak, and Chapter 6 centers on how to design them. The case studies provide HCI evaluation examples.
The book is particularly aimed at the early-to-intermediate undergraduate student. There is an assumption here that students already know some programming language, but little else. The goal is to quickly get students producing multimedia applications in Squeak. It serves as an excellent lead-in to more advanced classes in any of these subject areas.
At Georgia Tech, we have been teaching a course on material like this for over five years. It has met with success, in terms of student performance and satisfaction with the content. This book is based on the notes for that course. I hope that this book will be as successful in other classes, and for you, the reader, however you come to this book. ACKNOWLEDGMENTS
This book builds on the efforts and contributions of many developers, reviewers, teachers, students, and colleagues. My listing their names here does not imply that the end product reflects their preferences, but they have been important influences for me in writing the book.
First of all, thanks to Squeak Central: Alan Kay, Dan Ingalls, Ted Kaehler, John Maloney, Andreas Raab, Scott Wallace, and Kim Rose (and Jeff Pierce, in his former intern role). The most obvious gratitude is for giving us Squeak, but I also owe them enormous thanks for the hours of help they have given me in answering questions, looking over sections of the book, helping me find resources, and so on. Thanks, especially, to Alan, for providing the thought-provoking foreword to the book.
Thanks to the Squeak community for answering questions and to many of them for explicitly reviewing and commenting on versions of these chapters. Special thanks to Stephane Ducasse (who gave an enormous amount of time and effort reviewing), Naala Brewer, Jennifer Brown, Piero Campanelli, Ward Cunningham, Marcus Denker, Andreas Dieberger, Steve Elkins, Dick Karpinski, Mayuresh Kathe, Patrick Milligan, Stefan Rieken, Mary Beth Rosson, Frank Sergeant, my colleague and coteacher Richard LeBlanc, and several anonymous reviewers. My thanks and admiration go to the teachers who first trialed this book in their classes and gave me some of the most valuable feedback I received: Rick Zaccone at Bucknell, Rik Smoody at Portland State University, and Cullen O'Neill at the University of Michigan.
Thanks to the many Squeak students at Georgia Institute of Technology's College of Computing who helped me learn how to teach Squeak and what difficulties people had in learning Squeak, especially to those students and teaching assistants in CS2340 who first trialed the book and gave me feedback on it. Some of the exercises here were based on labs invented by TAs Jennifer Brown, Anna Shleyfmari, and Ivan Brusic.At a risk of leaving out some of the Squeakers, I want to highlight the contributions of Ivan Brusic, Colleen Kehoe, Bolot Kerimbaev, Aibek Musaev, Bijan Parsia, Noel Rappin, Jochen Rich, Lex Spoon, Michael Terry, and Rodney Walker.
Alan Apt and Toni Holm of Prentice-Hall were amazingly patient and supportive of a first-time author, and I appreciate their help.
Thanks to Ivan Sutherland and Sun Microsystems for permission to use the picture of him running Sketchpad in Chapter 1.
Parts of the case studies (especially the Swiki or CoWeb) were developed with the support of the National Science Foundation as part of our work on collaborative learning environments.
Last, but not at all least, to my children Matthew, Katherine, and Jennifer and my ever-patient wife, Barbara, who gave me time to work at the book and had even more confidence than I that it would become finished one day. Thanks for your loving support!
Product Details
Would you like to update product info or give feedback on images?
|
More About the Author
I started teaching computing in February 1980. I was 17 in my senior year of high school, and I taught "Bits, Bytes, and Basic" in a community education class. I taught through my undergrad years--community education, afterschool classes, GED classes, and even community college in 1984. I read "Personal Dynamic Media" by Adele Goldberg and Alan Kay while on an internship at Bell Labs in 1982. I'd never before thought about computing FOR learning (as opposed to learning ABOUT computing). Adele and Alan's thoughts and words set me on the road to my PhD in Education and Computer Science at the University of Michigan in 1993. Nowadays, I focus on using lessons from learning sciences and educational technology for teaching about computing.
Customer Reviews
|
Share your thoughts with other customers:
|
||||||||||||||||||||||
|
Most Helpful Customer Reviews
29 of 31 people found the following review helpful:
5.0 out of 5 stars
Fine Book on a Wonderful Language,
By
This review is from: Squeak: Object-Oriented Design with Multimedia Applications (Paperback)
As the author of several Smalltalk books myself, I tend to be a bit skeptical of new books about Smalltalk. But Mark Guzdial's excellent first book on the best Smalltalk implementation on the planet, Squeak, earns my highest respect. It is organized the way I suspect most people trying to learn a new language like such books organized. Rather than beginning with abstract concepts and then hoping you will be able to use those concepts to solve specific problems, Guzdial takes a practical, project-based approach.This book does not purport to cover basic object-oriented design and programming paradigms but in fact it does at least an adequate job even for a relative beginner. It is clearly aimed at someone who has at least a smattering of programming training or experience, but you don't really need much to derive great value from the book. It is true that since the book was released there is a newer version of Squeak, but the good news is that the author had the foresight to include on the accompanying CD-ROM the version of the language on which he relied to make the book examples work. I've been working with the newer version for some time but reverting to the older version for the purpose of the book wasn't difficult or painful. I believe that Squeak IS the future of all kinds of computing and development, including the Internet/Web world, and it will behoove you to learn this wonderful language sooner than later. There is simply no better way to do that than to start with Guzdial's work. He's the prototypical teacher and the book is marvelous.
11 of 16 people found the following review helpful:
5.0 out of 5 stars
Another great Smalltalk book,
By Roger Vossler (Denver, CO USA) - See all my reviews
This review is from: Squeak: Object-Oriented Design with Multimedia Applications (Paperback)
Good books for people wanting to get started in Smalltalk are hard to find. Particularly, those that are connected to a viable programming environment. This book is excellent on both counts. The associated Squeak programming environment is a solid Smalltalk-80 implementation that is being moved in new directions by a team at Squeak Central, now at Disney, led by Dr. Alan Kay whose team contains several of the early developers of Smalltalk. Dr. Kay also invented the concept of the DynaBook. Mark Guzdial's team is also working on a Collaborative DynaBook at Georgia Tech. Thus, this book is also a entry point into two hotbeds of R&D in leading-edge computing technology. Welcome to the future! Note: Squeak is free on a number of popular platforms.
6 of 10 people found the following review helpful:
4.0 out of 5 stars
The only book about one of the best software systems,
By
This review is from: Squeak: Object-Oriented Design with Multimedia Applications (Paperback)
If you do not yet know Squeak or Smalltalk:1. Download the current version of Squeak from squeak.org (the version on the CDROM is not the latest and greatest)! 2. Buy this book, read it and learn to Squeak! 3. Order the other book (not yet published) about Squeak edited by Mark Guzdial! otherwise: do the same! In both cases try to ignore the problems with the reproduction of some of the screenshots.
Share your thoughts with other customers: Create your own review
|
|
What Other Items Do Customers Buy After Viewing This Item?
Tags Customers Associate with This Product(What's this?)Click on a tag to find related items, discussions, and people.
|
Sell a Digital Version of This Book in the Kindle Store
If you are a publisher or author and hold the digital rights to a book, you can sell a digital version of it in our Kindle Store.
Learn more
Customer Discussions
|
This product's forum
Active discussions in related forums
Search Customer Discussions
|
Related forums
|
