Darren New schrieb:

> 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.

Dream on :-)

Automatic code generation from tools has been the subject of wishful 
thinking for decades. Yes, CASE tools do exist. But where are they used, 
and how powerful are they really?

I've seen such a tool only once in real life: It was used to document 
state machines and generate code for them. But even there, too often 
people would just try to make it generate the state machine they wanted, 
instead of actually documenting it. And more often than not, the actual 
"meat" code would contain additional hidden state variables.

> 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.

Exactly. But this will not happen unless management understands the 
business reason for it in the first place, and makes sure the coder has 
enough time to carefully plan, document and test his work.


>> 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.

Probably not, indeed. Embedding code into documentation will only work 
if the file format is inherently suited to documentation needs. 
Unfortunately it's not so easy to find some common ground for this.


>> 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.

That C part of ACID would be covered by the contract-oriented paradigm I 
think.


>> 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.

That direction may indeed be problematic, but changing from a stack to a 
double-ended queue shouldn't be a problem, as a stack is just a special 
case of a deque that provides no access to the "head" of the queue.

That it's not so easy with the STL is a problem of C++, not OO languages 
in general. And even with the STL it would be a piece of cake if you had 
chosen to use a typedef (which you could interpret as a kind of 
"identity inheritance") in the first place instead of hard-coding the 
type name everywhere.


> C++ seems to do pretty well, and its not using any OO for the STL.  

Oh, sure it does! For instance, the class behind the vector::iterator 
type derives from the class behind vector::const_iterator, which in turn 
derives from some obscure class _Ranit - to name just the very first 
example I chanced upon.

It also appears to me that the main reason to avoid any class hierarchy 
for the "primary classes" is in this case the heavy use of templates, 
which may not mix too well with inheritance on various compilers.

And the /design/ of the STL is heavily object-oriented at any rate. For 
instance, the documentation refers to both "deque<T,Alloc>" and 
"vector<T,Alloc>" as /models/ (think "implementation") of the /concepts/ 
(think "abstract classes" or "interfaces") "Random access container" and 
"Back insertion sequence" (with "deque" also being a model of "Front 
insertion sequence").


> 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.

Note that data encapsulation /is/ an OO trait. And are you really sure 
they don't use any OO portions behind the scenes? You were obviously 
mistaken regarding STL.

>> 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.

A library using an OO design does not necessarily imply that you can 
subclass it, or any of its components.

Post a reply to this message