OpenEuphoria

Re: unfolded expressions

• Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Jul 20, 1999
• 450 views

Dialog between me & Lewis Townsend:

> > > >Speaking about confusing statements, its really in the hand of the
> > > >programmer.
> > > >This is legal, already:
> > > >
> > > >     function pos (object x)
> > > >         return x + ( x < 0 ) * -2x)
> > > >     end function
> > >
> > > What?! I didn't know that was legal! Can you really
> > > eliminate the "*" operateor like that? (-2x)
> >
> >It doesn't eliminate the '*' .. what I eliminate is the if-statement, by
> >using boolean math.
>
> I know what you were doing, I was just kidding you because
> you forgot a '*' in your function:
>         return x + ( x < 0 ) * -2x)
> should be
>         return x + ( x < 0 ) * -2 * x)
> I believe                         ^
> You are quite right.  I too can write horribly complex
> code using Euphoria's current syntax. Infact, I don't
> think that your example was all that bad.

I didn't even notice I made a mistake. I suppose it proves the complexicity
of the above code. On the other hand, it would be catched and fixed in no
time. I personally still have no problem coding like above. As if I would
remember the algorithm at all, after some time. I won't .. so I would have
to figure it out again anyway, so why not keep it fast, short, flexible and
compact, and only comment what it does, rather than how. If I can come up
with it once, I can do that again. When it works, it works, etc. Clearity is
only important for the big picture. Not all little tad details. That's what
using seperate include files and modules, etc. is about.  And precizely in
that area, Euphoria needs a little more work. (yeah, yeah, not another
namespace discussion, at least this statment lacks any suggestions to
discuss) ..   than we can worry less about the clearity of the code.
Program, debug, test and seperate it from the whole program, and the
underlying tricks ? comments, clear code, clean algorithms, and other things
that require hours and hours of work .. think not. Just keep the
end-programmer interface of your include file clean and you'll be fine. This
'clear' and 'unconfusing' argument used in any discussion related to new
extensions and improvements to Euphoria is, in my eyes, done.

I mean, does this look logical ?

    if find (0, ("euphoria" = input_string) + ("EUPHORIA" =  input_string )
then

Its the same as: (when the size of input_string is fixed!)

    if compare ("euphoria", input_string) and compare ("EUPHORIA",
input_string) then

But this is the most clean alternative:

    if compare ("euphoria", lower(input_string) then

But guess, which approach is the fastest ? Etc.
If the comment above this code would say:

     -- check if the input was euphoria regardless of capatilization

Would it really matter which code was used ?

Anyways, I've proven at least my point, that writing unclear code, has got
nothing to do with syntax and everything with attitude, perspective and
trivial choices I and you make...

> >The argument is can create confusing statement is, in my eyes, a
ridiculous
> >argument. So can I with any part of the syntax of Euphoria.
>
> Well, if a proposed syntax could ONLY create confusing code then
> it's a different matter IMHO.

Completely true, but I personally can't come up with the desire of new
syntax either without a need or at least one example were it would be more
elegant than current solutions. I suppose, only creating confusing code,
could, at most, only be possible with suggestion that base from theoretical
consistentency rather than suggestions based from practical and
context-related desire of expression methods. (See, even in English you can
create huge complex sentence that really no one even tries to comprehense