DocJet is no longer a commercial product. It is now free to use, but unsupported.

As some of my loyal users will already have observed, Tall Tree Software has never consisted of anything more than myself, Steve Benz. I've written it, supported it, and marketed it (in my own limited fashion!) Now, I'm calling an end to it. DocJet had a great run! The first DocJet license was sold in 1996, and kept me in groceries for over 10 years. For the past several years, DocJet has not seen the kind of love it enjoyed earlier on. This is because of a trend I spotted several years ago:

Changes to computer languages and IDE's will soon make DocJet and tools like it obsolete.

That might seem distant, since DocJet et. al. are still the only game in town, but take a look at the changes that have gone on outside of the comment space. Visual Studio catches most syntax errors before you ever run the compiler! Tools like DocJet are still stuck in the compile-test-debug cycle of old. The next generation of commenting tools will be integral to the editor, and will catch spelling, grammatical, formatting and completeness errors as you're typing them.

One of the things that always distinguished DocJet from its competitors was its ability to glean formatting clues from textual idioms. While this was important back in the day, when the next generation of comment-aware editors comes out, this will be entirely unneeded. Thus tools like NDoc and Sandcastle, who grimly build documentation from machine-friendly formats are the future of this business.

Even beyond the editor, there are still interesting questions about the future of documentation. The one that strikes me as the most interesting arises from the fact that, back in 1996, if you were to write a function that, say, sets the background color, you'd probably write int setbgclr(int c). Back in the day, brevity was the fad and first-class objects were hard to make. Just by looking at setbgclr, it's hard to say just what it does. Even if you can parse the name, you would still ask what is c? Is it an index in a pallatte? An RGB quad? If so how many bits? And what of the return code, is it a 0/-1 result code? Is it maybe the previous color? Given all this, it's clear why the current generation of documentation tools are all so very good at making sure each function's documentation includes the purpose, parameters and return code.

Today, we wouldn't write setbgclr. We would write something more like void SetBackgroundColor( Color c ). Even a novice programmer can discern what this function does and what the arguments do. The old questions of purpose, arguments and return value are becoming more irrelevant every day. The important questions are more along the lines of "what constitutes the background?" and "when does this change take effect?" Creating a commenting tool that could ask those questions of commenters is the future of documentation tool development.

That's a future I'd like to be a part of, but after long investigation, I just don't believe it can be done unless you're a part of the team developing the IDE and language tools. While it's true that Eclipse and Visual Studio IDE's can now be extensively tweaked, my investigations suggest that they're not good enough to make the kind of changes I envision.

So, for the time being, I'm not working on any code for any of these ideas. I'm going to stick to theorizing from the sidelines and go on to other things.

Steve Benz - September 9, 2007