Lambda the Ultimate

Visual environments like Maple and Mathematica are very easy to grade students on their understanding; I have the experience of 3 years being a teacher's assistant in college. Most of my students were Child Study majors with a concentration in mathematics; they were not mechanical/electrical/software engineers or aspiring to be computer scientists, actuaries, etc. Yet, it was really easy to grade, and also teach them why I gave them the grade and explain what their weaknesses are. In essence, these visual environments had sufficient code review mechanisms.

Systems like Alice, on the other hand, seem impossible to measure quality of.

How does MIT propose Scratch be graded?

[Edit: The point being, students want to know WHY they scored so low. How do you do that with Alice? I've never been able to figure it out, but is Scratch any better? You can't simply give everyone high scores, because that makes students think the class is a joke and they instantly react to grade inflation promises in a way that conditions them not to learn. Just speaking from experience observing how other TA's ran their labs.]

If you agree with Dehnadi and Bornat (cf. LtU story, Testing first year programming students), then the magic key to programming is a mindset of interpreting computer code in a consistent and inflexible manner.

It seems to follow that the consequence of poor choice of initial language will not be to injure the students ability, though maybe there may be some injury to the language preferences in the child. Your anecdotal experience is, I think, open to rival interpretations.

I'd like Scratch to have some sort of abstraction facility, but the most important thing for me is the idea of being a fairly painless environment for exploring the idea of programmatically exerting some kind of rewarding control of a machine. Once the programs start to get bigger, then maybe it's best to peel back the covers and look at the Squeak underneath.

Well, I started programming (in a very unsophisticated way) at the age of 3 or so in BASIC. Moving to Pascal was quite painful at first, part of me didn't want to do it, I think the first failed attempts came around the age of 9-ish, but by the age of 12, I had made the transition and I saw that Pascal was a much superior language, which was a valuable lesson. And my interest in BASIC waned as my abilities with Pascal grew. Interestingly, I never understood why GOSUB was a good idea until after I started to get comfortable with Pascal.

But within a year or two of completing my transition, there were a number of things I disliked about Pascal. The thing that annoyed me most was the restrictions on the return type of a function, and I couldn't find a way of writing a library to work with rational numbers and matrices that satisfied me. Object Pascal appeased me for a few more years, for what I later understood to be the wrong reasons.

And then came C++, which precipitated a crisis in which I found it deeply unsatisfying to work in any language I currently knew. The subsequent search for a better language eventually lead me to ML and Haskell. These languages instantly "clicked" in the sense that I knew I liked them a lot, but of course actually learning to use them was quite a challenge. It took a good year and a half before I became approximately competent, and another year before I was comfortable enough to no longer need imperative programming.

So I guess my point is that BASIC does not necessarily lead to "bad outcomes", but my story is probably rather unusual. The real question is one of statistics: what choices lead to better outcomes on the whole?

It seems to follow that the consequence of poor choice of initial language will not be to injure the students ability, though maybe there may be some injury to the language preferences in the child. Your anecdotal experience is, I think, open to rival interpretations.

What rival interpretations? He is effectively saying that when students encounter an idea for the first time, they may struggle to learn it, especially if the idea is totally counter to the habits they've been encouraged to pursue.

Bertrand Meyer took this hypothesis to its fundamental limit, with good results in his classes. The end result is the book A Touch of Class.

Bertrand has been jetsetting ACM SIGCSE conferences the past few years with his approach. Yet it has received very little attention from rivals, from what I can see. e.g. DrScheme.

Learning environments are complex systems. A linear progression in one direction (pouring all emphasis into one technique for improving learning) will not yeild linear gains in improvement. The trick is to design things extraordinarily well. I can't find the paper at the moment, but Boustedt et al did a study that shows there are certain core concepts in calculus that once students truly show understanding of, their understanding and grasp of future material is irreversibly changed and made easier. I believe the example they gave was use of limits.

Also, Nicole Mcneil, a psychologist at Notre Dame, has done various studies on how children interpret symbols based on how the meaning of the symbol is first presented (eg. the problem context). Fascinating stuff that shows how much teachers can take for granted. What it revealed is that if you gave children problems like 3 + _ = 4, students would often answer 7, because they interpreted '=' as 'add up all the numbers' aka 'calculate the total'. I've seen similar problems in college calculus courses. For example, once a student learned u-substitution, it became a deathgrip, such that they found integration by parts difficult. This is very unfortunate. (Obviously, you do not need to teach integration techniques in that order.) This basically boils down to being good at manipulating symbols and forming abstractions.

I think the risk to students is that, having learnt a way to solve a problem in a particular way, they will be slow to see the advantages of learning another, but when provided adequate motivation to learn, they will learn all the better for it. The alternate seems to suppose that the mind is somehow polluted by conceiving of ugly code, and does not naturally rid itself of this toxicity. I'm guessing the failure to be convincing when presenting the problems of unstructured programming is more likely to be at fault.

If you want to teach the dangers of unstructured programming, I'd guess that a code maintenance problem would be a good start.

I think you are conflating bad habits with new ideas.

The idea that code can be made maintainable through analysis is a "new idea" in the ocntext of spaghetti programming. In the software industry, this "new idea" was not even discussed much until the '70s. And the idea of updating analysis -- refactoring -- was not discussed much until the late '90s.

In spaghetti programming, the "new idea" is being able to program a machine to do things like add numbers faster than humans, and know exactly how the machine does this. Structured does not matter.

It is possible for a "new idea" to be presented in such a way as to form a "bad habit", which is what you want to say: For 3 + _ = 4, the answer apparently is _ = 7, because the "new idea" of algebraic manipulation of an equation mixed with constants and variables was simply presented too naively.

Honestly, it is pretty hard to get statistics on how badly brains are damaged. Only one state in the US enforces standardized textbooks for K-12, and that is Texas. So it is very hard to map out how well students are doing and how well teachers are picking out the right materials e.g. how well they are managing a classroom budget. I tried to get these numbers, but it was impossible, and my requests from publishers were never replied to. -- they wouldn't even tell me what their demographics were.

Don't underestimate the flexibility of the brain :) We can always adapt if we choose to adapt. Not adapting is not as big a problem as well. For example, it seems to be a fashion in the "new music interfaces" groups to consider the piano-ish keyboards to be "very bad" interfaces to making notes and melodies. There are some great pianists nevertheless. Likewise, great software is independent of the greatness of the language in which it is written.

But you do get message passing and concurrency. What I miss is recursion.