Like a lot of people my age, I learned to program in BASIC. It was a mostly self-directed activity. There were people who showed me the basics of the language, but after a certain point I learned a lot from a reference manual and other people's programs. (Back in those days it was possible to go to the local library and check out books filled with BASIC source for various programs, mostly games.) I learned because it was fun. Part of the reason it was fun was the sense of accomplishment in making the machine do something useful. The other part was that it felt like I could accomplish most of the things that I had seen the machine do. The Apple II was not an especially complicated machine. Simple graphics, sound, and disk I/O are all firmly within the grasp of the beginning programmer.
I think the urge to do what you've seen the machine already do is found in most beginning programmers. Very few programmers learn how to program without already knowing what their computer can do. So it's only natural to expect to be able to create GUIs, use the network, and create flashy 3D games when you first learn how to program today, despite the fact that most working programmers don't use most of that, most of the time. (No, I'm not going to quantify that.)
If you're going to teach programming on modern computers, there are two options: you can give in, and integrate this into the curriculum, or you can hold out, and attempt to teach good thinking discipline before teaching shader models and light maps. Neither method is all that great.
If I had to teach programming today, I'd be sorely tempted to start with one of TI's or HP's high-end calculators. These machines resemble the machines that I learned programming on quite a bit more than modern computers do, and they share the same essential characteristics. It's easy to create useful programs, and the full range of the machine's capabilities are easy to harness. They also teach the fundamentals of programming in a modern environment because they are based on dynamically typed languages with garbage collection.
Of course, neither machine is based on Scheme or Lisp. I have no problem with teaching these languages, because it's not the language which I am concerned about. It's the context in which that language is learned. Even Squeak which to some degree establishes its own context, at least visually, tries far too hard to show off its abilities to produce GUIs, web programs, and 3D graphics.
I think many of the issues involved in teaching programming are conflated with the issues of teaching introductory computer science. I learned to program long before I learned anything of computer science. Of course what I learned in my undergraduate studies helped to mature my abilities, but it was not essential to the task of learning how to make the machine do something useful and debug it when it doesn't do what I want. Learning to program was about exploring systems of knowledge. I still remember when the thought of installing Linux brought a sense of glee, just because it was large and complicated and was not something which I already knew. There is very little in the academic context which could have evoked that same feeling.
Learning how to program is tied to an individual's mode of learning and problem solving far more than the academic context allows for. I think that one day universities will realize that solid programming skills in at least one language should be a prerequisite for a Computer Science curriculum, just as music majors are expected to already play one instrument. In fact there's much that we could learn from the field of music education - perhaps the best way to teach programming is one-on-one with someone who can adapt his teaching style to the individual's learning style. I wonder if practicing programmers will start to give programming lessons on the side to pass along their love of the discipline. It might do a lot of good for education in general.
Briefly: when I wrote about XML mixed mode I was under the delusion that I had somehow worked around CALL-ARGUMENTS-LIMIT by making the XML tag in (<tag> body1 body2 body3) a macro which was bound by a lexically-surrounding WITH-XML form. I hadn't; those element body arguments still ended up as arguments to LIST. The WITH-XML macro is really unnecessary, and now <tag/> reads as a form which returns an object, while <tag> reads as a LAMBDA form which can be used at the head of a list or evaluated to return a function. That function, when called, returns an object which represents the tag wrapped around the arguments as a body list.
I also have an implementation of XML to XML transformations based on pattern matching, using XML mixed mode for the lexical syntax of patterns. This is intended to replace the hacky templating system I wrote for cl-blog, which was so poorly designed that it was incredibly difficult to express conditional or iterated expansion. The new system is much nicer, and allows templates to be created by people who do not know the template system.
I recently started working on a generic system for intentional types in Common Lisp. Since I am working on a library for web programming, this should have been a no-brainer, as the task which I have spent the most time solving is perfect for such a system. I already have a good abstraction set up for producing and processing forms, but the processing of values from strings and conversion of strings to values was always a little bit hacky.
Of course, CLIM also offers an intentional type system for presenting and accepting values, but the mechanics are tied into CLIM. I think it would be useful to have a generic system for defining and representing intentional types, as well as defining operations using those intentional types. I may even provide an equality operator.