[Bluej-discuss] bits of syntax to expose, and OO-early (was How to call an accessor method...)

[Stephen Bloch]

Ian Barland writes:
>After I was noticing that each semester one or two students will spend hours
>and hours thrashing because they wrote (what seems reasonable to them)
>`i=i++`, yes I now avoid using ++ for at least two weeks after introducing
>loops.  (Still, some students have seen ++ on their own, and still fall into
>that trap.)
>
>I don't actually *require* students to spell out `this.` or `i = i + 1` or
>always use getters/setters, but the code I show in class does these things.

I would certainly introduce "i = i + 1" BEFORE "i++" or "++i", 
because the former is built from syntax rules they've already seen. 
And really, the only reason to mention the autoincrement operators 
(or the automatic "this.") at all in a first-year course is so the 
students can read code written by other people.

>(Over time, I'm becoming less and less convinced that OO is any less 
>confusing for
>beginners than procedural programming.)

and Aryeh Friedman adds:
>OO is great in professional hands and sucks otherwise... I mentioned 
>to a former boss of mine who accused me of falling into the OO trap 
>... that you shouldn't be allowed to use OO until your out of school.

Class-based OO is a terrific way to organize a multi-KLOC program. 
But first-semester programming students don't write multi-KLOC 
programs.  Which means they have to pay the price of OO (in syntactic 
complexity and levels of semantic abstraction) without reaping much 
benefit -- at least at the time.  An argument could be made that 
they'll reap the benefit later, when they DO need to write multi-KLOC 
programs and are already fluent in the syntax they need to do OOP... 
but the delayed gratification at least makes one question the 
effectiveness of OOP in a first course.

What exactly is it about OOP that we WANT to teach in a first course? 
Is it simply that students need to start learning the syntax early so 
they've actually got it down by the time they need it?  If so, then 
we'd better start in the same language in which we plan to eventually 
use OOP, no matter how horrible that language is.

OTOH, is it the idea of defining data types to represent important 
aspects of the problem, and then writing algorithms and code based on 
those data types?  That's a large part of the TeachScheme approach: 
we teach a data type, then how to write code (and tests) for that 
data type, then another data type, then how to write code for it, 
lather, rinse, repeat.  By the end of a semester, my non-majors with 
no programming experience have learned to define and write code for 
primitive types, classes with fields, variant/polymorphic types, 
self-referential types such as linked lists and trees, parameterized 
types (e.g. Java templates), and higher-order types such as 
functions.  (Admittedly, we don't spend a lot of time on the 
parameterized and higher-order types in a first course for 
non-majors.)

Aryeh again:
>At least you have the good sense to not start the Java vs. Scheme 
>debate again.

The approach I've described above could in principle be done in 
Scheme, Java, C++, Pascal, Python, C, Smalltalk, etc. -- probably any 
high-level language invented in the past forty years.  I've done it 
in Scheme a number of times, and once or twice each in Java and C++. 
In my experience it was easier in Scheme, but YMMV.

The other reason to favor a functional-first approach is that it's so 
much easier to write tests for a functional program than for a 
stateful one.  If you want to inculcate good testing habits in your 
students from the beginning, that's a significant incentive.  Again, 
a functional-first approach CAN be done in almost any language; it's 
just a bit more natural in Scheme than in many other languages.

-- 
Dr. Stephen Bloch
Math/CS Department
Adelphi University
sbloch at adelphi.edu