clipka wrote:
> That's not a problem of the tool, but the person using it. Those people 
> taking it as an excuse wouldn't do any docuentation at all otherwise, 
> unless forced at gunpoint.

Not necessarily. As I said elsewhere, a tool that would make the high-level 
documentation generate source code (and where the changes to the source code 
would be reflected in the HDL) would help. It would let people who are 
designing the system document it as part of the progress forward.

The problem with writing code documentation is that it doesn't help the 
coder. It only helps the people who come after. So it's seen as a waste 
unless the coder understands the business reason for it.

Imagine something like TDD, except with documentation instead of tests.

Or imagine a block diagram with arrows showing data flow between the blocks, 
where that's *actually* the code.

> As far as making life easier for people who do have the honest desire to 
> document properly, I think integrating the documentation with the source 
> code is a good way to go, and docman and javadoc make good tools for hem.

If you're documenting the *code*, yes. I'm wondering if it's also possible 
to design a language that makes it easy to document the intention, the 
architecture, etc as part of building the code.  Tangle and weave, anyone?

> Then again, maybe it's the approach taken from the wrong side, and the 
> true proper way would be embedding the source code in the documentation, 
> not vice versa - if only for the psychological effect.

Yes, exactly something like this.  We probably won't get there as long as 
the primary form of source code is ascii strings.

> There's no general way around it, because malicious people of this type 
> are highly intelligent and inventive. Whatever you'd integrate into the 
> language itself would just give you a /false sense of/ security.

Hard to say. Certainly having a language with bounds checking is safer than 
a language without bounds checking. How far can that go?

> The only thing you can do about it is /defensive/ programming - but 
> that's a paradigm you probably cannot support with language features I 
> guess. Well, maybe stuff designed for contract-oriented programming 
> would help with this.

Yeah, that's the sort of thing I'm thinking.  Or like the C part of ACID.

>> Stuff like the ability for me to know that my change hurt your code. 
>> Something like unit testing, only built into the language, say.
> 
> That seems to go into a similar direction as contract-oriented design.

To some extent, yes. That, or typestate analysis, or some such. I don't know 
the answer.  I just know it's a problem looking for a better answer.

> Try implementing and using generic container classes in a non-OO language.


> Then try to refactor your application to use a deque container instead 
> of a stack for a certain job. Or a tree-backed map instead of a 
> hash-table-backed one someplace else.

I can't imagine changing a queue to a stack without needing to rewrite a 
fair amount of the code using that structure.

C++ seems to do pretty well, and its not using any OO for the STL.  Python 
and LISP also do pretty well without actually using the OO portions of the 
language, as would Ada I think. Erlang (and Hermes) both handle this just 
fine as well, and that's not OO. You just need good encapsulation, not 
inheritance or dynamic binding or anything like that.

> You won't have much success without implementing verbosely what OO 
> languages do for you behind the scenes.

Sure. OO is pretty good at data structures and GUIs. But what about other 
libraries? What about math libraries, HTTP libraries, networking libraries, 
databases, etc? None of those types of libraries tend to be designed for you 
to subclass the instances.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message