Teaching programming h;lp

I'm going to teach programming to somebody who's going to study it more formally in a year, but wants to be learning part of it in the mean time.

What SIMPLE, CLEAN, STRUCTURED language would you recommend me to use for teaching? Please, refrain from language wars as this is not a fanboy thread but a serious question. Before yuo mention it, I'm not going to start with either Python or Ruby because they're too complex and get too much in the way, and no, I'm not stupid enough to start with Java because a radical OO language (and a crappy one at that) with a shitty enterprise API is not the best either.

I'm thinking Pascal. As much as it sucks, it has strict/anal types (it's better to start anal than to start easy-going and botch it), simple yet not messy syntax, simple stdin/stdout input and output to play with (that's all I'll need), and none of the complexity of OO. Yet it sounds so useless. But I don't know of other languages that meet these requirements.

So I'm >>1. I like the discussion on C strings (BTW: C strings suck, sure they are simple, but they just can't do O(1) operations, come with an ugly standard library, and are ZERO TERMINATED, which means they are NOT BINARY SAFE), but that won't help my student.

I plan on teaching him C (or at least wait for it to get teached to him because it will), and of course he'll learn to deal with them, but right now I'm worried about teaching programming, not a particular language, so I want it simple and purist.

>>2
I'd bet I'm older than you, also working on real software and making more than you do.

>>7
Python is a great language (RUBY IS TOO, WEEABOOS, SO JUST SHUT UP), but perhaps some features of modern languages may bite to people who are learning programming and can't be bothered to deal with classes, exceptions, bound objects, iterators, range objects, etc. yet.

>>8
Real men master C strings, after which they realize how crappy they are and how a waste of time string handling in a low-level language is, so unless they need the best performance, and especially if they're getting paid, they move on to higher level languages equipped with PCRE.

>>9
Uh, no. C strings suck because they can't hold any character, have O(n) strlen and most operations, and come with a crappy standard library to handle them.

>>11
I've considered PHP. It's simple, and has a more common syntax than Pascal or Python. The problem is it's so loosely typed I think it might do bad. I want to differentiate data types before we can introduce variant types, automatic conversion, and why is "" == 0.

>>15
The same could have been done with length-based strings. Actually, I had a great idea, but never bothered to implement it: to have a struct like:

typedef struct {
int size; //Allocated size, increased or decreased logarithmically
int length; //Character size of the string; always <= (size >> 1) - 1
wchar_t chars[]; //Struct hack to hold characters
} string;

then move the pointer so that it actually points to character 0 in chars. This way you keep the array access to characters, but string functions (which should be the only ones to know about this structure) can access size and length, and deallocate/reallocate the block if necessary (base is the address of string.size). You get a O(1) macro for strlen. As an extra utility, the functions always guarantee that the string is terminated by a zero so that, when not using binary strings, read-only C string functions and functions which expect C strings will work.

>>19
Copying null-terminated strings was faster than Pascal-style on a PDP-11. And thanks to that, we're still stuck with it several decades later.
I still can't believe that. It doesn't make sense, unless perhaps if all your strings are "Hello world!" and shorter.