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

[TJ Evert]

 > From: "Lon Levy" <lxl at oregon.k12.wi.us>
> 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.

It's funny you bring up geometry - That was the "main" subject I taught - AP
CS was just an elective. I used geometry as a continued theme in my class:
"size" variables, "area" methods, "Shape" classes, drawing "Shape" objects
with applets, and even a "Scalable" interface. It worked out quite nicely.

 Not to quibble, but I would consider the above to be "a strong foundation
in math".


> From: "Lon Levy"
 > There are a few bizarre things about Java that make it much easier to
start with a simpler language ... 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 checked out Scheme - intriguing, but sadly, I've never thought I had the
"luxury" of starting another language. I feel so pressed for time by the end
of the year. I'm toying with the idea of Javascript as an intro, though. Any
thoughts?

As for methods, it's less confusing if you approach it from a (for lack of a
better word) "historical" view point.
1. methods (functions, sub-routines, etc.) are a just word for "containers
of code"
2. they can return values
3. if they don't, they are "void"
4. if they act on objects, they don't have to be static


> From: "Lon Levy"
> 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.

I disagree - the need is exacly the same: pass the AP exam...


 > From: "Lon Levy"
>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).

You taught *all* that without creating a class, using a "main" method or
calling "System.out.print()"?  Impressive...


 > From: Michael K?lling <M.Kolling at kent.ac.uk>
> Understanding this is not easy, and thus changing between one and the
> other is not easy. We are not doing our students a favour by requiring
> them to swap between these two models early (because it requires them
> to fully understand this, which many people don't).

I think this point is really where this discussion is centered - the idea of
"two models". I get the feeling that "objects-first" proponents view the
debate as "geo-centric" (procedures) vs "heliocentric" (OOP). It's as though
they have to overturn a whole paradigm (and 50 years of programming
exercises, lessons, insight, ...).

Object-oriented programing is, like th heloicentric model, *right*, in that
it's where we (ultimately) want all our students to get. But we all still
"think" that the sun rises. No matter how many times you draw a solar
system, it's simpler and often easier to just refer to the stars and
planets "moving" though the sky. I've never seen an astronomer worry about
confusing a class by "switching between the two models" because while we all
know which is the best from a "global" perspective (think "top-down" design)
it's just easier to work in the "local" one (implementing methods). The
latter is also easier to introduce...


> > I strongly believe that students learn best what they've studied
> > longest.
>
> I perfectly agree with you on that. That's why, if we want them to
> learn OO, we should teach them OO longest (i.e. from the start).
>
> > I think we're probably both in agreement when I say that procedural
> > topics are the hardest part of a 1st-year Java class.
>
> No, I don't agree at all. Object interactions are harder.


More subtle, perhaps. Tracing values in method calls is hard - thank God for
Jelliot!

I think it's easier to discuss these issues when "armed" with a strong
foundation in data types, variable scope, passing values to variables, etc.
All this can happen quiet early in "historical" programming".


> > I think you'd also agree there's no way of really getting around
> > teaching procedueal topics.

> I think what you really mean here is is not procedural programming in
> the sense of the structuring paradigm, but just subroutine calling
> with parameters and return values. That's an element of many
> paradigms, and needs to be taught. But in a context that does not
> require students to later un-learn and restructure the overall
> understanding of structuring the program.

I guess so - C++'s "functions" were the probably most appropriate name. I
guess my point is that writing static methods (like Fibonacci(n) or GCD(x,
y) ) help more in writing object methods more than the other way around.


> I think what is ultimately behind this is a very strong tendency of
> teachers to teach in the exact order in which they themselves have
> learned. This somehow becomes the "natural order" and the only way to
> "proper understanding" of programming.

Ah, the "Fuddy Duddy" argument. Procedures-first in certainly not the only
(or neccessarily best) way to teach Java. But it's ceratinly viable. This
whole debate started on whether a "main compile" method should be a feature.
So the questions isn't "What's the best way to teach programming?" It's
"What will help students learn Java?"

Regardless when it happens, student will have to evaluate procedures.  As
trendy as it may be to rail against text output, when you have to run a
proceedule 50 times to figure out why it (doesn't) work, a "main compile"
method makes procedure evaluation faster and therefore easier to learn. It's
a simple as that.


> I agree, we should start with the basics. But that's not procedures,
> that's assignment and goto. Procedures were just tacked on later.

Because "goto" is not in the language (for good reason) I think "history"
has shown us why goto was a painful (but very useful) step along the way.
It's an important lesson, though, and I'm sure if we could "look into" any
repetition-structure, we'd find "goto" embedded into the machine code.


> But wait, assignment is a radically modern, new invention: where we really

> should start is with load and store into/from registers. Ahh no:
> that's really a too high level abstraction: we need to understand how
> memory works first. Let's start with flip flops. But no, that really
> assumes too much: I actually think that we should start with gates. No
> atoms, actually.

Remember "new math"? You may not - I'm not too sure it caught on outside of
the US. Teachers were trying to get 6 year-olds to do their math problems in
base-7 to "free their minds". Ironically, it was intended to teach kids
binary to help them learn about logic gates and flip flops...

It was abandoned, of course. Soon after, calculators were introduced in
grade schools to "ease the transition". Meanwhile, the rest of the world did
their long-division and we've seen where all the programming jobs have gone.
I'm just ranting, now...

The point is low-level "rigor" is essential to master later, higher-order
concepts. But perhaps it's just a matter of taste
.

> Now, I (and, I assume, you) don't really want to start with atoms.

 Not unless you mean LISP! Actually, many texts start with bits, Bytes,
hex, and ACSII. It makes typecasting primitives and colors a breeze...


> So then people start making these choices defining what are acceptable
> black boxes, and what really needs to be understood first before being
> allowed on to higher abstraction levels. Okay, so we draw a line. The
> real question then is: where do we draw that line? What are the
> acceptable black boxes?

Fair enough. My answer would be "Whatever get's students writing *useful*
programs fastest." I'll admit, that's a pretty subjective criteria, but
after the novelty of writing code fades away, what can students program in
the first few weeks that they wouldn't be able to on their own?

 I have to do some hand-waving in the beginning on what classes and objects
are.
It's fun to get to games like "SevenGuesses" (to guess a number from 1 to
100 - great into to binary sorting), "palindromeTest()" to introduce Strings
as "arrays", or novelties like "bottlesOfBeer()" or animation for loops .
It's a computer's abiltiy to run repetative tasks that makes it truly
useful.


> I have had that conversation with quite a few different people over
> time. My impression: Where people draw this line is mainly a function
> of their age. It is, in fact, a direct function of how they themselves
> started to learn about programming.
>
> Everything I had to learn is obviously required knowledge for a proper
> understanding of programming, and those bits that I don't really
> properly know about are obviously not needed. The pedagogical decision
> becomes a the result of the year-of-birth lottery.
>
> I'd like to argue that, yes, we have to draw the line somewhere, but
> we have to make the choice where to draw it based on pedagogical
> considerations, not on personal history.

A bit unfair, I think...


> And I do find it easier to teach student about objects first, and
> about methods in the context of object behaviour implementation, when
> my goal is to end up with an understanding of OO.

An understanding of OO has never been the problem. OO is the "easy" part
(especially with nice tools like BlueJ). Sure, there are some fine points,
but those are rarely the ones my students struggle with. It's nitty-gritty,
*procedural* things like how trace though a recursive function, "shuffle"
the elements of an array, or evaluate the logic of TicTacToe. It's also the
"obvious" things we teachers have long since mastered, like formatting code,
documentation, or basic spelling.

*These* are the things we should be debating - features like:
1) folding-code
2) drag-and-drop structure templates (like in Alice)
3) simpler code-formatting tools ("hard" tabs instead of spaces?)

and the aforementioned "execute main" keystroke command (I guess I'll just
have to write a script in VB...)

As fun as this has all been, we should all be focusing on these last points.

Thanks,
TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bluej.org/pipermail/bluej-discuss/attachments/20071130/efe265ae/attachment-0001.html