bearophile wrote:
Walter has said that putting ddoc inside the compiler helps keep ddoc
uniform, so people don't invent/use something different. In theory this is a
nice purpose, but in practice I have seen lot of people use other
documentation means for D, Doxygen. Walter seems to ignore how much often
such other systems are used instead of ddoc.
It's fine if people choose to use other documentation systems. Ddoc, though,
sets a minimum standard, and it's always there, requires no additional installs,
is always synced to the compiler, is always on every platform D is, etc.
My experience with languages that do not have built in doc abilities is, by and
large, only a tiny minority of programmers use a doc system. Having to research,
download, install, read the manual, address incompatibilities, etc., takes
effort and the reality is that by making such effort close to zero it greatly
encourages people to use it.
The same goes for unit tests.
For another example, back in the 80's, it was commonplace for people to dis the
C text preprocessor as "not a real macro system". Those who wanted a better one
were advised to "just use m4". How many people using C or C++ today use m4 as
the preprocessor? Zilch. The C preprocessor was good enough to get the job done,
it was always there, always ready, and that was that.
(Note that I'm not defending the preprocessor, I'm just illustrating the power
of having something built in as opposed to being a separate tool.)
