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