May 31, 2013
On Fri, 31 May 2013 02:41:14 +0100, Shriramana Sharma <samjnaa@gmail.com> wrote:

> Thanks to all who replied.
>
> On Thu, May 30, 2013 at 10:18 PM, bearophile <bearophileHUGS@lycos.com> wrote:
>>
>> But Walter refused them time ago on the basis that no one uses them in C++.
>> So you can ask for them in the main D newsgroup, but I don't think you will
>> see them in D...
>
> Um why really? "No one uses them in C++"? How come?

Until this thread I didn't even know they existed.. and I've been coding in C++ for ~12 years.  I suspect people who came to C++ from C (as I did) would not learn about them, because they are simply alternate syntax for something they already know and use.

I find them ugly and less clear - because I can glance at words & symbols and immediately see the operator, faster than with words and symbols.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
May 31, 2013
On Thursday, 30 May 2013 at 16:48:33 UTC, bearophile wrote:
> Shriramana Sharma:
>
>> Hello. I have always loved the readability of C++'s and/or/not/xor
>> word-like logical operators but It doesn't seem to be available in D.
>
> and/or/not are less visually noisy, they look better than the ugly &&/||/! of C/C++/D, and it's much less easy to write & when you need && or vice versa, so they are also less bug-prone, as Python shows. On this Python syntax got it better than D.
>
> But Walter refused them time ago on the basis that no one uses them in C++. So you can ask for them in the main D newsgroup, but I don't think you will see them in D...
>
> Bye,
> bearophile

They are more noisy for non-English talking persons.
May 31, 2013
Regan Heath:

> I find them ugly and less clear - because I can glance at words & symbols and immediately see the operator, faster than with words and symbols.

Finding a short, common and easy to write English word "ugly" is quite strange, especially for a person that seems able to write in English.

In C code it's not uncommon to write "&" where you meant "&&" by mistake and vice versa (so common that all the lint tools I know of have rules to spot such kind of bug). And for most kinds of not low-level programming bitwise operators are far less commonly used than boolean operators. So it's a good idea to visually differentiate them more.

Maybe if you program in Python a little you will appreciate my opinion :-)

---------------

Minas Mina:

>They are more noisy for non-English talking persons.<

It's hard to believe, it's the first time I hear that. I have no reliable studies on this topic.

Bye,
bearophile
May 31, 2013
On Fri, May 31, 2013 at 4:12 PM, Minas Mina <minas_mina1990@hotmail.co.uk> wrote:
> They are more noisy for non-English talking persons.

Um and the rest of the D keywords are in what language?!

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

May 31, 2013
On Friday, 31 May 2013 at 10:21:19 UTC, Regan Heath wrote:
> Until this thread I didn't even know they existed..

Same.

I use them every day in python, but I had no idea they were in C++

Tbh they annoy me in python, although that's just my C background showing.
May 31, 2013
> 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. These operators are self-documenting, no one will need to look up 'and' and gain readability, language accessibility and beauty.

June 03, 2013
On Fri, 31 May 2013 21:26:56 +0100, ixid <nuaccount@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

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
June 04, 2013
On Monday, 3 June 2013 at 09:29:20 UTC, Regan Heath wrote:
> On Fri, 31 May 2013 21:26:56 +0100, ixid <nuaccount@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.

a and b

is far clearer than

a && b

especially as you add more terms:

a and b or c

versus

a && b || c

Which is just symbolic gibberish to anyone beginning programming. Digraphs are almost as bad as trigraphs.
June 05, 2013
On Tue, 04 Jun 2013 23:47:07 +0100, ixid <nuaccount@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@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
June 05, 2013
On Wednesday, 5 June 2013 at 09:02:44 UTC, Regan Heath wrote:
> On Tue, 04 Jun 2013 23:47:07 +0100, ixid <nuaccount@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@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

Although I love the easy-to-read properties of and/or, I always find they make it too tempting to read the code as english instead of formal logic.

E.g.
a and b or b and c
vs.
a && b || b && c

For me, the latter reminds me that I need to specify precedence whereas with the former it's just too easy to place the emphasis yourself like you do when reading prose.
1 2
Next ›   Last »