From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,808505c9db7d5613 X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: Testing teaching belief? Date: 1996/11/22 Message-ID: <5735c9$7f3$1@goanna.cs.rmit.edu.au> X-Deja-AN: 198055788 references: <32723F6A.54A3@dtek.chalmers.se> <56b275$6k4@felix.seas.gwu.edu> <56paj4$bu0$1@goanna.cs.rmit.edu.au> <56rbmm$kc8@felix.seas.gwu.edu> <56thaj$3v$1@goanna.cs.rmit.edu.au> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-11-22T00:00:00+00:00 List-Id: 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.