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

[Igor Stasenko]

On 15 June 2012 09:11, Denis Kudriashov <dionisiydk at gmail.com> wrote:
>
> Hello
>
> 2012/6/15 Igor Stasenko <siguctua at gmail.com>
>>
>>
>> On 14 June 2012 23:47, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> >
>> >
>> >
>> > On Thu, Jun 14, 2012 at 11:17 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>> >>
>> >>
>> >> What i really don't understand is why my opponents readily want to
>> >> sacrifice the performance in order to deal with consequences of having
>> >> complex systems, when its hard to reason about it,
>> >> and at same time completely opposed to proposal of adding features
>> >> which will help to reduce complexity in a first place, like adding
>> >> slot for having arbitrary properties.
>> >
>> >
>> > You;re putting up a straw man.  You *think* performance of immutability is an issue, but my experience tells me it isn't.  I've implemented it before.  So please stop raising an invalid objection.
>> >
>>
>> Remember, what i have been told when i implemented a language-side
>> scheduling, removing the
>> need of VM to even know that is Semaphore?
>> I been told *it is slow*. And this was the *only* argument against it,
>> why it is found unacceptable.
>
>
> Do you try your scheduling implementation on Cog? Very interesting what difference in performance
>

I'm not sure, but if i remember correctly , Cog puts even more
assumptions (read 'contracts') about Processes and scheduling. Though
, it is still could be possible, but it is hard to find motivation to
do that,
when others don't see the real value of it, and instead throwing it
out basing on "unproven" argument.

It is same thing again, i trying to swim against the flow and reduce
the responsibilities of VM, while most of people doing completely
opposite: adding new and new contracts between VM and language,
considered  a good thing (tm).

The more early bound semantics you put into language, the more static
it is , and if we won't stop going that way, one day we will find
ourselves programming in C , just using "exotic" smalltalk syntax.
So, why not just leave it alone and switch to C?
I know sometimes it is very hard to provide some functionality without
using early binding hammer,
and reasons could be, of course, performance and complexity.
Let me remind you that "Hardware is really just software crystallized
early." And what is Virtual Machine to language, if not hardware (the
Machine word speaks for itself)? That's why, we should think twice
before crystallizing something, because then it is much harder to
change and evolve, once it carved in stone.

That's why i raising questions about immutability, in particular.
Because my view on the role of VM is to be a servant who can optimize
certain things, but not stand in your way being a dictator who tells
you what is possible and what's not.

-- 
Best regards,
Igor Stasenko.