David Brown wrote:
A lot of modern languages are getting pretty good about solving both of
these problems.  The code stays as the definitive description, and the
documentation is generated from the code.

My experience with this sort of system is a complete lack of overall introductory documentation. For example, sit down with the man pages for bind(), listen(), socket() and related functions, and see if you can figure out what's going on without already knowing how sockets are supposed to work. Or sit down with some .NET classes and see if you can deduce why every class says "instance methods are thread-safe, but class methods aren't," and what you're supposed to do about it.

Any system big enough that you need multiple modules full of classes is going to need some documentation outside of every class.

Otherwise, you wind up like people trying to use MS Word for a large writing project without having any idea what styles are, formatting every line separately, because the overall structure of how things are intended to work is opaque.

--
  Darren New / San Diego, CA, USA (PST)
    "That's pretty. Where's that?"
         "It's the Age of Channelwood."
    "We should go there on vacation some time."

--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg

Reply via email to