[Gambas-user] static const?

[Fabián Flores Vadell]

>> I don't agree the criteria for saving one variable or one expresion if
>> it is not justified.
>>
> Well, perhaps my daily work with little CPUs (some have 32 bytes of
> ram!) drives me to professional bias, but why use a variable if can be
> avoided? There is more than one reason for this (reported without an
> order). One: variables have to be declared at the beginning of a block;
> when I write code, if I want to use a variable I must go back to the
> start of the code and add the declaration, leaving the old "road of my
> mind". Then I must go back to the relevant part and concentrate again on
> the code.

I don't see the problem here. When you think about create a variable
(or any other memory structure), you never let to think about your
algorithm. In fact, if the language require previous variable
declaration is a good thing because forces to think about on
resources you will use and how you will do that.

I think that the choices about memory structures is one of the
critical parts when you write an algorithm.

So, when you think about variables far away of divert attention,
actually you are deepening your understanding about the problem and
your algorithmic solution.

> Two: saving a state to later break a loop is less
> straightforward than doing it "in place". If the logic of an algorithm
> is "concentrated" in a single point, instead of being spread around, it
> is easier to revise - at least for me.
>
> Three: I think that fast
> algorithms are always better than slow ones.

I think that if the speed is a requeriment, that's right. But if not,
just is right if is to easy to do. So, not always a faster algorithm
is better. Let me quote to Donald Knuth when he said "premature
optimization is the root of all evil (or at least most of it) in
programming".

> It is the duty of a good
> programmer to write good code: and good code is fast and easy to read.

I believe that a good code is one that is simple, and to achieve this
goal at least must (sure I forget something):

- Uses the correct structures of memory and control
- Have high cohesion and low coupling
- Be correctly modularized
- Uses good names
- Be written in order that it is easy to understand it

> Perhaps, if I was a teacher, I would say different things. But teachers
> sometimes are a little distant from the reality; and scholars will face
> it later - when they will be programmers.

The industry insists in that the most important things are compliance
of requirements and easy maintenance.

> That said, using a variable is a cost (even more for interpreted
> languages like gambas). Well - we must understand each other. By no mean
> I want to say that using variables is awful - is a technique with pros
> and cons.

Easy, I understand you.

>    if (i<TabStrip.count) and (tabstrip[i].caption blahblahblah) THEN
> blahblahblah
>
> This is a logical mislead, because it puts together two unrelated
> concepts: the test on the relevant thing (we look for caption), and a
> "good precaution" which has little to do with the algorithm. In fact, I
> would rewrite it as
>
>    if i<tabstrip.count then if tabstrip[i].caption...
>
> There is no difference in the final (machine) code, but the second
> statement looks to me more explanatory.

I agree.

> And, to be sincere, there is
> more. The ambiguity of the first statement is well stressed in other
> languages (sorry, they exist), where sometimes there is no warranty
> about the order of evaluation of expressions. For whatever reason, a
> compiler could evaluate tabstrip[i].caption *before* tabstrip.count.
> And, of course, the compiler is right - the AND operation is commutative
> (the two terms can be swapped), like addition and multiplication. Back
> to gambas - I don't know if the documentation says anything about
> short-circuit and things like that. May be we can assume it as a
> standard, that modern languages always do short-circuit, but the concept
> remains.

I agree.

>  function movefile(src, dst as string) as boolean
>    result = false
>    if not exists(src) then return
>    if not open_and_read(src) then return
>    close(src)
>    if not open_and_write(dst) then return
>    close(dst)
>    result = true
>  end
>
> Now comes personal taste. The second routine, for you, is a joke.

Oh, no. The joke was: IF (YouWriteInC) THEN RETURN. Maybe, we not
share the same humor sense.

> For
> me, it looks simpler, shorter, and faster. The only problem I see are
> those repeated "not" and "return". They are ugly to see, but very clear
> in saying "if this operation fails, then stop". The code coverage should
> be simpler to do, but I am not really sure.

When I have to write many logical tests, I separates them in a new
function. That allow me keep the code short and self explanatory. I do
this in a extremist way especially when I want to anybody can
understand my code.

I know this is even more expensive than using a variable. I don't
care, I never seen a penalization over performance for that, and if I
have to do some optimization, I would do later.

>> I think that the subject here is identify practices that have
>> potential to bring problems.
>>
> GOTOs were the only mean to control the program flow, once upon a time.
> When some genius broke the rules and invented structural programming,
> GOTOs were rewarded as evil, and we are still in the long wave of this
> thought.
> But Pascal (and C, - sorry - the most important language of all times,
> until now), still retained GOTOs. Strange... may be that they are, after
> all, not so evil?

Clearly, this was done to maintain backward compatibility (the root of
the rest of evils).

> We don't want spaghetti outside our food, but there is
> a way in between - ok for a GOTO, when you have a reason for that.
> Practices that have potential to bring problems are not simple things
> like "using GOTO", or "using object oriented programming". The issue is
> far more complicated. Going on, I would say that, in certain cases, it
> *is* an error to not use GOTOs. In some situations, it is an error to
> use objects. And so on. Nothing is perfect, and nothing is totally bad.

I understand. Maybe, you express that with too much relativism.

> Well. I really enjoyed to discuss with you. Because I feel that we both
> have slightly changed our mind - we have had an improvement. Even If we
> didn't change our thought, it seems to me that we, at least, had
> understand each other. Not a bad thing.

This was a productive discussion to me. I learned new things.

Regards.

-- 
Fabián Flores Vadell
www.speedbooksargentina.blogspot.com