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

[Lon Levy]

Hi TJ,

I do teach high school students and clean method calls are far less confusing for my kids than quasi-algebraic notation.  I believe Stephen was entirely serious and, while he is at the college level, correctly reflecting what I see in my kids.

My AP students are required to have had or be in their second year of algebra.  This is not a "strong background in math", but it does mean a couple of things:  My AP students have to understand what a function is and what a composite function is.  My AP students need to have a reasonable understanding of Order of Operations (and I really want to kill My Dear Aunt Sally).  My AP students need to have an introduction to proofs, which is being taught less and less as time passes.  I find myself making up for more and more geometry in my Introduction to Computer Science (pre-AP) course every year.

There are a few bizarre things about Java that make it much easier to start with a simpler language.  For example, in the Beginning Student Language of DrScheme, every function returns a value.  In Java, methods return a value except that sometimes there is something that is neither an object nor a primitive listed as the return type:  void.  That is confusing.  You can't instantiate void.  Like null, it is a serious breach of the object oriented paradigm.  Primitives are also a breach of OOP.  To learn more about this, if it is of interest to you, check out the information on www.teach-scheme.org, which includes links to a free on-line text.

I started teaching AP Pascal and have taught AP C++ and AP Java.  The needs are not the same today as they were in the halcyon days of Pascal.  Unlike you, I do not try to "get to it (and past it) as soon as possible".  I spend three quarters of a school year on very simple functional programming.  In DrScheme, my students learn recursion (loops wait until fourth quarter), lists, trees, structures, searching and sorting, data unions, and more.  They learn all of that with fewer syntax rules than are necessary to do a traditional Hello World in Java.  (I don't teach Hello World).

I spend a full week away from computers to transition to the concept of Objects, using lots of role-playing materials from Dave Levine at St. Bonaventure and other classroom exercises to understand how class hierarchies work.  Somehow, despite this different approach, all of last year's AP students passed the data structures exam and exactly half of them earned "5".

a.set(plus(b, c)) is much clearer than a confusion between balanced algebraic expressions and assignment.

Regards,

Lon.

Lon Levy, MS-CSEd
Computer Science Teacher
Volunteer Computer Club Advisor
Oregon High School
608-835-1316
LXL at oregon.k12.wi.us
cs at levytree.net

non somnos requiem

>>> "TJ Evert" <tjevert at gmail.com> 11/29/07 9:09 PM >>>
>
> >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.