I was very encouraged by the premise of the paper, the desire to make the programmer's model of the program match more closely with the environment's model of the program. It seems natural to make an environment that helps the user to build their model of the problem.

Where I got somewhat lost was when the authors stated that objects were too distanced because the programmer could not directly reach them. I took this to mean that on screen representations of objects could not be directly manipulated: but this isn't true anymore.

Although I'm trying not to be cs015 specific, I will use GP as an example. The react methods, buttons, and slide bars allow the programmer to build their own methods for interacting with their objects, and the programmer can directly manipulate their objects. Perhaps it is a bias, but I really didn't agree with this part of the paper.

I do, however, strongly agree with the paper's conclusion. OOP provides the chance to move away from text based environment. Having objects more closely resemble the programmer's "mental model" of the problem allows beginning programmers to visualize what they are thinking, and this can be very helpful. While I don't agree on some of the paper's views on objects, I do feel that it raises many valid points.

I think what the article was trying to get at is that most tools for visualizing an object takes a look at a specific aspect of an object. For example, the instance variables of an object may be listed, or the method call stack of a program can be created. However, these are views of certain aspects of the object, rather than the object in its entirety. Also, when you use GP as an example, you are thinking of interacting with objects on the user level, not the programmer level. A programmer would want a visualization of an object with all its instance variables, its methods, its current state, and its relationship to other objects. The class browser is the closest thing we have in 15, but I think they were shooting for something much more graphical.