[Bluej-discuss] bluej-discuss Digest, Vol 53, Issue 27

[Michael Kölling]

On 30 Nov 2007, at 03:09, TJ Evert wrote:

> They'll have to actually start *writing* classes at some point. Then  
> you get to the day when you explain what a class actually is: a set  
> of attributes and the methods. Data and functions. And then it hits  
> them that they actually have to do procedural (call it "functional"  
> if you like - I see no real difference) programming to implement  
> just about any basic class they want to write.

It seems to me that there is a deep misunderstanding of what  
procedural, functional and object-oriented really is. Object-oriented  
structures are not procedural (and, btw, procedural is also not  
functional).

Also confusing the discussion sometimes is that some people use  
procedural and imperative as if it was synonym. It isn't.

In procedural programming, the procedure is the top level code  
structuring mechanism. Programs are represented as a set of  
procedures, plus state. This means that you have global variables (of  
which style guides tell us to have few), and everything else you want  
to operate on has to passed in to the procedures as parameters.

In object-oriented programming, the top level code structuring  
mechanism is a class. All code is structured as a set of classes. Now,  
classes have methods, and they might seem similar to procedures at  
first glance. But they are not the same.

I was in the unfortunate situation once where I was teaching on a  
course that introduced procedural programming first, and then  
introduced classes and objects. There were several problems: We had a  
style guide in the first part that said "No global variables". Now, to  
beginners instance variables feel quite like global variables (even  
though they are not), and many could not understand why this was  
suddenly okay. Also, many students tries to pass the object they  
wanted to operate on as a parameter to the method. That's what you  
would have to do with procedures. Many students were struggling  
severely (and one of the really bright ones, who got the point, came  
to me and said "Why didn't we do this in the first place?" - exactly  
what I was thinking!)

The fundamental difference is that procedures are free floating code  
that receives its data via parameters. Methods belong to an object.  
They are always executed in the context of an object (or class as a  
special case), and they operate on the state of the object (augmented  
with parameters).

The similarity is syntactical, the difference is semantic, and thus  
much more profound.

Understanding this is not easy, and thus changing between one and the  
other is not easy. We are not doing our students a favour by requiring  
them to swap between these two models early (because it requires them  
to fully understand this, which many people don't).

Now, both procedural and OO may be imperative (as they often are) -  
that's another discussion. Functional languages differ in the  
treatment (or lack thereof) of state, but that, too, is another  
discussion.

So, when we start writing classes, we present all of it as  
implementing behaviour of objects. Code does not just float free in  
space.


> I strongly believe that students learn best what they've studied  
> longest.

I perfectly agree with you on that. That's why, if we want them to  
learn OO, we should teach them OO longest (i.e. from the start).

> I think we're probably both in agreement when I say that procedural  
> topics are the hardest part of a 1st-year Java class.

No, I don't agree at all. Object interactions are harder.

> I think you'd also agree there's no way of really getting around  
> teaching procedueal topics.

I think what you really mean here is is not procedural programming in  
the sense of the structuring paradigm, but just subroutine calling  
with parameters and return values. That's an element of many  
paradigms, and needs to be taught. But in a context that does not  
require students to later un-learn and restructure the overall  
understanding of structuring the program.


I think what is ultimately behind this is a very strong tendency of  
teachers to teach in the exact order in which they themselves have  
learned. This somehow becomes the "natural order" and the only way to  
"proper understanding" of programming.

We have heard the argument before that you have to start with the  
basics - procedures - to get a proper understanding. Why stop at  
procedures?

I agree, we should start with the basics. But that's not procedures,  
that's assignment and goto. Procedures were just tacked on later. But  
wait, assignment is a radically modern, new invention: where we really  
should start is with load and store into/from registers. Ahh no:  
that's really a too high level abstraction: we need to understand how  
memory works first. Let's start with flip flops. But no, that really  
assumes too much: I actually think that we should start with gates. No  
atoms, actually.


Now, I (and, I assume, you) don't really want to start with atoms. So  
then people start making these choices defining what are acceptable  
black boxes, and what really needs to be understood first before being  
allowed on to higher abstraction levels. Okay, so we draw a line. The  
real question then is: where do we draw that line? What are the  
acceptable black boxes?

I have had that conversation with quite a few different people over  
time. My impression: Where people draw this line is mainly a function  
of their age. It is, in fact, a direct function of how they themselves  
started to learn about programming.

Everything I had to learn is obviously required knowledge for a proper  
understanding of programming, and those bits that I don't really  
properly know about are obviously not needed. The pedagogical decision  
becomes a the result of the year-of-birth lottery.

I'd like to argue that, yes, we have to draw the line somewhere, but  
we have to make the choice where to draw it based on pedagogical  
considerations, not on personal history.

And I do find it easier to teach student about objects first, and  
about methods in the context of object behaviour implementation, when  
my goal is to end up with an understanding of OO.

Regards,

Michael