A declarative model of Smalltalk (was Re: [DOCS] SUnit tests)
nevin at smalltalkpro.com
Sun Feb 23 14:52:22 UTC 2003
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
> 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).
More information about the Squeak-dev