Reaction for: Getting Close to Objects by Andrew Schulak

I find it very interesting, and somewhat refreshing to hear someone talk about making object-oriented concepts more concrete when normally we talk about topics in Computer Science as being abstractions upon abstractions.

Object-oriented thinking (when it comes to programming) is very natural for us to understand because we view our world in objects. We tend to see trees, cars and books. Not collections of lines, shading and color (though it may be argued that artists see the world in this way as well). It is not surprising that when it comes time to organize these understandings that it is very difficult for some people, especially beginners. We are taking something concrete which we know something about and expressing them in some variant of some abstract language. This can be and often is very confusing. We often lose a sense of the concreteness of the system in this process.

Being able to view and construct one such system without losing this concreteness may be a very viable means of programming. But my question is how concrete can you get? At some level I am going to have to describe a set of actions in some sort of language. Is it useful to be totally object-based in our programming? I don't know. It seems to me, with all things, a mix is probably best. It is nice to setup object-relations graphically, manipulating the objects themselves so that one gets a good view of the system. But is also nice to be able to have a language rule to be able to describe actions that objects can perform. In order to fully concretize all object actions it seems to me that the types of things objects could do would have to be very limited so that one could just plug-and-play essentially.

But this might not be so bad. Then everyone would be forced to reuse code. Oh, I want this object to be able to manipulate this other object in some way? Ok, I'll just take Bob's module and plug it in. It might be an interesting project to construct an environment with a moderately large amount of such actions and see what types of systems users could build given already canned actions. Of course actions could be parameterized so loop actions could have different time stamps. But is this kind of what is going on subtly with GP? Maybe. GP has objects that can be plugged in like this for loops (I think) and boolean queries (if statements).

One last factor to think about is the limiting factor of two dimensions. So far I think most environments or design environments are all two dimensions. What kind of options would creating an environment like this have in three dimensions. Certainly the user would have a wider range of freedom and expression. What do you all think?


Reactions


Jon:

Well, first of all I'm not sure I agree that Object Oriented programming is necessarily easier, because "we view our world in objects." Personally, I don't look at the world around me, and immediately classify all of existance as a set of objects interacting. There are many ways to think of the world, and an object-based way is only one way. Also, while it is probably a closer analogy to the real world than, say, functional programming, OO is still a very definite form of abstraction. Finding a way to represent a thing in the world (or a computer program) in an object construct is difficult. Of the hundreds (if not thousands) of characteristics I may have, or the virtually unlimited number of things I am capable of, determining what the salient features of an object are is a rather abstract thing. So I don't really agree that even OO is that "concrete."

However I will agree that being able to visualize objects will probably help many people to conceptualize them, and deal with them more easily. As far as the plug-and-run idea that you have, I think Java Studio is similar to that idea. Studio allows you to attach various components together, using a GUI. You can define your own components, (as Java Beans, I believe), and connect them to existing components. You can also specify what exactly they do (for example, there is a generic button you can use, but there are seperate dialog boxes which allow you to specify what the button does.) You might consider taking a look at that if you are interested. It exists in /pro/java/studio.

In regards to the 3D question, I think that is an interesting one. Modeling object relationships on a two-dimensional plane can be difficult, as many complex Rumbaugh diagrams will attest to. So would it be easier in 3D? I don't know. One current limitation of 3D is that, for the most part, it gets projected onto a two-dimensional screen. So, even if you are moving through a 3D design, it is very difficult to manipulate it easily, and take advantage of some aspects which could be useful (such as proximity) to looking at a design.

Now, if it were possible to create an object design environment in full 3D, via some sort of virtual reality apparatus, that would be very interesting. Of course, limiting yourself to 2 dimensions is often nice, even if for no other reason than being able to print out your design on a piece of paper. Whether expanding an environment to three dimensions would result in a definite increase in productivity or understanding is something I am unsure of, but would be an interesting topic to pursue.


[BACK]