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

[Igor Stasenko]

On 14 June 2012 23:44, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> 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 the system).
>
Yes i remember this number.

But, lets pose the *right* question:
 - guys we have extra 5% of performance to waste,
what feature you would like to spend it on?

Are you sure that immutability will be absolute winner?


>> 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
>> problems.
>>
>> >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.
>>
>> Yeah, a good example of such work will be JavaScript, which made in two weeks.
>> 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.
>

Yes, this is what Andreas says.
And so, i don't buy it (not because it from Andreas, for sure ;).

Let me repeat same silly, bully, idiotic question again: suppose you
found all those errors and fixed them. What next? Your system runs
well, doing everything correctly, and... still keep paying the price
of extra check per write?

I see two major areas where immutability is useful:
A) to detect & fix bugs, like you & Andreas described
B) to use it for implementing certain features

A. Yes , it's useful. No doubt. But for sure, no doubt,  one can
detect such kinds of errors (as well as many others) by running his
software/system in "supervision" mode (like VMMaker simulating VM). As
well as writing proper tests can help in that regard too.
The only difference by making immutability an inherent property of a
system, is that you testing testing, testing every time.. Even already
tested and proven to work software. Is it only to me it sounds like a
waste?
You don't run tests when you deployed application, isn't? You testing
& fixing it during development, then you ship it, and it works. No
overhead to pay.
If immutability would be the *only* possible solution to these
problems, i would vote with both hands for it.
You may answer: yeah, of course we can do it other way, but we just
too lazy to test the software we write in a first place, so let it be
like that.
And that will be the right answer to that :)

B. Most of the software don't needs immutability for implementing its
features. Fact. A working Squeak-family systems backing up this fact
just well. So, when/where you need it? In some specialized
applications like OODBs..
And it is not because it is not available *yet*, because then,
immutability would be there much much earlier.
Marking literals as read-only is not a *feature*, it is just
protection from fools.

So, like it or not, i don't consider the impact of having immutability
so significant, that it worth paying 5% of performance.

And besides of that, why flag? If we can use the hardware to protect
from memory writes (like Stefan mentioned) so, there will be no
overhead, and then i will say not a single word against it.
If you remember, i proposed before, to develop a segmented object memory model,
so you can split a memory on segments, which could serve many
different purposes (again not just to solely support immutability):
you could have a read-only segments, you could have segments for
pinned objects etc, and apply different strategies for working with
object residing there.
And i bet some work already done in that regard by others, so it is
hardly an *experimental* , *exotic* or *academic* area (the *-* words
are sorted in order of scaryness ;) ).

This is a feature(s), which i would like to have and ready to pay the price.
But just immutability alone? Nope.



-- 
Best regards,
Igor Stasenko.