Re: could we agree to remove caseOf: and caseOf:otherwise:
Posted by
Ricardo Moran on
Feb 13, 2011; 3:05am
URL: https://forum.world.st/could-we-agree-to-remove-caseOf-and-caseOf-otherwise-tp3302475p3303370.html
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
<[hidden email]>
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
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