The paradox of programmers' tools is aptly captured by a passage from Neal Stephenson's 1992 novel, Snow Crash, in a scene where a hacker is stranded on a life raft in the middle of the Pacific Ocean -- and thanks to the miracle of laptop computing, is hacking nonetheless.

"When hackers are hacking, they don't mess around with the superficial world of Metaverses and avatars. They descend below this surface layer and into the netherworld of code and tangled nam-shubs that supports it, where everything that you see in the Metaverse, no matter how beautiful and lifelike and three-dimensional, reduces to a simple text file."

I've seen any number of attempts to give programmers something "more," something "better," than an ordinary text file to represent their code and to serve as the environment in which they write it and rewrite it. I've seen, and liked, tools such as Source Dynamics' Source Insight, with its many fully integrated analysis tools and its effective use of font and size and other text attributes to communicate the structure and function of pieces of code.

Even so, there's only one programming tool in which I've found it worth my time to invest at least a dozen hours -- perhaps twice that -- in extensive customization of almost every keystroke other than those that merely enter text. I've done that only for Mansfield Software Group's KEDIT, itself a visible descendant of the 1980s IBM mainframe editor XEDIT. KEDIT is still maintained, despite the 5-year-old date that I found on Mansfield's home page this morning, and my keystroke customization code for that editor meets a vital test: I never look at it, or think about how hard it was to make it work exactly the way I wanted. It just does.

And if I'm not running KEDIT, I'm probably running SlickEdit, which I like for its breadth of platform support -- the main reason that it's on the eWEEK Labs list of Must-Have Tools.

Do you find, as I do, that when you're really cranking away on your code, a screen of monospaced font is actually an important aid to seeing the regularities in what you're writing? Yes, I know, there's a school of thought that says there shouldn't be regularities: that if there are big sections of code with a repetitive structure that you can see, you ought to be abstracting what's common into a single entity that operates with appropriate variations on each of the leaves of its tree.

To the extent that programming languages differ in anything more important than punctuation, I agree that their varying capability of abstraction is one of the real distinctions among them: "If you try to solve a hard problem," wrote Paul Graham,

"... the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one."

If you take this line of argument to its logical conclusion, the notion of "design patterns" becomes more a symptom than a strategy. A sufficiently powerful language, some would argue, either makes popular "patterns" far simpler or assimilates them entirely.

One way or another, though, there's no question that programmers demand direct access to the actual code that they're compiling -- or even to the output of the compiler itself, which is one reason why I like and actually use the option of compiling code to assembly-language source with the source lines embedded as comments. Sometimes, I really want to know exactly what the machine is being told to do.

Telelogic makes tools that offer high-level views of complex applications, and especially of enormous embedded-software systems: The company's toolmakers therefore have particular reason to understand and struggle with the dual demands of giving development managers the big picture and also indulging programmers' insistence on access to the lowest level of detail. The company addressed this duality with this morning's announcement of Version 7.0 of Rhapsody, its model-driven development environment with substantial new aids to model generation from code and to preservation of source code details during multiple model generation cycles.

The latter design goal, code-named "Code Respect," is an important part of making programmers completely comfortable with round-trip environments that let the coder use the most convenient tool at any time -- rather than locking in a particular sequence through a multitool chain.

Also new on the scene is the latest release of SlickEdit Tools for Microsoft Visual Studio 2005, which integrates some of the cleverest coding aids of SlickEdit into Microsoft's widely used -- not quite the same thing as "popular" -- workbench. At over $100, SlickEdit Tools is not an impulse purchase, but a free evaluation download will give you a chance to decide if its ingenious and productive improvements (I especially like the Regular Expression evaluator) are worth the price.

Tell me what tool you wish you could find at any price at peter_coffee@ziffdavis.com.

This article was originally published on eWEEK.com.