Posted by
Levente Uzonyi-2 on
Feb 13, 2011; 2:14am
URL: https://forum.world.st/could-we-agree-to-remove-caseOf-and-caseOf-otherwise-tp3302475p3303357.html
On Sat, 12 Feb 2011, Miguel Cobá wrote:
> El dom, 13-02-2011 a las 02:58 +0100, Levente Uzonyi escribió:
>> On Sat, 12 Feb 2011, Miguel Cobá wrote:
>>
>>> El dom, 13-02-2011 a las 02:26 +0100, Levente Uzonyi escribió:
>>>
>>>> I know what's premature optimization.
>>>
>>> It appear that you know but doesn't understand. See below.
>>>
>>>> What I do differently than other
>>>> people (including you) is:
>>>> - if I can choose from different solutions for some problem, then I
>>>> usually pick the one with the best expected performance if it has neglible
>>>> other extra cost (complexity, readability, size, etc) compared to other
>>>> solutions. E.g.: I usually write 1 to: 10 do: instead of (1 to: 10) do:,
>>>> foo ifNotNil: [ ... ] instead of foo ifNotNilDo: [ ... ] or foo isNil
>>>> ifFalse: [ ... ]), etc.
>>>
>>> This *is* premature optimization. Why? because you're programming with
>>> the performance in mind *all* the time, since the first second you start
>>> programming!
>>
>> What you fail to realize is that the code is not longer or complicated at
>> all. It has zero extra cost for you to read it, for me to write it, for
>> the machine to execute it.
>>
>>>
>>> And not only that, it relies on a specific VM implementation, the squeak
>>> one. Presumes that the given messages are *more efficient* (just because
>>> you know that the squeak compiler/vm combination makes them so). But
>>> this could be wrong or at least useless in other vm (like GNU or
>>> Gemstone). So by definition it is premature optimization.
>>
>> That's right, I don't care about other VMs. Do the developers of VW,
>> Gemstone or GNU Smalltalk care about how their code will perform on
>> SqueakVM or CogVM? Hardly.
>>
>>>
>>> Lastly, to program like you (and not like others, Igor and I and most
>>> people I think) we should have in the head the specifics of the vm
>>> implementation and a handy list of the inlined messages of the vm.
>>
>> That list is surprisingly short. There are more keywords or syntax
>> constructs in C/C++/Java/C#/Python/whatever than these special messages.
>
> The list of registers in a intel 386 cpu is short too but that doesn't
> means that everyone must learn what registers are better for what kind
> of datatype performance-wise. Again this is not the task for the
I'm sure, every assembly programmer has to learn it, but how is it related
to the messages that are inlined by the compiler?
> developer. As everyone trying to do OO programing, the implementation
> details are irrelevant when programming.
Are you serious?
>
>>
>>> This is the job of the JIT, not from the developer!
>>
>> Show me the JIT that does it.
>
> I said that is the *job* of the JIT not that every JIT can do it/should
> do it/does it.
Be honest, there's no JIT for a Pharo image, that can do this.
Levente