and/or/not/xor operators

[Regan Heath]

On Tue, 04 Jun 2013 23:47:07 +0100, ixid <nuaccount at gmail.com> wrote:

> On Monday, 3 June 2013 at 09:29:20 UTC, Regan Heath wrote:
>> On Fri, 31 May 2013 21:26:56 +0100, ixid <nuaccount at gmail.com> wrote:
>>
>>>> We really don't want D to become a TMTOWTDI language.  Ideally there  
>>>> should be 1 right way and no alternatives.  That way, anyone who  
>>>> knows D will have a greater chance of knowing what any given code  
>>>> sample does, and not have to look up alternate syntax etc.
>>>>
>>>> R
>>>
>>> Up to a point I'd certainly agree with that, however in this case I  
>>> think the advantages outweigh the penalty.
>>
>> Not for me, and I suspect others too.
>>
>>> These operators are self-documenting, no one will need to look up 'and'
>>
>> I can't recall ever being confused by &&.. in fact, I got my first  
>> programming job (an apprentice position) by describing some C code (a  
>> language I had never used/seen before) using && and I immediately guess  
>> what it meant, it was obvious from the context.
>>
>>> and gain readability
>>
>> To me using "and" would reduce parsability (as in by my human eyes) and  
>> that would hamper readability, for me.
>>
>>> language accessibility
>>
>> Any programmer that does not understand && needs to be educated,  
>> period.  Once that happens they can code in numerous other languages,  
>> so win-win.
>>
>>> beauty.
>>
>> I don't find && ugly, in fact I would go so far as to say that code  
>> using "and" would be less pleasant to my eyes.
>>
>> R
>
> I think you're coming from a position of what is rather than what can  
> be. You're practiced with && so it appears more normal than it is.

Yes.  I am, and every other C and C++ programmer is.  Just about no-one is  
practiced with "and" or "or" in a programming language.

> a and b
>
> is far clearer than
>
> a && b

No, it's really not (for me).

> especially as you add more terms:
>
> a and b or c
>
> versus
>
> a && b || c

The latter is still clearer (to me).

R