Both) In order to be productive writing software:

• you need to know what to produce
• you need an environment to help you produce
• you need a way of monitoring that way you're producing is a
• correct implementation of the requirement

In a genuinely productive environment, these three are balanced: all contribute to the success of your project. And ultimately, all three come down to different forms of communication. That's what makes programming so interesting.

Programming languages are not a panacea in any of these areas. No current programming language will let you get inside your user's head, for example. However, programming languages do have a role to play.

When initially digging for requirements, you _think_ you understand what the user said, but how do you know? Large documents and acres of UML diagrams won't help, because the user won't or can't read them. The best check is to show them your understanding by producing some kind of prototype or tracer-buller implementation, or by using short iterations that deliver value early. Let the users get their hands on a real system. Not only will it verify your understanding: typically it will help them clarify theirs too. To do this, you need environments and languages that let you get applications out quickly: there's no point producing a prototype if it takes as long as the full-blown application would take to write. You also need languages and environments which allow you to rock-and-roll once the code is produced: the user says "what if...?" and you just make the change. Languages such as C++ and Java are poor at this: there's just too much ceremony involved in doing even simple things. Dynamic languages have the flexibility you need.

When you're producing code, the focus shifts subtly. Yes, you're still aiming to deliver value for your users each day, but minute by minute the emphasis is on the lower-level functionality. Here, as programmers, we'r looking for languages which allow us to express ourselves cleanly and transparently. The smaller the gap between thought and keyboard, the more efficient the communication. There are two issues here. First is the level of the language. In general, the higher level the language, the smaller the effort required to translate thoughts into code. However--and it's a big however--higher level languages also tend to get in the way, imposing their designer's ideas of "the right way to do things" onto everything you code. This impedance mismatch then makes coding more difficult. Java is a good example of a language that gets this wrong. Although it's reasonably high level, just about everything you want to do in Java, from creating closures for callbacks to iterating over collections, involves just that little bit too much extra work: your flow is broken as you type all the extra cruft that Java and its libraries impose. In many ways this is why good-old C is still popular: once you've mastered the idioms, it gets out of your way and lets you code.

Finally there's the issue of verification: have you written the correct code? Languages help (or hinder) here in a number of ways. At a low level, there's compile-time and run-time support for common errors. The static-typing advocates claim this is a major benefit o their environments. We'll discuss this in a moment. Once the code is written, it must be tested. How does the language help you here? Before writing a line of actual JUnit test code, you have to create perhaps 40-50 lines of support code. In Ruby, the equivalent is "require 'rubyunit'". Perhaps that's why a higher percentage of Ruby developers actually write tests. Finally, most studies show that code inspection is the most effective way to spot bugs and design flaws. So, how easy it it for people to read what you've written? Does the language make it easy to see the intent behind your code, or does the reader see nothing but the scaffolding?

We both feel that this question is not really answerable as it stands. However...

(Dave) I don't have a single favorite language. For lower-level grunge work, there's nothing to beat C (certainly not C++). I've always liked the declarative 'pic' language in DWB: there's a certain thrill drawing a complex diagram without using a single coordinate in the specification. (And for this kind of constraint-based programming, I also have a soft spot in my heart for a numerical-control language called APT: it somehow makes programming real when the equations in your code are translated into the movements of a spinning cutting head.) However, for general purpose programming, I currently reach first for Ruby. It lets me be productive and expressive, and it doesn't get in my way. After two pretty solid years of Ruby, I also still find it fun to use.

(Andy) Favorite for what? The biggest danger inherent in having a favorite programming language, or a favorite methodology, or any other favorite hammer is that everything starts to look like a nail; you apply your favorite thing whether or not the situation dictates it. I use a variety of programming languages, and in a way, they all come up short. For systems-level programming, or any task where speed and size are critical, C is the best choice, but C can be cryptic and chasing down memory problems can chew up a lot of time. For clarity of expression, Eiffel might be the choice, but it can't match the flexibility of Ruby.

(Dave) Andy's right here about the dangers of choosing a single favorite _anything_. I guess that's why we both tended to rebel against this particular question. I think we both have affection for certain languages, but when it comes down to it, languages are tools: choose the right one for the job at hand.

(Both) Transparency, transparency, transparency. By transparent we mean languages, libraries, and operating systems that don't get in your way, or force you to do someone else's job. C++ is probably the worst offender in this camp, but Java has many shortcomings here as well. For instance, as a programmer, we want to deal with integers as Objects. Always. We don't care if the compiler handles them differently from other objects internally; *we* shouldn't have to. After 40 years of programming language development, we should be moving away from these low level implementation details, not coding around them.

In the old days, computer cycles were expensive and men were cheap; you and your punch cards weren't allowed more than one compile a day, and every instruction the computer executed cost dearly. So it made economic sense for you to do some extra work. Times have clearly changed, people are now far more expensive and precious a resource than the disposable clone boxes we can buy at the mall. Yet the attitude prevelant in many languages still harkens back to the dawn of the age, forcing us to bear in mind thousands of details of implementation minutiae when all we really want to do is solve the customer's problem.

(Both) There are two. The first is haste. Programmers are often placed under tremendous time pressure; some of it from our management and clients, but much of it we place on ourselves. This mis-placed bravado leads us rapidly astray: there's no time to do it right, but maybe there will be time to do it later. There is no later. We tend to quickly abandon good programming practices and discipline in the face of crushing deadlines. The result? More bugs and problems that must be fixed in even less time, feeding the vicious cycle. No programming language or technology will help until we collectively learn to stop and "THINK!".

The second problem is that we often think we know the proper solution without ever verifying our knowledge. We think we've written correct code, but don't bother to unit test it to confirm our assumptions. We constantly re-invent the wheel, disregarding years of research and useful techniques that others in the industry have discovered. As an industry, we remain pretty much oblivious to current research as well.

Clearly, these trends need to be reversed if we are to ever progress as a profession. We advocate a style of software development we call Pragmatic Programming, which calls on programmers to resist the false economy of thoughtless haste and to utilize feedback to confirm assumptions in all areas, from writing code to dealing with customers and end-users. We need to repair the knowledge-exchange chain that spans from academia to industry, and back again from coders to researchers to vendors, so that we can stop repeating past mistakes and get out of the rut of 30-year-old languages and techniques.

(Both) We've been advocating generative programming (without actually calling it generative programming) for many years. The idea of moving towards a more declarative style of writing, with the code itself taking on the menial behind-the-scenes work of realizing your objectives just seems like common sense.

(Dave) At the same time I worry about some of the complexities introduced by using the techniques in languages with fundamentally lack the proper support. C++ templates are a hack, and using them as complex code generators cannot be good news for the future generations of coders who'll have to maintain the system. If generative programming is good (and it is), then let's start asking developers why they aren't using languages that support it in an integrated way.

(Andy) I agree with Dave, the industry must learn to move beyond this idea of layering ugly hack upon ugly hack, and be willing to embrace truly original paradigms from the ground up. Why *not* have an operating system with a true object-oriented system call interface? Why stick with GUI systems that would be perfectly at home on an Apple Lisa? Why do we continue to model the most complex systems ever envisaged using black and white, two-dimensional boxes and stick figures? It's time to move on, and to truly lead the revolution that is upon us.