November 26, 2006
> Why do you reply in spanish?

If anybody replied in my mother language, and I would like to reply, I would reply in english and translate the the relevant parts off the original post. Because I think most people here at least understand english.


November 26, 2006
nobody_ wrote:
>> Mi queja se debe al hecho de que la gente piense que para que "sus
>> matemáticos" puedan entender mejor el código, debería usarse una sintaxis "legible" en vez de una sintaxis "críptica"... presuponiendo que la sintaxis "legible" debe ser inglesa.
>>
>> Si el problema está en que programadores profanos deben usar un lenguaje de programación.  La mejor opción es formarlos convenientemente.
>> Si por alguna razón esto no es posible, lo mejor sería que el compilador admitiese el uso de "alias" para los símbolos y las palabras reservadas.
> 
> Why do you reply in spanish? 
> 
> 
Because I have something to say... but not enough english level to express it...

Sorry :-(
Just my fault

November 27, 2006
"Don Clugston" <dac@nospam.com.au> wrote in message news:ek71e0$1ako$1@digitaldaemon.com...
> antonio wrote:
>> Ary Manzana wrote:
>>> Bill Baxter escribió:
>>>> David Qualls wrote:
>>>>> I just compiled my first D function (adapted from C), and had to replace all my 'and' 'or' and 'not's with the arcane &&, ||, and ! from prehistoric C to get it to compile.
>>>>>
>>>>> iso646.h has been a part of C for several years.  Perl, C++ and possibly other languages have all adopted 'and', 'or', and 'not' as part of their grammar.
>>>>>
>>>>> I write software that will be maintained by non-programmers
>>>>> (mathematicians, who would prefer that I use Fortran).  Lots of
>>>>> funny symbols in source code (like && || !) make it difficult to
>>>>> read for the non-immersed (ah, who am I kidding, I even have
>>>>> trouble reading it now and then).
>>>>>
>>>>> Is there any future to D incluing the logical operators in English, as opposed to &!|%'ish?  (I didn't mention it, but 'mod' might also be a good (easy for non-programmers to understand) substitute for '%'.)
>>>>>
>>>>> David
>>>>
>>>> +1
>>>>
>>>> After 20 years of C/C++ my use of && and || was pretty instinctual, but after just a few months of working with Python on the side I found I started typing 'and' and 'or' without thinking about it.  It makes complicated expressions more readable and would fit in great with D's more "modern" look.
>>>>
>>>> As noted before, I'm also in favor of allowing 'in' to replace ';' in foreach statements.
>>>>
>>>> --bb
>>>
>>> I guess the main reason to stick with symbols is some compatibility with C/C++ source code.
>>>
>>> Anyway, I also like the idea of words instead of symbols. You benefit from readability and it's also much more simpler to type (i.e. you don't you shift or look in a new keyboar for them).
>> Well..
>>
>> I'm an spanish programmer:
>>
>>   My code is written using Spanish terms like "valor" vs "value",
>> "irSiguiente()" vs "goNext()"...
>>
>> the best of algebra symbology is the language independence:
>>
>>     [x..y] vs "Between x and y"
>>     x < y  vs "x less than y"
>>     a.b    vs "the b of a"  (Director Lingo used this sintax)
>>     (a)b    vs "cast b to a"
>>     a = b  vs "set value of a to value of b"
>>     a == b vs "a equals to b"
>>     { stamens } vs "begin stamens end"
>>        I'm forced to use the basic english programming syntax: if/else,
>> while, for, foreach, public, private, protected,.... PLEASE: STOP
>> IMPOSING ENGLISH TO THE WORLD... you are not the only one programming
>> here.
>
> I've got a lot of sympathy to this. I'm really surprised that I don't hear
> this view more often.
> I'm currently maintaining some code that was written in Italian, modified
> in German, and now there's some English. It's a pig's breakfast. But
> still...
>
> My feeling is... do not program in a language which you are not fluent in. I prefer to try to read Italian written by a native speaker, than a garbled attempt at English -- it's horrible to read code that was written by someone who was putting more energy into translation, than into thinking about their programming problem.
>
> In the open-source Fast Fourier Transform project (www.fftw.org), there's
> a file with code written in Latin.
> :->

I suppose Latin would be great if you want language neutrality.  Might be politically correct, but not very practical.  I hate to be the bigot here, but let's face it.  As far as international languages go, English is a standard.  Sorry, but it's not my fault.  It's just the way it is.

However, if I had it my way we would all be speaking a simpler language.  I hate English.  A written language should be completely phonetic and orthogonal.  There shouldn't be silent letters, myriads of exceptions to rules of thumb, and ridiculous non-phonetic pronunciations.

Back to the topic, adding "and" and "or" wouldn't replace the symbolic representation.  The symbolic representation would still be valid, so I see this as a benign addition to D.   It seems it would make a lot of people happy, and would be easy to do, so I am not opposed to it.

-Craig


November 27, 2006
Craig Black wrote:
ard.  Sorry, but it's not my fault.  It's just the way it is.
> 
> However, if I had it my way we would all be speaking a simpler language.
> I
> hate English.  A written language should be completely phonetic and
> orthogonal.  There shouldn't be silent letters, myriads of exceptions to
> rules of thumb, and ridiculous non-phonetic pronunciations.

Esperanto?

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
November 28, 2006
== Quote from Craig Black (cblack@ara.com)'s article
> I suppose Latin would be great if you want language neutrality.
Might be
> politically correct, but not very practical.  I hate to be the
bigot here,
> but let's face it.  As far as international languages go,
English is a
> standard.  Sorry, but it's not my fault.  It's just the way it
is.
> However, if I had it my way we would all be speaking a simpler
language.  I
> hate English.  A written language should be completely phonetic
and
> orthogonal.  There shouldn't be silent letters, myriads of
exceptions to
> rules of thumb, and ridiculous non-phonetic pronunciations. Back to the topic, adding "and" and "or" wouldn't replace the
symbolic
> representation.  The symbolic representation would still be
valid, so I see
> this as a benign addition to D.   It seems it would make a lot
of people
> happy, and would be easy to do, so I am not opposed to it. -Craig

Thanks, Craig.  This subject seems to have taken on a life of it's own.  The simple summary is as you put it, 'and', 'or', etc would not *REPLACE* &&, ||, etc., just be available to those who found them easier to use.  Just as in C and C++.

I don't find the many proposals to "internationalize" the D language very compelling.  Face it, D is not trying to become the new rubbery language.  It's basically an enhanced and improved C++.  If niche groups did successfully translate the C++ language into other nationalities, perhaps those same niche groups could do the same with D.  Of course, it wouldn't be D then; just like C in Latin is not *really* C (at least I don't see anything in the standard that allows the keywords to be replaced by their Latin equivalents).

There was a reason C and C++ caved, and adopted English operators.  I reckon that for the very same reason, D will be hindered from a place of prominence if it does not adopt English operators.  Those who want them won't find them in D, and will move on.

Perhaps a few more BRIEF opinions regarding whether the standard English operators should be adopted within the D language would be enough to send the think-tank to their Cave Of Contemplation to debate it amongst themselves.  I, for one, am eager to hear what they have to say.  I don't recall seeing Walter weigh-in on this discussion.

David
November 28, 2006
David Qualls schrieb am 2006-11-28:

> Perhaps a few more BRIEF opinions regarding whether the standard English operators should be adopted within the D language would be enough to send the think-tank to their Cave Of Contemplation to debate it amongst themselves.

Adding addtional keywords that have exactly the same functions like already present keywords (actually keytokens) seems to be against D's spirit.

The more general issue: Iv'e checked 10 random C/C++ projects
(taken from Gentoo's portage) and none of them used iso646.h's alternative
spellings.

Thomas


November 28, 2006
Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> David Qualls schrieb am 2006-11-28:
> 
> 
>>Perhaps a few more BRIEF opinions regarding whether the standard
>>English operators should be adopted within the D language would be
>>enough to send the think-tank to their Cave Of Contemplation to
>>debate it amongst themselves. 
> 
> 
> Adding addtional keywords that have exactly the same functions like
> already present keywords (actually keytokens) seems to be against D's
> spirit.
> 
> The more general issue: Iv'e checked 10 random C/C++ projects
> (taken from Gentoo's portage) and none of them used iso646.h's alternative
> spellings.
> 
> Thomas
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFFa+7ZLK5blCcjpWoRAgQdAJ0UBatA3czG0A5+wZdMwcl50q/39gCghILf
> fpEBz2SVezekjI+rWqpibfE=
> =nQ5N
> -----END PGP SIGNATURE-----

Hang on... doesn't that header define macros that look like normal prefix functions?  You're comparing this:

> (expr1 and expr2) or (expr2 and expr3)

with this:

> or(and(expr1, expr2), and(expr2, expr3))

Given the choice between the existing boolean operators and the second lot, I'd choose the existing ones any day.  Given the choice between the existing operators and the first lot, I'd chose the first lot.

It's like the referendum regarding Australia becoming a republic: people voted against it, and the government toted that out saying "see, the public don't WANT to separate from England!"

Fact was, most polls showed that people DID want to become a republic. What they had a problem with was the nasty little condition the government added: the PM would chose the president, NOT the people. What would be the point of even *having* a president if we can't choose who it is?  Hence, given the choice between the way things are now, and a half-arsed token offering that leaves a bad taste in your mouth, we chose the lesser of two evils.

Blech; I'm rambling.  Sorry about that :)

	-- Daniel
November 28, 2006
Daniel Keep wrote:
> Thomas Kuehne wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> David Qualls schrieb am 2006-11-28:
>>
>>
>>> Perhaps a few more BRIEF opinions regarding whether the standard
>>> English operators should be adopted within the D language would be
>>> enough to send the think-tank to their Cave Of Contemplation to
>>> debate it amongst themselves. 
>>
>>
>> Adding addtional keywords that have exactly the same functions like
>> already present keywords (actually keytokens) seems to be against D's
>> spirit.
>>
>> The more general issue: Iv'e checked 10 random C/C++ projects
>> (taken from Gentoo's portage) and none of them used iso646.h's alternative
>> spellings.
>>
>> Thomas
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>>
>> iD8DBQFFa+7ZLK5blCcjpWoRAgQdAJ0UBatA3czG0A5+wZdMwcl50q/39gCghILf
>> fpEBz2SVezekjI+rWqpibfE=
>> =nQ5N
>> -----END PGP SIGNATURE-----
> 
> Hang on... doesn't that header define macros that look like normal prefix functions?

No.  They actually alias '&&' with 'and'.  Macros are a wonderful (read: terrifying) thing.

> You're comparing this:
> 
>  > (expr1 and expr2) or (expr2 and expr3)
> 
> with this:
> 
>  > or(and(expr1, expr2), and(expr2, expr3))
> 
> Given the choice between the existing boolean operators and the second lot, I'd choose the existing ones any day.  Given the choice between the existing operators and the first lot, I'd chose the first lot.

Then you're in luck, so long as you're using C/C++ :-)


Sean
November 28, 2006
Daniel Keep wrote:
> Thomas Kuehne wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> David Qualls schrieb am 2006-11-28:
>>
>>
>>> Perhaps a few more BRIEF opinions regarding whether the standard
>>> English operators should be adopted within the D language would be
>>> enough to send the think-tank to their Cave Of Contemplation to
>>> debate it amongst themselves. 
>>
>>
>>
>> Adding addtional keywords that have exactly the same functions like
>> already present keywords (actually keytokens) seems to be against D's
>> spirit.
>>
>> The more general issue: Iv'e checked 10 random C/C++ projects
>> (taken from Gentoo's portage) and none of them used iso646.h's alternative
>> spellings.
>>
>> Thomas
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>>
>> iD8DBQFFa+7ZLK5blCcjpWoRAgQdAJ0UBatA3czG0A5+wZdMwcl50q/39gCghILf
>> fpEBz2SVezekjI+rWqpibfE=
>> =nQ5N
>> -----END PGP SIGNATURE-----
> 
> 
> Hang on... doesn't that header define macros that look like normal prefix functions?  You're comparing this:
> 
>  > (expr1 and expr2) or (expr2 and expr3)
> 
> with this:
> 
>  > or(and(expr1, expr2), and(expr2, expr3))
> 
[snip]

> 
> Blech; I'm rambling.  Sorry about that :)

And not doing your homework either. :-)

A rudimentary google search turns up:

#define and && [keyword in C++]
#define and_eq &= [keyword in C++]
#define bitand & [keyword in C++]
#define bitor | [keyword in C++]
#define compl ~ [keyword in C++]
#define not ! [keyword in C++]
#define not_eq != [keyword in C++]
#define or || [keyword in C++]
#define or_eq |= [keyword in C++]
#define xor ^ [keyword in C++]
#define xor_eq ^= [keyword in C++]

So, no, iso464.h is not about prefix operators.  Just some simple #defines.

Interesting story about Australia not becoming a republic though.  :-)

--bb
November 28, 2006
Bill Baxter wrote:
> antonio wrote:
>> Bruno Medeiros wrote:
>>
>>> antonio wrote:
> 
>>>
>> Simplicity in arguments forced million people die in Holocaust :-/.
>>
>> Let time and people defend and propose their solutions... natural evolution is better than forced imposition.
>>
>> I defend, now, && because is not "and" or "y"... :-)

O_o

> 
> Cool! Thread's officially over now!
> http://en.wikipedia.org/wiki/Godwin's_law
> 
> --bb

Hell yeah... and it came surprisingly fast, Blitzkrieg style :P

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D