[Vm-dev] [Pharo-project] Plan/discussion/communication around new
eliot.miranda at gmail.com
Thu Jun 14 21:44:32 UTC 2012
On Thu, Jun 14, 2012 at 9:03 AM, Igor Stasenko <siguctua at gmail.com> wrote:
> On 14 June 2012 12:53, Andreas Raab <Andreas.Raab at gmx.de> 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.
> Sure. Because we're talking about object format design. I just not
> sure that benefits of immutability so great that they outweigh the
> performance overhead.
But so you know what the performance overhead is? In VisualWorks it was <
5% over a wide range of benchmarks (e.g. real benchmarks such as recompile
And i thinking we should not stop looking for better solutions.
Of course. But for now immutability is in because I, and many others with
real experience in the Smalltalk world, think it more than pays its way.
> > 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 :-)
> How nice of you, Andreas. You had bad sleep?
> I just said that using immutability to _detect_ problems in your
> software is not the same as using immutablity to address certain
> >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
> Nice suggestion, but thanks. No.
> Trust me, i worked long enough in industry and know what you talking
> about. Now i don't see any parallels to what we discussing here. It is
> completely orthogonal.
> There's enormous amount of crap in software produced because of such
> approach. And Squeak and it's VM is not an exception.
> If you think that immutability can help you producing less crappy
> software, then i afraid i have to disappoint you: no, the amount of
> crap will remain the same, and even increase. Because the more
> concepts you putting into domain, the more complex it becomes, and in
> a non-linear progression, for sure.
Not so. Just avoiding updating supposedly immutable literals is a win.
When immutability was added to VisualWorks many errors in the base classes
were found. The most typical being related to ^'' writeStream.
> If we're want to improve that, then it is better to take a time, think
> twice before cutting (and yeah, read some hatred academia papers, if
> you like to know if there other/better solutions
> exist to your problems, because (what a surprise!!) many people meet
> the same problems as you do).
> >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.
> Care to share some practical example?
> Because to me your attitude to this flag sounds like "solve all my
> problems = 1" in object header.
> >> 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.
> That's what i thinking too. But why you stop there and don't think
> further: what if there a solution which can make things even simpler
> and don't require immutability?
> This where i trying to drive a discussion. Now, if you keep insisting
> that immutability solves all your problems, and you don't care to
> think about better alternatives (because you have a boss with a whip
> who will execute you if you don't deliver in time) then there's
> nothing to discuss.
> >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
> Best regards,
> Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev