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

[TJ Evert]

>
> >What's more simple (to a 1st-year student):
> >
> >       a  = b + c
> >or
> >       a.set( plus(b, c) )
>
>
> Obviously, the latter (although it only uses one syntax rule, twice)
> takes a lot more typing and is more visually confusing.


 You're joking, of course. You clearly don't teach high school students...


The latter has three problems.  For students who are comfortable with
> math, it LOOKS like an old friend, but it actually does something
> different.  For students who aren't comfortable with math, it looks
> like an old ENEMY: they already know that they can't do that math
> stuff, so they conclude that they can't do computers either.  And for
> either kind of students, after (or perhaps before) they're
> comfortable with that syntax, we show them the OTHER syntax
>
I've heard this defense before: "Bad math students will become good
object-oriented programmers." I was an awful math student (before switching
to physics and then math - one of life's great ironies...)

At the level of an introductory college course, programming requires careful
thinking about how to represent data. This is not to say that you have to
have a strong background in math to program, but you definitely need to be
able to think analytically and reductively.


>Mind you, the aforementioned "students who aren't comfortable with
>math" have a panic attack as soon as they see a number or an
>arithmetic operator.  Which is why the last time I taught CS0, I had
>the students working with pictures (defining variables and functions,
>doing function composition, and developing a sound, test-driven
>methodology) for several weeks before we introduced numbers and
>arithmetic.

A student who has "a panic attack as soon as they see a number or an
arithmetic operator" should probably not study programing. Just think of
what will happen when they get to arrays...

However, you can introduce students to simple OOP syntax all you want
(like the classic "Shape" classs). It's not too threatening and does take
the edge off programming when you begin. I certainly wouldn't jump into
recursive method calls on day 1. I introduce objects right after I cover
primitive data types and operators because they are a *data type*. Hence the
analogy

primitive:operator :: object:method

So, you're two weeks or so into the course - what do you do next?

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.

I strongly believe that students learn best what they've studied longest. I
think we're probably both in agreement when I say that procedural topics are
the hardest part of a 1st-year Java class. I think you'd also agree there's
no way of really getting around teaching procedueal topics. So if you *have*
to teach it (being an high school AP teacher, I do) it makes sense to me to
get to it (and past it) as soon as possible.

Procedures are hard. There is ceratinly a psychological cost. That's endemic
to any course with difficult material. Ultimately, you can teach procedures
pretty completely without OOP. The reverse isn't true.

Procedures are "nuts and bolts". Objects are "blueprints". As experts, we
certainly think "Make blueprints first, build with nuts and bolts later."
That's the essence of top-down design. But you can't learn how to build
houses by just turning the light switches on and off. You hammer together a
box, and then another, and put them together and say "house". You have to
intimately understand what an attribute is, how to change it properly with a
method, and then put it all together and say "class".


>Right...  Yes, Scanner does make console I/O easier than it was
>before, and as we all know, it's still something of a pain.  More
>importantly, it's completely unlike Java GUI I/O, which is completely
>unlike older-Java console I/O, which is completely unlike C++ I/O,
>which is completely unlike C I/O, which is completely unlike FORTRAN
>I/O, which is completely unlike COBOL I/O... almost anything you
>learn about I/O in one language is useless in another language.  By
>contrast, a lot of what you learn about variables, functions,
>conditionals, datatypes, etc. transfers pretty well from one language
>to another.

Absolutely right - which is why the AP committee doesn't actually demand
teaching it. Unfortunately, it makes for pretty boring programs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bluej.org/pipermail/bluej-discuss/attachments/20071129/1012b3ac/attachment.html