For me it is having someone to work with who shares the goals and objectives. I quickly bog down without someone to talk to. In part this is because I learn what I think by talking about things, but also I find that having partners gives me energy and ideas when I need them.

Smalltalk. The simplicity of the language, the development environment, the fact that it's Smalltalk all the way down, and my familiarity with the language all contribute. The only language I know that is like that is Lisp, and since I didn't fall in with evil Lisp companions, I don't know it as well as I do Smalltalk.

In Smalltalk, the environment helps me learn about the code I'm using, helps me see the code I'm writing. I'm always asking questions about the code: how is this used, who is using this, how does this thing I'm using really work, what else can this object do. More conventional languages make it much harder to get those answers.

I've been working with Ruby lately and like it very much. If it had more of the capabilities of Smalltalk in browsing, it would be much better. And of course Ruby is implemented in C, which means that just when you want to know how something works, you may have to jump out of Ruby. When you want to extend how something works, on the other hand, you can usually do it. It's a very nice language, just not as nice as Smalltalk.

Honestly I don't see one. I hope that the agile methods like XP will help teams to be more productive, and I hope that the world will learn that dynamically typed languages like Ruby and Smalltalk are more productive than those with static typing.

The thing that holds us back more than anything is probably complexity: the complexity of the problems we attack is always getting higher and the things we have to know to go after them grow in number and complexity.

Somewhere inside most complex problems is a simple problem, and the right simple starting solutions can make all the difference. But we seem to me to be a long way from embracing that truth.

I hope there is a productivity jump coming and that I'm just too old and stupid to foresee it. Until then, I'm counting on small groups of smart people to keep things going.

Complexity. As young programmers, we thrill at our ability to handle complexity and often we come to believe that this is our power. In fact a greater power is that of simplicity, but it seems to be few of us who ever recognize this and develop the skill to make complex things simple.

But complexity comes not just from inside programmers. Our society seems to choose complex solutions where simple ones would do. We seem to favor big organizations over small ones. We seem to favor complex methods over simple ones. We seem to favor strong control over emergent structure.

This makes me want to go back to the previous question but in fact I'll make this comment here. One possible productivity jump might be the use of small systems with emergent behavior. For example, air traffic control, as done today with centralized control, is difficult and in many airspaces, up against its limits. If instead we had smart airplanes that knew where the other nearby planes were, and that had a common set of simple rules by which they flew, the problem might be more tractable.

This kind of thing will come: the Internet is creating some of this sort of thing, with Gnutella as compared to Napster for example. We're starting to see smart vehicles that know what's going on around them. We're even seeing kids' toys that know when another nearby child has a similar toy, and the toys act to bring the kids together.

Maybe small processes and small processors cooperating will be a breakthrough. In some areas, certainly they will be.

At one level, it is something that any competent programmer uses. A typical feature for any application will have a number of things in common with the next feature: perhaps each feature needs a record definition, a general ledger account number, an icon, a menu name, a way to erase itself. Today's languages can make it difficult to keep all these things together, and in so doing they make refactoring difficult. So competent programmers often write tools to generate the code from some compact description of the feature.

These tools are very powerful but often very ad hoc. They never cover everything, and are often used only once, to build the initial version of the code.

I expect we'll have to learn again that generation can rarely handle everything, but that more powerful tools, kind of "round trip generative programming" will come along and help us get things done. So far, I'm not aware of anything out there that will solve my problems better than Smalltalk or Ruby, but within those, I use generative techniques fairly often. And, of course, there might be something good out there that I'm not aware of. Is there?