Re: Re (tilly) 1: Atoms as a concept for programming analysis

I'm not sure why the 'but' ... an atom isn't going to be repeated because it already exists. You're going to reuse an atom every time you can. (But, then again, I'm assuming logic will be used here. *shrugs*)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Re: Re (tilly) 1: Atoms as a concept for programming analysis

Replies are listed 'Best First'.
Re (tilly) 3: Atoms as a concept for programming analysis by tilly (Archbishop) on Oct 08, 2001 at 20:51 UTC
The reason for the but is that if you are trying to merely decompose into atoms, then you have no reason to aim to create atoms that are maximally reusable in creating other atoms. Indeed not creating them makes for more local simplicity. When reusability conflicts with local simplicity (and they very often do), saying that reusability generally wins is based on some value system. Without a value system to reason from, your conclusion is not just logic. I think that the concept of intellectual compression captures the value system quite well. I think that the atomic hypothesis captures what you do, but misses why you do it, and cannot resolve that conflict.	[reply]

Replies are listed 'Best First'.

Re (tilly) 3: Atoms as a concept for programming analysis
by tilly (Archbishop) on Oct 08, 2001 at 20:51 UTC

When reusability conflicts with local simplicity (and they very often do), saying that reusability generally wins is based on some value system. Without a value system to reason from, your conclusion is not just logic. I think that the concept of intellectual compression captures the value system quite well. I think that the atomic hypothesis captures what you do, but misses why you do it, and cannot resolve that conflict.

[reply]