Re: Testing teaching belief?

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>With regard to Richard's experimental design, it is missing a HUGE element.
>Students learn from the teacher as well as the text book. There is no way
>that you can normalize the teaching effect in a case like this, without
>doing hundreds of parallel experiments.

What you are saying, in effect, is that we can *never* have
experimental evidence for *any* aspect of programming teaching.

I didn't mean to imply that it would be easy to do a *perfect*
experiment, only that it should be straightforward to do an
experiment from which something could be learned. 

Is it entirely impossible, for example, to find a teacher who is genuinely
open-minded about this issue?

And would a null result (which is what I actually expect) be uninformative?

>Even then, there is an asymmetric quality that may fundamentally bias
>your results. Those who think that it is important to emphasize keywords
>with upper case letters have a particular view of how to teach a language.
>I for example find that emphasizing keywords as important is totally
>unnecessary, I regard that as a minor syntactic detail, and my teaching
>of any programming language does not focus on the syntax.

>This means that the whole business of upper case keywords may reflect
>a fundamental difference in approach and style, and I don't see how to
>normalize that.

But the issue under question is not "whether to emphasise keywords or not"
but "whether to distinguish keywords by making them upper case or by
making them lower case".  It's precisely a teacher who *DOES* believe that
distinguishing keywords is important, but has an open mind about the best
way to do it, that we want.  I agree that "whether to emphasise keywords
or not" is an important question, but it is a *different* question from
the one I'm asking.  Let's spell it out:

	ASSUMING that it helps beginners to distinguish keywords
	H0: it makes little difference whether you consistently use
	    the LRM/AQ&S highlighting method (all and only keywords
	    are entirely lower case) or the UPPER highlighting
	    method (all and only keywords are entirely upper case;
	    I don't know what happens to acronyms).
	H1: using the LRM/AQ&S style improves concept learning
	H2: using the UPPER style improves concept learning.

(My prediction:  H0 cannot be rejected.)

I would expect people who don't think it important to highlight keywords
to have no trouble with adopting the LRM/AQ&S style.  All of the proponents
of upper case keywords for beginners we've heard from so far have said that
their reason for preferring a non-LRM/AQ&S style is in order to highlight
keywords (which the LRM/AQ&S style *does* make visibly distinct).

>The call for objective evaluation in teaching methodologies is of course
>a common one, but that does not make it easy to meet.

Well, enlarging the question beyond the original proposal can always make
it look well-nigh impossible.

>Rather than focus on such a small issue, why not address the more 
>interesting issue. How can you show that teaching Ada is or is not
>better than teaching C++ to first year students?

I was thinking of a very limited question, where the factors you've
mentioned might possibly be controllable.  Now *you* are asking an
extremely general question.  People who select C++ have a very different
idea of what programming is about than people who select Ada.

Believe it or not, as I've mentioned before, I am co-supervising (with Dr
Isaac Balbin as principal supervisor) a Masters student who is addressing
a closely related but different question:

	- how can we tell whether our choice of first year language
	  is producing the benefits we hoped for?

He has surveyed a _lot_ of CS education literature, and found a great deal
on the reasons people give for why they chose or are about to choose a
particular language, but almost nothing on whether it actually _worked_.

>Even if you tried to find two equally enthusiastic teachers, you would find
>that you were more likely to be measuring skill and enthusiasm of the
>teachers than inherent pedagogical value of the language vehicle.

This is actually something we are aware of, which is one reason I was asking
about a limited experiment where only the particular _means_ of achieving an
agreed end in a single language and teaching style was to be tested.

For what it's worth, we do not expect this student to produce the final
answers, only to produce a thesis surveying what the _questions_ are and
providing a basis for further study.

It's a bit like software engineering:  it's hard to improve the product
without also improving the process.  We want very much to improve our
product, so we are looking at all sorts of ways of improving our process.
With strong pressure from C++ (it's hard to fight the "it won't get me a
job" belief, whatever truth there is in it) and growing pressure from
Java (it's also hard to fight the "new and sexy" effect; COBOL succumbed
to "how can we hope to be taken seriously as a university if we teach
COBOL?") we really would like to have _grounds_ for persisting with Ada.


For what it's worth, my own prejudice is that a heavy stress on keywords
is a very bad thing for students, because the next language they meet
will use different keywords.  I well remember the confusion of Pascal-with-
emphasis-on-keywords students meeting C.  They didn't understand "bounded
loop", they understood 'for', and C's 'for' was different, and of course
the difference between Pascal's 'case' and C's 'case' didn't help any.

There is, for example, a certain amount of keyword/concept confusion in
Feldman & Koffman, where p33 says "In Ada a program is called a PROCEDURE".
This text consistently uses italics when it introduces new technical terms,
and there are capitals in that sentence, not italics.  (Of course, some Ada
programs are implemented as functions, using quite a different keyword, so
the concept is the important thing.)  p39 says "There are many different
Get statements in the input/output libraries", but what the libraries offer
is Get _procedures_.  That's a similar confusion, but I think it has the
same cause.

[When I commented on the US-centric bias of this book before, I hadn't read
chapter 2 in detail.  It's _very_ strong in chapter 2.]

This may look like an attack on Feldman's book.  I hasten to point out that
the reason I picked it for comment here is that I *have* it, and I needed a
*good* book to make my point.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.