== Quote from Bernard Helyer ([email protected])'s article > I'm writing a compiler, not a half-arsed documentation generator (because > if I wrote the DDoc stuff, that's exactly what it would be).
I'll concur with Walter. I think that sometimes power users of a given tool/feature fail to realize that very often simple, good enough and works out of the box beats well-designed, feature-packed, efficient, but a PITA to set up and use, overkill for simple cases, and not available out of the box. I understand treating ddoc as a low priority feature, but **please** support it eventually, as the whole point of it is that it's just there on any implementation (nothing separate to download/configure) and just works for the simplest 80-90% of cases even if its deficiencies become obvious in the last 10-20%. In general I also think that DDoc's evolution is actually good design strategy. I wish more tools were designed by pinning down how the simplest 80-90% of cases should work first, treating that as a constraint and then figuring out how to make the most complicated 10-20% work within the constraint. Designing with "everything must be possible" as the first goal encourages overengineering such that users with simple needs end up reinventing the wheel because it's the path of least resistance. For example, I'd probably never use Ddoc if I had to use XML for it.
