Nevin Pratt responded to me thusly:

>> As an example consider a program that adds a class to the system. 
>> This class is a subclass of Object, a class that's already part of 
>> the system. The imperative model represents this by sending  
>> #subclass: to the object named 'Object'. If Object doesn't exist, you 
>> get a MNU error. An well-designed system will have facilities to 
>> catch these errors and react appropriately. Nevertheless, if the 
>> error occurs in the middle of the execution, the side effects of the 
>> execution up to that point will persist. This leads to an 
>> inconsistent system.
>
>
> Not with GemStone Smalltalk.  You simply "roll back" to your point of 
> origin.  So, this proves it can be elegantly dealt with in an 
> imperitive model.

Using GemStone's transactional capabilities to keep file-ins from 
hosing your image is neither elegant nor simple. There's a reason 
GemStone is so expensive. Implementing transactions correctly and 
efficiently is *hard*. It's complete overkill for something as 
fundamental as loading a program, something which should be quite 
simple.

> Don't blame weaknesses of some specific implementation onto the 
> imperitive approach in general.

The weakness of the imperative approach is that it's hard to implement 
well. Ok, so Gemstone doesn't suck. How many Smalltalks have there been 
over the years? How many have had fullblown transactions? More to the 
point, what is the easiest and best way to bring, say, decent revision 
control capabilities to Squeak? Stephen Pair's Chango project provides 
some hope for a transaction engine, but I'm pretty sure a declarative 
representation of Smalltalk code will be an easier way to achieve it.

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

The point is that we're (or a least I am) concerned with representing 
and manipulating source code, not byte code or object code.

> In fact, if anything, I'd have to give the nod to the imperitive 
> approach, because I'm personally not aware of *any* approach that as 
> elegantly deals with the issue in the declarative model (without 
> artifacts like the above) as GemStone does with the imperitive model.  
> If anybody *does* have an elegant solution, I think it would be David 
> Simmons with S#, but I haven't looked deeply enough to judge.

Compilation of declarative code fails if its dependencies are not met 
by the system at the time it is compiled. It's that simple. Sure, if 
you tried to run the resulting bytecode in a different environment than 
it was compiled in, it might not work. But that's always true, no 
matter how you represent the source code.

As for elegant approaches that use a declarative model, how about 
Ginsu, Envy, and VSE?

> But in either camp, the "initial state sensitivity" issue has to be 
> dealt with.  Thus, I don't see any real difference, and so I remain 
> unconvinced.

Suit your self...

> BTW, I quite like your description that "an imperative representation 
> is essentially a program that constructs a program".  Of course, I 
> think you can see that it too lacks precision, as your definition is 
> recursive, and a fileout isn't recursive.  But I still like your 
> phrase, and your inclusion of the word "essentially" gives you the 
> needed wiggle room, IMO.

Yes, this is subtle stuff. I said "essentially" because I'm not sure 
that a series of DoIts constitute a program. In fact, a definition of 
the word "program" would help this discussion immensely. I don't think 
my description is recursive, though, as I'm not defining the word. The 
program constructs another program, it doesn't construct its self.

Cheers,

Colin