Colin Putney wrote:

>
>
>> The same warning likewise applies for the declarative approach as 
>> well, which typically creates such artifacts as "DLL-hell", "JRE 
>> version proliferations", "glibc version mismatch", etc.  All of those 
>> real-world artifacts (and I'm sure quite a few more) have, as their 
>> underlying root cause, the same "initial state sensitivity" issues 
>> that the imperitive approach has.  It is the specific way that those 
>> language designers chose to meet the "initial state sensitivity" 
>> challenge that produced those artifacts.
>
>
> These problems have nothing to do with declarative representation vs 
> imperative representation.


Not directly, no.  They instead are artifacts of the way the various 
language designers chose to meet the challenge of "initial state 
sensitivity".  They also are common artifacts of the declarative design 
choices commonly made these days.  They don't necessarily need to be, 
though.  I gave a reference to David Simmons work as a potential counter 
example.

> They are the result of an attempt to link incompatible chunks of 
> executable object code into a single process space. If you compile 
> some code against one version of a library and try to link it against 
> another version, it's no surprise if it doesn't work.


They are the result of creating "consumer" code that is dependent on a 
particular initial state for the "supplier" code (i.e., a particular 
version of the supplier code library).

Nevin