[Vm-dev] Sounds baaad sounds

[Igor Stasenko]

On 1 February 2011 18:14, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> On 2/1/2011 5:50 PM, Igor Stasenko wrote:
>>
>> On 1 February 2011 16:04, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>>>
>>>> That's really nice design, because you can place all primitive-related
>>>> part into platform/dialect specific package
>>>> and it enables you to use same FileSystem API among not just various
>>>> forks of Squeak, but even among various dialects of smalltalk,
>>>> without need of hacking/porting core API classes!!!
>>>
>>> Yes, that is a very nice approach if the goal is to support different
>>> backend primitives. On the other hand, *unless* that is the goal and
>>> *unless* there are significant differences in the backend implementation
>>> the
>>> approach borders on needless complexity.
>>>
>> Hmm..
>> Are you sure that following is not 'needless complexity'?
>>
>> ADPCMCodecPlugin, having ZERO methods at its instance side, and only
>> one method at its class side.
>>
>> ADPCMCodecPlugin class>>translateInDirectory: directory doInlining:
>> inlineFlag
>> "handle a special case code string rather than generated code"
>> "Not currently hooked into the timeStamp mechanism for VMMaker since
>> this would mean replicating code from InterpreterPlugin; waiting for a
>> more elegant solution to appear. In the meantime this means that this
>> plugin will always get regenerated even if the file is uptodate"
>>        | cg |
>>        self initialize.
>>
>>        cg := self buildCodeGeneratorUpTo: InterpreterPlugin.
>>
>>        cg addMethodsForPrimitives: ADPCMCodec translatedPrimitives.
>>        inlineFlag ifTrue:[
>>                "now remove a few which will be inlined but not pruned"
>>                cg pruneMethods: #(indexForDeltaFrom:to: nextBits:
>> nextBits:put:)].
>>        self storeString: cg generateCodeStringForPrimitives onFileNamed:
>> (directory fullNameFor: self moduleName, '.c').
>>        ^cg exportedPrimitiveNames asArray
>>
>>
>> this method alone could spoil someone's day because as it appears that
>> this class serves only as a facade, while all of the behavior lies
>> somewhere else.
>>
>> So, if that is not an example of 'unnecessary complexity', then what it
>> is? :)
>
> Why do you think I would disagree with your analysis? ;-) ADPCMCodecPlugin
> is not exactly a shining example of compactness and straightforwardness. But
> adding another layer surely won't improve on that ;-)
>
>> Why bother creating ADPCMCodecPlugin, when code generator can do this
>> by itself by simply looking for all implementors of
>> #translatedPrimitives
>> of all classes in system, and generate necessary primitives out of them.
>> Simple, universal and doing the same, because there are no clear
>> separation between 'what is a primitive' and what is language side
>> code.
>> But if that is not a goal, then why bother, right?
>>
>>
>>>> I think that this approach could be applied to sound prims as well, to
>>>> nicely decouple a front-end API, from low-level backend, implemented
>>>> either primitively or 'naively' or whatever.
>>>
>>> It could, but see above. What would be the point of doing this? It just
>>> adds
>>> complexity and unless there is tangible benefit I'm against adding
>>> needless
>>> complexity. I mean, if one indirection is good, two must be better, no?
>>> ;-)
>>
>> I cannot agree.
>> Good design which comes from dependency decoupling and good
>> abstraction layer(s) is not 'unnecessary complexity'.
>> In fact, in far perspective, it works straightly in opposite direction.
>
> I completely agree. But in this case the decoupling already exists. It's the
> primitive where the decoupling happens. The extra indirection is helpful
> only if one needs multiple (non-primitive) backend implementations.

but it is already like that , no? if there is no primitive, then it
fails and code is interpreted directly instead.


> Without
> that need it's a pointless indirection. For example, would you really
> consider it better design if we added the same kind of extra indirection for
> SmallInteger primitives? That's why I'm saying I don't like to add
> complexity unless there is tangible benefit in return. If there is, then
> absolutely, go for it. But if there isn't, then let's be careful with
> additional layers. They tend to get out of hand much too quickly.
>
>> This code smells. Usually things smell bad because they rot. :)
>
> Which code specifically? ADPCMCodecPlugin? Agreed for the most part. But
> then again, I don't think adding another indirection will address that smell
> particularly well.
>
>> And what people usually do with things which rotten? They throw them out.
>> Yeah, there are few, who so passionate that they could overcome the
>> disgust and start digging in rotten pile of cruft in hope to find
>> precious gems.
>> But usually this not happens often, because people having more fun things
>> to do.
>>
>>
>> Hopefully the above explains better what i meant by saying:
>> "the only means how to maintain this code is either freeze it for
>> ages, or throw it out completely."
>> to which you replied with:
>> "I fail to see how either one follows from the premise."
>
> And I still don't see it :-) You seem to forget the option to simply fix
> what's broken. That's so obvious that I still don't get why freezing or
> throwing away would be the only options.
>

Well, from your words it sounds that i should not fix it. Or should
not do it like i proposing.
Currently i don't care about eventual complexity increase or not. What
i care about is VMMaker consistency.

The problem that i (why i? WE!) need to have guaranteed way to
reproduce the VM sources, no matter what base image i using
(be it Pharo, Squeak or Cuis or Croquet).
In cases when generated VM code almost directly or indirectly or in
some nontrivial way depends on code inside an image (which not
explicitly declared as part of VM), this is problematic, because
obviously nobody could be able to track all these dependencies,
because then it requires too much knowledge and magic incarnations to
simply build same VM as you built , and therefore when people who know
all these shady corners in labyrinth leave our community at some day,
then we will be left with an artifact which no one will be able to
reproduce sitting at home and running a build script.
Then if next time someone will say "my image crashing, how to fix
that?", the most probable answer will be "we are not sure" or "we
don't know".
And after getting such kind of answers, people usually start looking
for better tools to use.

My vision is simple: VM-side is VM side. Language side is language
side. This is because VM compiled statically
and can't change during runtime.. and if not that, then there will be
no any issues with it :)

It appears that pharoers incidentally touched stuff which are not
supposed to be touched under pain of death.
Sure thing they was not aware that thing which they touching contains
behavior which goes directly into VM. So, i'd like to not see such
incidental refactorings in future. Because people having right to
change the language/system in the way they want without fearing that
they incidentally will change the most heart of a system - VM. And for
that we need a clear separation with BIG red banner: if you cross that
line - there is no turning back.. (or something like that ;)


> Cheers,
>  - Andreas
>


-- 
Best regards,
Igor Stasenko AKA sig.