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

[TJ Evert]

> >IMHO, objects should be "introduced" early and "taught" later.
> >
> >We want out students to have access to certain object classes ASAP
> >("Scanner" for user input, etc.) So, I introduce objects right after
> >primitives in a chapter on "Data Types". It's apporpriate here to discuss
> >objects as a data type (aliasing, casting, autoboxing, etc.) I then go on
> to
> >cover object methods using the analogy:
> >
> >         operators: primitives
> >         methods : objects
>
> Of course, it would be a lot easier to teach the language if we
> didn't have to worry about these two worlds at all -- if the syntax
> for "doing something to something" were the same regardless of the
> thing's data type.  For example, if the Integer class had predefined
> methods plus(Integer), minus(Integer), times(Integer),
> quotient(Integer), and remainder(Integer), we would scarcely have to
> use primitives at all... but the syntax to get anything done would be
> long and tedious.
>
> Gee... if only there were a language in which all functions
> (built-into-the-language, library, and user-defined) on all data
> types (primitive, library, and user-defined) used the same simple,
> brief, consistent syntax, in which order of operations was obvious
> rather than needing to be memorized.... :-)


What's more simple (to a 1st-year student):

      a  = b + c
or
      a.set( plus(b, c) )

On a different note, try writing your own Integer class with as few
primatives as possible (none, if possible...)



> >I also deeply believe that an introductory course must relect the history
> >and evolution (for good or bad) of the material it covers. The idea of
> OOP
> >evolved out of the need to encapsualize data and procedures. The only way
> to
> >fully appreciate that is to understand *data and procedures *(procedural
> >programming).
> >
> >Modern liturature can't be fully appreciated without understanding
> >"classical" liturature. The same can be said with art, physics, music,
> >history, math and any other subject. Programming should be taught with
> it's
> >history, good or bad, in mind.
>
> OTOH, I wonder (along with Michael E. Caspersen):
>
> How far back do you want to go with this "historical" approach?  It
> sounds like TJ (like one of my colleagues here at Adelphi) would like
> to start with procedural programming and data type definition a la
> Pascal c. 1975.  Or maybe we should start with programming a la
> Fortran c. 1965, in which "excessive" use of procedures (not to
> mention recursion!) was considered Bad Programming Practice.  Or
> should we start with assembly-language programming, c. 1955?  Or
> perhaps with decimal hardware, c. 1945?  Or lambda-calculus and/or
> Turing machines, c. 1935?
>
> To continue the analogy from literature, art, physics, music, etc, we
> don't teach kids to read by giving them Shakespeare, much less
> Chaucer or _Beowulf_.  Sure, they should see the historical stuff
> eventually to appreciate how it all fits together, but it's not
> obvious to me that "historical-first" makes any more sense than
> "objects-first".



 Of course we could go on and on about this. Some languages are more
"verbose", some more "terse". I was just reading about how Conway's "Game of
Life" program can be written with *one* line in APL. That's a little to
"laconic" for me. SmallTalk goes to the other extreme.

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

 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: algebraic statments,
Boolean algebra, control structures - procedural programming!

I would argue, therefore, given a choice (with student who have *never*
programmed) we should *lean* towards the "procedural" rather than objects.
Speaking of 1965-1975, by the way, the "objects-first" movement reminds a
little too much of "New Math" - a great way to teach when you already
understand the subject...

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.



>
> >PS - This is why I think it would be nice to have "Compile and execute
> main
> >class" feature in BlueJ
>
> This would make it easier, and therefore encourage people, to teach
> and program in the style of 1965-1975.  I'm not convinced that that's
> a good thing.  To me, one of the best features of BlueJ (even better
> than the class diagram or the object bench) is the ability to call
> ANY function on ANY inputs at ANY time and see the results, without
> having to mess with I/O.  I/O programming (even with 1.5 or 1.6) is a
> pain in Java, it's something of a pain in MOST languages, and it's an
> area where languages differ the most, so it's almost completely
> non-transferrable knowledge.  If "compile and execute main class"
> encourages people to teach I/O and assignment statements on the first
> day of class, I vote against it.
>
Don't get me wrong - I love BlueJ's independent method call (great feature!)
I would argue its best feature is its direct manipulation of objects (with a
close second to Greenfoot and it's cool extensions...)

As for a "main execute" feature, why not give teachers the option? A good
teaching tool can suggest a certain pedagogy, but shouldn't *force* it. Why
not make it easier for some to teach according to their own style?

PS - With the Scanner class, I/O is actually pretty simple. It's
*object-oriented* - what could be simpler?  ; )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bluej.org/pipermail/bluej-discuss/attachments/20071128/090e4d31/attachment.html