[Edu-sig] CTL: Computer Thinking Language
macquigg at ece.arizona.edu
Mon Mar 2 18:18:48 CET 2009
At 07:59 AM 3/2/2009 +0100, Laura Creighton wrote:
>I think the whole idea of 'not a programming language' is flawed. If
>you want to teach concepts in this fashion --- and I think this is a
>great idea -- you want to teach 'how to use an interpreter' (you
>are using an interpreted language) and some sort of Test Driven
>Design (which you do not have to teach explicitly) if you have something
>like py.test or nose available.
Or something like Python's doctests. These could be presented to students without all the overhead of a complete Python program, by embedding them in an application or website, like our soon-to-be-announced http://py-bat.appspot.com.
>Otherwise what you have given yourself is a lot of marking to do, and
>you are stuck with the same problem that troubles math teachers --
>(unless they are teaching from Kirby's Pythonic Math exercises, or
>something.) You give your kids an assignment, and they don't
>understand it, and get it wrong. You reteach the principles, and
>try again. The nice thing about proramming is that it doesn't have
>to be taught this way.
>"Here is an acceptance suite. Bash on your program until it passes."
>is a perfectly acceptable way to go. And this changes your class from
>math class (where there are correct answers and wrong answers, and
>hated by those who seem always to get the wrong answers) to programming --
>where all running programs are in some sense 'correct' -- they just need
>to be completed, or to have some bugs removed before they correctly
>solve the assignment. :) This notion is incredibly liberating to some
We can even turn this around. "Here is a function with an error. Write a test that will catch the error." This will focus the student's attention on learning the critical CT skill of being able to define a problem in precise terms, even before you have the solution.
>I get the distinct idea that the authors of this paper are functional
>language fans, and what they are looking for is a way to get to
>Haskell or ML or something like that. This is 'programming as
>mathematical proof'. But I don't think that programming is actually
>like that. I think that the idea that a person needs to invest 10,000
>hours in an activity to become very good at it (which seems to work
>for learning a sport, or learning how to play a musical instrument)
>seems to work for programming as well. I won't argue for the
>10,000 -- but just that if you want to get better at programming,
>then what you need to do is practice doing it more. Filling yourself
>with more advanced concepts will not, unfortunately for those of us
>who are good at filling ourselves up with concepts, change the fact
>that you need to practice writing programs to improve at writing
I think there are two ways of learning - language style, and logical style. Language style ignores all the inconsistencies and ambiguities in the teacher's presentation, and just absorbs the subject like a sponge. "Osmosis" is another term I have heard applied to this style. Logical style fits each new piece of knowledge into an existing framework, locking in pieces which fit, and rejecting everything else. I'm more of a logical learner, and I have difficulty with human languages, overly-complex programs where every menu follows a different logic, and computer languages that have a lot of "cruft" that you just have to memorize. Still, when I learn something new in Python, I go first to the examples, then study the syntax.
Lambda functions are a good example. These were presented to me as something wonderful, something to do with lambda calculus. I didn't get it. Later, I saw some examples, and understood they were nothing but a syntactic trick to define a function when you don't want to give the function a name. If you are going to present lambda functions to students, show some useful examples first, then talk about lambda calculus, if you really must.
By the way, naming a function, as opposed to just using it as a piece of an expression, is a concept worthy of special syntax in CTL. How about:
. f(a,b): (a+b)/2 # lambda style (do it now)
. f(a,b) = (a+b)/2 # save it for later use as a function named "f"
Of course, this raises the question, do we really need lambda functions at all? I never use them.
>I think this analysis misses this point, and then tries to get around
>it by saying -- well, we don't actually care if the students learn to
>program, only that they learn the concepts behind programming. But
>I think this is exactly backwards -- the way you should be teaching
>the concepts behind programming is with an interpreter. Thus you
>need to teach them a tiny bit of programming _first_ and not second.
>And more and more I think that Kirby is correct. You should teach
>math with an interpreter, too.
>On a related note -- a friend of mine has given his 6 year old son
>a linux system on a laptop to play with. It is a hit. But now the son
>wants a book that explains how the linux operating system works. :)
>Anybody have a reference that is suitable for children?
When my daughter was seven, she started playing with the Unix system in our lab, and by herself discovered how to write messages and print them. I was even more impressed when she asked if there wasn't some way to send the message to another computer. Mind like a sponge!!
I totally agree that kids can use an interpreter before they even know how to add a column of numbers. Not to say we shouldn't teach addition first. I wouldn't want to see kids ignore math lessons because they don't see the usefulness of doing something a computer can do for them.
* David MacQuigg, PhD email: macquigg at ece.arizona.edu * *
* Research Associate phone: USA 520-721-4583 * * *
* ECE Department, University of Arizona * * *
* 9320 East Mikelyn Lane * * *
* http://purl.net/macquigg Tucson, Arizona 85710 *
More information about the Edu-sig