[Vm-dev] [Pharo-project] Plan/discussion/communication around new
Andreas.Raab at gmx.de
Thu Jun 14 10:53:17 UTC 2012
> 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
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.
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...
More information about the Vm-dev