TITLE: Resolved: "Object Early" Has Failed AUTHOR: Eugene Wallingford DATE: February 26, 2005 5:39 PM DESC: Have objects failed us, or have we failed objects? Or is the question premature? ----- BODY: The focal event of Day 3 at SIGCSE is the 8:30 AM special session, a panel titled Resolved: "Object Early" Has Failed. It captures a sense of unrest rippling through the SIGCSE community, unrest at the use of Java in the first year, unrest at the use of OOP in the first year, unrest at changes that have occurred in CS education over the last decade or more. Much of this unrest confounds unhappiness with Java and unhappiness with OOP, but these are real feelings felt by good instructors. But there are almost as many people uneasy that, after five or more years, so few intro courses seem to really do OOP, or at least do it well. These folks are beginning to wonder whether objects will ever take a place at the center of CS education, or if we are destined to teach Pascal programming forever in the language du jour. This debate gives people a chance to hear some bright folks on both sides of the issue share their thoughts and answer questions from one another and the audience. The panel is structured as a light debate among four distinguished CS educators: Our fearless leader is Owen "Moderator with a Law" Astrachan. The fact that the best humor in the introductions was aimed at the pro-guys may reveal Owen's bias, or maybe Stuart and Eliot are just easier targets... Eliot opened by defining "objects early" as a course that on using and writing classes before writing control structures and algorithm development. He made the analogy to new math: students learn "concepts" but can't do basic operations well. Most of Eliot's comments focused on faculty's inability or unwillingness to change and on the unsuitability of the object-oriented approach for the programs students write at the CS1 level. The remark about faculty reminded me of a comment Owen made several years ago in a workshop, perhaps in an Educators Symposium at OOPSLA, that our problem here is no longer legacy software but legacy faculty. Michael followed quite humorously with a send-up of this debate as really many debates: objects early, polymorphism early, interfaces early, GUIs early, events early, concurrency early... If we teach all of these in Week 1, then teaching CS 1 will be quite nice; Week 2 is the course wrap-up lecture! The question really is, "What comes last?" Michael tells us that objects haven't failed us; we have failed objects. Most of us aren't doing object yet! And we should start. Michael closed with a cute little Powerpoint demo showing a procedural-oriented instructor teaching objects not by moving toward objects, but by reaching for objects. When you reach too far without moving, you fall down. No surprise there! Stuart returned the debate to the pro side. He sounded like someone who had broken free of a cult. He said that, once, he was a true believer. He drank the kool-aid and developed a CS 1 course in which students discussed objects on Day 2. He even presented a popular paper on the topic at SIGCSE 2000, Conservatively Radical Java in CS1. But over time he found that, while his good students succeeded in his new course, the middle tier of students struggled with the "object concept". He is willing to entertain the idea that the problem isn't strictly with objects-first but with the overhead of OOP in Java, but pragmatic forces and a herd mentality make Java the language of choice for most schools these days, so we need an approach that works in Java. Stuart lamented that his students weren't getting practice at decomposing problems into parts or implementing complete programs on their own. Students seem to derive great pleasure in writing a complete, if small, program to solve a problem. This works in the procedural style, where a 50- to 100-line can do something. Stuart asserted that this doesn't work with an OO style, at least in Java. Students have to hook their programs in with a large set of classes, but that necessitates programming to fixed API. The result just isn't the same kind of practice students used to get when we taught procedural programming in, um, Pascal. Stuart likens this to learning to paint versus learning to paint-by-the-numbers. OOP is, to Stuart, paint-by-the-numbers -- and it is ultimately unsatisfying. Stuart's contribution to the panel's humorous content was to claim that the SIGCSE community was grieving the death of "objects early". Michael, Kim, and their brethren are in the first stage of grief, denial. Some objects-early folks are already in the stage of anger, and they direct their anger at teachers of computer science, who obviously haven't worked hard enough to learn OO if they can't succeed at teaching it. Others have moved onto the stage of bargaining: if only we form a Java Task Force or construct the right environment or scaffolding, we can make this work. But Stuart likened such dickering with the devil to cosmetic surgery, the sort gone horribly wrong. When you have to do that much work to make the idea succeed, you aren't doing cosmetic surgery; you are putting your idea on life support. A few years ago, Stuart reached the fourth stage of grief, depression, in which he harbored thoughts that he was the alone in his doubts, that perhaps he should just retire from the business. But, hurray!, Stuart finally reached the stage of acceptance. He decided to go back to the future to return to the halcyon days of the 1980s, of simple examples and simple programming constructs, of control structures and data structures and algorithm design. At last, Stuart is free. Kim closed the position statement portion of the panel by admitting that it is hard work for instructors who are new to OO to learn the style, and for others to build graphics and event-driven libraries to support instruction. But the work is worth the effort. And we shouldn't fret about using "non-standard libraries", because that is how OO programming really works. Stuart followed up with a question: Graphics seems to be the killer app of OOP; name two other kinds of examples that we can use. Kim suggested that the key is not graphics themselves but the visualization and immediate feedback they afford, and pointed to BlueJ as an environment provides these features to most any good object. In his closing statement for the con side, Michael closed with quote attributed Planck:
A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.
Stuart's closing statement for the pro side was more serious. It returned to structured programming comparison. It was hard to make the switch to structured programming in CS education. Everyone was comfortable with BASIC; now they had to buy a Pascal compiler for their machines; a compiler might not exist for the school's machines; .... But the trajectory of change was different. It worked, in the sense that people got it and felt it was an improvement over the old way -- and it worked faster than the switch to OOP has worked. Maybe the grieving is premature. Perhaps objects-early hasn't failed yet -- but it hasn't succeeded yet, either. According to Stuart, that should worry us. The folks on the panel seemed to find common ground in the idea that objects-early has neither succeeded nor failed yet. They also seemed to agree that there are many reasonable ways to teach objects early. And most everyone seemed to agree that instructors should use a language that works best for the style of programming they teach. Maybe Java isn't that language. In the Q-n-A session that followed, Michael made an interesting observation: We are now living through the lasting damage of the decision by many schools to adopt C++ in CS 1 over a decade ago. When Java came along, it looked really good as a teaching language only because we were teaching C++ at the time. But now we see that it's not good enough. We need a language suitable for teaching, in this case, teaching OOP to beginners. (Kim reminded us of Michael's own Blue language, which he presented at the OOPSLA'97 workshop on Resources for Early Object Design Education.) I think that this comment shows an astute understanding of recent CS education history. Back when I first joined the CS faculty here, I supported the move from Pascal to C++ in CS 1. I remember some folks at SIGCSE arguing against C++ as too complex, too unsettled, to teach to freshmen. I didn't believe that at the time, and experience ultimately showed that it's really hard to teach C++ well in CS 1. But the real damage in everyone doing C++ early wasn't in the doing itself, because some folks succeeded, and the folks who didn't like the results could switch to something else. The real damage was in creating an atmosphere in which even a complex language such as Java looks good as a teaching language, an environment in which we seem compelled by external forces to teach an industrial language early in our curricula. Perhaps we slid down a slippery slope. My favorite question from the crowd came from Max Hailperin He asked, "Which of procedural programming and OOP is more like the thinking we do in computer science when we aren't programming? The implication is that the answer to this question may give us a reason for preferring one over the other for first-year CS, even make the effort needed to switch approaches a net win over the course of the CS curriculum. I loved this question and think it could be the basis of a fun and interesting panel in its own right. I suspect that, on Max's implicit criterion, the mathematical and theoretical sides of computing may make procedural programming the preferred option. Algorithms and theory don't seem to have objects in them in the same way that objects populate an OO program. But what about databases and graphics and AI and HCI? In these "applications" objects make for a compelling way to think about problems and solutions. I'll have to give this more thought. After the panel ended, Robert Duvall commented that the panel had taught him that the so-called killer examples workshop that has taken place at the last few OOPSLAs have failed. Not that idea -- having instructors share their best examples for teaching various OO concepts -- is a bad one. But the implementation has tended to favor glitzy examples, complicated examples. What we need are simple examples, that teach an important idea with the minimum overhead and minimum distraction to students. I'm certainly not criticizing these workshops or the folks who organize them, nor do I think Robert is; they are our friends. But the workshops have not yet had the effect that we had all hoped for them. Another thing that struck about this panel was Stuart's relative calmness, almost seriousness. He seems at peace with his "back the '80s" show, and treats this debate as almost not a joking matter any more. His demeanor says something about the importance of this issue to him. My feeling on all of this was best captured by a cool graphic that Owen posted sometime near the middle of the session:
The second attempt to fly Langley's Aerodrome on December 8, 1903, also ended up in failure. After this attempt, Langley gave up his attempts to fly a heavier-than-air aircraft.
(Thanks to the wonders of ubiquitous wireless, I was able in real time to find Owen's source at http://www.centennialofflight.gov/.) I don't begrudge folks like Stuart and Elliott finding their comfort point with objects later. They, and more importantly their students, are best served that way. But I hope that the Michael Köllings and Kim Bruces and Joe Bergins of the world continue to seek the magic of object-oriented flight for CS 1. It would be a shame to give up on December 8 with the solution just around the corner. -----