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

[Andreas Raab]

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

        
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120614/ea950826/attachment-0002.htm