I am planning to use Self in the practical part of an introductory course on OOP. Who has experience in teaching Self and can provide me with related tips and/or material for such a course? What is the difference to teaching class-based languages?
Plase reply to gk@cs.bonn.edu.
Thanks.
Gunter Kniesel Institut fur Informatik III e-mail: gk@cs.bonn.edu Universitat Bonn gk@cs.bonn.de Romerstr. 164 Phone: (+49-228) 550-276 D-53117 Bonn (+49-228) 550-292 Germany Fax: (+49-228) 550-382 ---------------------------------------------------------------------
I am planning to use Self in the practical part of an introductory course on OOP. Who has experience in teaching Self and can provide me with related tips and/or material for such a course? What is the difference to teaching class-based languages?
Gunter,
Your message comes at an ideal time -- the Self group are currently putting together some ideas and projects to encourage the use of Self in the initial teaching of OOP.
We would be delighted to include you, and anyone else considering using Self for teaching, in our plans and discussions. To get the ball moving, perhaps you could get in touch with me by email, so that we can find out more about our respective plans? I'm replying to the whole list; anyone with similar plans is encouraged to mail me.
If there is sufficient interest, we may consider running a workshop or BOF on the teaching of Self at OOPSLA (or ECOOP, too, I suppose) -- anyone who would consider attending such an event, please mail me.
-Mario Wolczko
Sun Microsystems Labs., Inc., 2550 Garcia Ave, M/S MTV 29-116, Mountain View, CA 94043, U.S.A. tel: 415 336 6022, fax: 415 969 7269.
Mario Wolczko writes:
I am planning to use Self in the practical part of an introductory course on OOP. Who has experience in teaching Self and can provide me with related tips and/or material for such a course? What is the difference to teaching class-based languages?
Your message comes at an ideal time -- the Self group are currently putting together some ideas and projects to encourage the use of Self in the initial teaching of OOP.
We would be delighted to include you, and anyone else considering using Self for teaching, in our plans and discussions. To get the ball moving, perhaps you could get in touch with me by email, so that we can find out more about our respective plans? I'm replying to the whole list; anyone with similar plans is encouraged to mail me.
Andy van Dam and I talked to Randy earlier this year about this some. I've included the body of this at the end.
If there is sufficient interest, we may consider running a workshop or BOF on the teaching of Self at OOPSLA (or ECOOP, too, I suppose) -- anyone who would consider attending such an event, please mail me.
I'd be interested.
Brook
ps -- here's the mail -- how we've been thinking about Self for graphics and for introductory programming
Randy> 1] Picked up some rumour (Brad Myeres?) that you have been thinking Randy> about the utility of Self. Are you in fact thinking Selfish thoughts, Randy> and if so, what thoughts are you thinking?
For our own work in interactive 3D graphics, there's two ways we find Self interesting. The first and most fundamental way is that we feel prototype/delegation object systems match the needs of interactive graphics much better than class-instance systems. As systems jocks, and not programming language designers, we implemented what turned out to be very similar to a delegation-based object system -- we just didn't know it was called that. That system was described in a 1991 SIGGRAPH paper by Zeleznik et al. We later investigated why we might want to use a delegation system, and why we feel it is better for graphics. The short answer to why we feel this way is that objects provided by graphics systems end up implementing some sort of dynamic, per-object sharing (using the terms of the "Treaty of Orlando"). A more detailed version of this argument can be found in Conner and van Dam, "Sharing Between Graphical Objects Using Delegation", from the 1992 Eurographics Workshop on Object-Oriented Graphics (which we can provide in PostScript form if you are interested).
The second way Self is interesting is as a possible replacement to our own home-brew programming language. This possibility takes the burden of supporting a language off of our shoulders. Unfortunately, we run on a variety of platforms, including Suns, HPs, DECs, IBMs and SGIs. Self is as yet a Sun-only system, and, from what we gathered from people in the Self group (Urs Holzle in particular), porting the compiler would be a major undertaking.
Randy> 2] We've been thinking about using Self as a way to teach the Randy> fundamental concepts of object oriented programming (things like Randy> message, object, method, inheritance, poymorphism, overriding, etc.). Randy> Since Self is minimalist in semantics, it should be a good medium for Randy> learning this stuff. And a good graphical interface could make these Randy> things very clear. Randy> Self could also be used to teach about itself - (all Randy> of the above plus Self-specific semantics and syntax). This could make Randy> it a nice environment for undergraduate projects. Randy> What are your reactions to this general line of work?
In general, we're very excited by the possiblities Self shows in this regard.
In particular, Self seems to have the potential to do for teaching object-oriented programming what Abelson and Sussman does for teaching procedural or functional programming. As youpoint out, the minimalist semantics is the key part here. One could begin by teaching a single object in isolation (as we do in our new first-semester course in programming, which is object-oriented from day 1). Adding multiple objects is easy. Adding more and more objects leads one to want to factor commonality. Hence we can introduce inheritance. Classes fall out naturally as soon as you notice that lots of objects have similar behavior but different state. As you need new functionality, you can build it. Need a conditional? Build it. And so forth. Instead of new language syntax and semantics, we simply use particular idioms.
So that's our thinking (in a nutshell) about how Self might be used for teaching object-oriented programming.
We're not using Self in our first-semester programming course. Why not? Principally because we felt we needed to minimize the cost of switching the curriculum to object-oriented programming and we felt that we should not stray too far from what is being used in industry (the industry we're preparing our students for), namely C++.
The shift to teaching object-oriented programming in the first semester was (and continues to be) a big change. We felt the need to mimimize that change by sticking with a language pretty close to what people were used to -- namely object extensions to Pascal based on Turbo Pascal. This means the language is similar in feel to C++ (which we use in later courses), and not too alien to students (and faculty and TAs) who have been using Pascal up until now. Unfortunately, we get all the pain of a complex hybrid language that you might expect.
At this point, we've just finished the first semester of our object-oriented first course -- a draft of our textbook is with reviewers (we can send you a copy of this, too, if you'd like). The semester has been rough -- we've had to redesign the entire text, syllabus, and every single assignment. All of our TAs had to be retrained for the new course. It was, frankly, quite a lot of work.
As a consequence, for the next couple of years, we simply want to smooth out the course. We don't want to completely revamp the course yet again right away -- it needs some stability.
However, that doesn't eliminate our interest in Self as a programming language for a first course. It is something we plan to continue working on. Many of the current TA staff, as well as the grad students and members of the graphics group are interested in Self. Interest is high enough that we're considering running a class in it, perhaps this spring, investigating its usefulness both for graphics and for a first course.
self-interest@lists.selflanguage.org