Pedagogical style [was Re: The "loop and a half"]
On Thu, 5 Oct 2017 07:29 am, Christian Gollwitzer wrote:
> To understand Stefan's way of teaching, take a look at his other
> courses, for example the C++ course:
Thanks for this Christian. It has been an eye-opener. More comments below.
> He defends the opinion that you learn a programming language best by
> studying syntax diagrams. He even writes in his FAQ about the language
> "Neuere Forschungen haben gezeigt, da? es erfolgreicher ist, formale
> Systeme (wie Programmiersprachen oder Mathematik) zu unterrichten, wenn
> dabei kein k?nstlicher ?Praxisbezug? durch ?real-world examples?
> (Beispiele aus dem ?wahren Leben?) hergestellt wird!"
> which means
> "Recent research results show that it is more successful, to teach
> formal systems (like programming language or maths), if no artificial
> practical use-case is demonstrated by "real-world examples" with a
> reference: "They said students who were taught abstract math concepts
> fared better in experiments than those taught with real-world examples,
> such as story problems.
> Adding extraneous details makes it hard for students to extract the
> basic mathematical concepts and apply them to new problems, they said.
> "We're really making it difficult for students because we are
> distracting them from the underlying math," said Jennifer Kaminski, a
> research scientist at Ohio State University, whose study appears in the
> journal Science.Reuters, 25. April 2008"
There's no link to the original paper, only to secondary sources that discuss
so I cannot really judge the quality of the paper. It might be good, it might
be full of holes, there's no way to tell.
But even if it appears really good, until it is replicated, a single paper --
especially one which claims to overturn decades of teaching experience and
convention -- should not be treated as anything more than *possibly*
suggestive. It certainly should not be treated as a proven fact.
Unfortunately, most scientific papers are wrong:
The above is written from the perspective of a medical researcher, but the
general conclusion holds across all the sciences, even more so for soft
sciences like educational studies. Until the Kaminski study is replicated,
our default assumption should be that it is "wrong", or at least that it
doesn't generalise beyond the narrow examples tested in the study.
The most obvious potential/hypothetical objection is, this study seems to go
against the phenomenon that most people do poorly at abstract reasoning, the
more abstract, the less well they do, but pose the same problem in concrete
terms and they do much better. This study implies the opposite should be
the case, and I find that implausible.
In my own experience in teaching maths, I can see some of the issues the
Kaminski study discusses: e.g. the majority of my students find it difficult
to generalise from one or three examples to a general principle, or to apply
a principle from one area to another.
(E.g. students who have successfully mastered Pythagoras' Theorem in the
context of geometry, will nevertheless often fail to apply it in the context
of trigonometry problems.)
I would never expect the majority of my students to generalise from a handful
of concrete examples to a general principle, but my experience strongly
suggests that concrete examples can and do aid in understanding general
The fact that this study found the opposite, that concrete examples
*suppressed* understanding, is so counter to my experience (including my own
learning style) that I feel very skeptical about its results.
Nevertheless, the study is interesting and necessary.
Even if the study turns out to be correct, or mostly correct, or even partly
correct, there is still a big gulf between what the study shows and Stefan's
(1) Programming in Python is NOT a formal system. Most programming isn't, and
Python *in particular* is further away from the mathematical purity of (say)
Haskell. There is a reason why we talk about "software engineering" and
why "computer science" is so little like a science.
(2) Kaminski's conclusion is:
"We really need to strip these concepts down to very symbolic
representations such as variables and numbers," she said. "Then
students are better prepared to apply those concepts in a
variety of situations."
But she is talking specifically about symbolic maths here, not programming.
There's no reason to think that even if she is right about maths, that the
same will apply to teaching programming skills. Different skill sets require
different approaches to teaching.
(3) Stefan's so-called "bottom up" approach is only bottom up from a
particular perspective. Another perspective is that he is unnecessarily
giving *implementation details* which are mostly irrelevant to the
*interface* presented by the language.
E.g. Python could introduce a completely new iteration protocol, and iterating
over a string or list would remain 100% backwards compatible, while Stefan's
preferred while-loop example would no longer be an accurate description of
the "bottom up" approach.
This is not a far-fetched example. Python has already changed its iteration
protocol once before, and it could do so again, without changing the language
(4) Stefan's own example of how to walk a string character-by-character is
complicated, and even worse, it teaches poor programming style for Python:
# Stefan's approach
walker = iter( 'abc' )
print( next( walker ))
That's six lines of code, involving five built-ins, four keywords, and at
least six extraneous concepts unconnected to the immediate problem:
* assignment/name binding;
* iterator protocol;
* try...except (exception handling);
* while loops;
* the syntactic necessity for pass ("do nothing").
And the result is poor-quality Python code. Such code would never pass code
review among even moderately experienced Python coders, let alone experts. By
teaching this first, Stefan's students have to literally unlearn what he
teaches them, in order to learn the right way of walking a string:
for char in 'abc':
That's two lines, one built-in, and two keywords, and it's practically
self-documenting. More importantly, it is the much better code. Even after a
lifetime of experience with Python, you won't find a better way to walk a
string printing it character by character than those two lines.
In fairness to Stefan, we should also include iteration and assignment as
concepts being learned, but in this case they are directly connected to the
immediate problem rather than at best only indirectly, and distantly,
So the bottom line is:
- Stefan's approach requires the student to learn fifteen concepts
to get poor-quality Python code;
- the idiomatic approach requires the student to learn five concepts
to get high-quality Python code (for this toy problem).
I think Stefan would probably love the approach taken by Zed Shaw's "Learn
Python The Hard Way" book. I think it is horribly overrated: my experience is
that beginners trying to learn from that book struggle terribly and
eventually give up.
I think that praise for the Hard Way is a classic example of Survivorship
Bias: we only see the praise from those who succeeded in learning Python
despite the book's pedagogical style, not because of it. Those who were
discouraged and dropped out and gave up on Python or programming altogether
remain invisible and unseen.
I expect that Stefan's approach suffers from the same problem.
 Anecdotes are not data, but for what it is worth, just in the last two
days I came across two examples of this. Teaching a boy in Year 10 maths
about logarithms, he struggled with purely algebraic questions involving
solving exponential equations by using logs, but when given a concrete
problem involving an investment he was able to solve it immediately.
The second example involved a girl in Year 8 maths, who again struggled with
abstract questions about adding and multiplying fractions. In particular, she
overgeneralised from fraction multiplication to addition, thinking that 1/4 +
1/4 must add to 2/8. But when put into concrete geometric terms, showing
physical shapes divided into quarters, she could instantly tell that 1/4 plus
1/4 must be 1/2.
As I said, anecdotes are not data, but when research claims to show that
apples fall upwards in contradiction to anecdotal evidence that they fall
downwards, we would be wise to be cautious before accepting the research as
?Cheer up,? they said, ?things could be worse.? So I cheered up, and sure
enough, things got worse.