[Bluej-discuss] programming as a random process

[Stephen Bloch]

Aryeh Friedman writes:
>Yes I am suggesting procedural first (but in a modified manner).  The
>reasons are:
>
>1. OO is a very powerful tool if you can write classes correctly and this
>means your logic must be correct in each method (and that *IS*
>procedural).   For example if they can't write a for loop then it is
>pointless to ask them to write a method that does something n times.

I teach recursion before iteration (on grounds that it doesn't 
require teaching a new language feature, only new ways of using the 
"function call" language feature you've already taught), so I have no 
problem asking students to write a method that does something n 
times, before I've mentioned for-loops.

>2. Much of the extra overhead ("I will explain later") your complaining
>about is *ONLY* present due to the fact it is OO

I'm not convinced of this.  Smalltalk and CommonLisp both do OO 
without much syntactic overhead.  Java has that overhead largely 
because it tries to resemble C++.

However, I agree with the point that beginning Java programs (and, to 
a lesser extent, beginning C++ programs) have an awful lot of 
syntactic overhead which isn't justified until the students see the 
benefits of OO.  And since the "big win" of OO is in writing large 
programs, that may not be for several months after they start CS1.



Here's my thinking about CS1, in a nutshell:

Most CS1 instructors think the course is about how to design and 
write a good program.

Most CS1 students, by contrast, think the course is about learning a 
new language, and in particular writing things in that language that 
get past the compiler without error messages.  It's understandable 
that they would think so: compiler error messages are much more 
obvious and concrete than abstract principles of good programming 
practice, or even than right/wrong answers.

Furthermore, compiler error messages lend themselves to a sort of 
"mental masturbation": compile the code, get an error message, fix 
it, compile again, get another error message, fix it, convincing 
yourself that you're making progress when you haven't actually had a 
fully conscious thought in hours.  Reacting to compiler error 
messages is passive, reflexive, and mentally easy, much like shooting 
enemies as they pop up in a video-game; designing a program "from 
airy nothings" is active, creative, and mentally difficult.  Which 
will the average 17-year-old prefer?

The more time and energy students spend wrestling with the language 
and the compiler, the less time and energy they (or the instructor) 
have left to think about designing and writing a good program.  So 
ANY programming language is a necessary evil: necessary in order to 
write real programs that really run on real computers, but evil in 
that it distracts from more important things.

To avoid giving students the impression that it's about language and 
syntax and compiler error messages, I try to follow two rules:
1) introduce each language feature one at a time, and only when it's 
necessary in order to solve a problem;
2) use a language with as few features as possible.

If you use Java from the command line, writing and running 
stand-alone apps from day 1, you've violated rule 1 in spades:
	import java.io.*;
	class Program1 {
		public static void main (String[] args) {
			System.out.println ("Hello, world!");
			}
		}
uses about twenty new concepts, most of which are irrelevant to the 
problem of producing the message "Hello, world!" (and why would that 
be an interesting problem anyway, if not to illustrate writing a 
class, a method, and an output statement?)

As for rule 2, you can do this by choosing a completely different 
language (like Scheme or Smalltalk), or by using a carefully selected 
language subset (ideally enforced by the compiler).

-- 
					Stephen Bloch
					sbloch at adelphi.edu