[Bluej-discuss] Objects When, languages, etc.

[Stephen Bloch]

"TJ Evert" <tjevert at gmail.com> writes:

>What's more simple (to a 1st-year student):
>
>       a  = b + c
>or
>       a.set( plus(b, c) )

Quibble: the latter really should be
	a.set(b.plus(c))

Obviously, the latter (although it only uses one syntax rule, twice) 
takes a lot more typing and is more visually confusing.

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
	a.doSomethingWith(b,c)
For some kinds of things, you're supposed to use the algebra-looking 
syntax, and for other kinds of things, you're supposed to use this 
funky thing with the period, parentheses, and commas.

>Note - No joke: there's a growing minority of college instructors that are
>pushing for LISP to be a 1st-year language!

That would be me :-)  Anybody else who's curious about the approach, 
including how we transition students from functional in Scheme to OO 
in Java, is invited to attend an NSF-funded, one-week workshop next 
summer (Barry and Lon have already attended in previous years).

>  There are extremes to any position. My aim isn't a reactionay throwback to
>assemly (or bit-coding Turing machines). The ultimate questions is "Will
>this help a student who knows *nothing* about programming?"
>
>However, the *real* $64,000 questions is "What prior experience does a 1st
>year computer science student have?" Some algebra, experience working with
>files, maybe a little bit of logic with Venn diagrams. So (especially in the
>first semester) why not use what they're used to:

I'm with you this far, but

>algebraic statments, Boolean algebra, control structures - 
>procedural programming!

Hold on now.  Yes, they've seen Boolean algebra.  Yes, they've seen 
algebraic "statements", but in a different sense of the word 
"statement" -- "a = b + c" is either a Boolean-valued expression or 
an assertion of eternal equality, not a state change.  And no, they 
haven't seen control structures.  They have, however, taken Algebra 
I, and probably some other math classes that involve functions.  So 
how does "procedural programming" come out of this?  I would say, 
instead,

"So (especially in the first semester) why not use what they're used 
to: algebraic expressions, Boolean operators, functions applied to 
arguments -- functional programming!"

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.  The fact that the syntax didn't resemble that of high 
school algebra was actually an ADVANTAGE, since it meant the students 
didn't already "know they couldn't do it."  When we did get to 
arithmetic, it used the exact same syntax rule as the functions 
they'd already been using to manipulate pictures.

>There is one exception to the above argument - I've seen several curricula
>that employ a "Turle-graphics" class as a first-week exercise. As
>"pro-procedural" as I might seem, it's a great way to get students to start
>*thinking* about programming.

How is this an exception?  Turtle graphics (e.g. Lyn Turbak's 
"buggle" Java exercises) is a great way to teach 
imperative/sequential/procedural programming (there may incidentally 
be several different turtles, but really the emphasis is on stateful 
imperatives, sequence, and procedures), and if I had to teach 
imperative/sequential/procedural Java as a first language, I would 
use it again.

>PS - With the Scanner class, I/O is actually pretty simple. It's
>*object-oriented* - what could be simpler?  ; )

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.
-- 
					Stephen Bloch
					sbloch at adelphi.edu