[Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

Ricardo Moran richi.moran at gmail.com
Sun Feb 13 04:05:33 CET 2011


Ok, guys... I'm sorry to interrupt this polite discussion, but this is
taking nowhere. Having such strong arguments (for or against) is not helpful
for anybody.
We all know using #caseOf:otherwise: it's not exactly good style, but
sometimes you need to compromise between design and efficiency, and having
simple and efficient constructs such as #caseOf: is very good IMHO.
You are free to avoid them if your projects don't need it, and if you happen
to need extra performance you can always build your own JIT, right? :)
But please don't ban people who are willing to sacrifice a little
readability for performance reasons. Thanks.

Best regards.
Richo



2011/2/12 Levente Uzonyi <leves at elte.hu>

> 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
>
>
>
>>
>>
>>>
>>> Levente
>>>
>>>
>>>>
>>>>  - I optimize library code which is expected to be heavily used
>>>>>
>>>>
>>>> This the time and usage will tell
>>>>
>>>>
>>>>  - I like to optimize code
>>>>>
>>>>
>>>> Prematurely it appears!
>>>>
>>>> Cheers
>>>>
>>>> --
>>>> Miguel Cobá
>>>> http://twitter.com/MiguelCobaMtz
>>>> http://miguel.leugim.com.mx
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> --
>> Miguel Cobá
>> http://twitter.com/MiguelCobaMtz
>> http://miguel.leugim.com.mx
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110213/6b29d7a5/attachment.htm>


More information about the Pharo-project mailing list