[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

[Bert Freudenberg]

On 2012-06-14, at 12:53, Andreas Raab wrote:

> Igor wrote:
>> On 13 June 2012 16:32, Andreas Raab <Andreas.Raab at gmx.de> wrote:
>> > I absolutely do. There were several situations (for example in Croquet and at Teleplace) where we changed our designs to the worse merely due to the lack of immutability support. The main thing that immutability fixes is to prevent accidental modifications of objects thought to be immutable (method literals for example), which when they happen are *extremely* hard to find.
>> 
>> I finding this very weak argument. You are talking about developing
>> project and bug fixing.. Yes i agree immutability can be useful for
>> debugging. But for deployed & well tested applications?
>> Once you found all bugs, and deploy your application, do you really
>> think it is worth paying the price for checking all write operations,
>> when you already made sure that your app will behave correctly?
> 
> First of all, the same can be said for array bounds checking. There are very good reasons to leave it on, and the very same reasons hold for immutability. But more importantly, testing is *never* done until "all bugs are found". Testing is done until boredom overcomes fear. And nothing more. You're expressing a rather academic perspective here.
> 
>> As for *extremely* hard to find, i think first thing which you should
>> address in such cases is the complexity
>> of your application, to always be able to reason about it's behavior
>> and make sure it behaves "deterministically", because if software
>> grows too large up to the point that you need such kind of crutches to
>> figure out what's happening, immutability alone doesn't solve your
>> problems, it can only indicate that you have a problems with your
>> design.
> 
> So what you're saying is that we should've just made our application simpler? Gee, I guess we never thought of that! Now I finally understand why Stefane is paying you the big bucks to work on Pharo :-) Seriously, Igor, academia is not becoming to you, you need to get back into the real world. Preferredly into a startup with real pressure to ship something. Because, right now you're mostly just talking out of your rear end. In particular considering that one thing that would have made our application considerably simpler would have been immutability.
> 
>> > But it also gives rise to many other interesting techniques (read-only transactions etc).
>> >
>> 
>> Look, we have completely open system in our hands. Do you think it is
>> impossible to implement certain things w/o immutability?
> 
> Well, by the end of the day everything is possible. Even implementing immutability without VM support, for example by copying all the classes and recompiling them to raise errors when stored into them. But the problems from that solution are manifold, from class hierarchy issues, to special VM objects etc. Once you go through the exercise (which I did once) you start thinking that it would be so easy and simple to implement immutability in the VM. And it's a fact that in our system having immutability would have made it simpler and faster. But then again, I have no skin in this game any longer, so take my comments with whatever amount of salt you'd like.
> 
> Cheers,
>   - Andreas

It should be possible to disagree and still keep the discussion civilized. Please?

I trust Eliot will take all this with a lump of his preferred mineral and come up with something good ;)

- Bert -