Sheldon Simms wrote:

> Im Artikel <9lhi4r$5u3$1@digitaldaemon.com> schrieb "Matt Busigin" <mbusigin@helios.spang.org.uk>:
>
> > On the subject of identifiers, I believe you should use international English, not American English.  For example, 'synchronized' should be 'synchronised'.  At least have _both_ - that's a pet peeve of mine (and would probably be a pet peeve for Americans if we made them use proper English spellings!).
>
> You are making a worse mistake by assuming that your preferred spelling
> is "international". It isn't. American spelling is taught as standard
> is many countries. In any case, it's ridiculous to gripe about this.
> As least the words are in your language. Think of all the people who
> don't have english as a native language that have to put up with english
> words as programming language reserved words. By your argument there
> should be different reserved words for each natural language, or perhaps
> thousands upon thousands of reserved words from every natural language
> to make sure that no one feels left out.

Another use for the preprocessor. I am personally illiterate and typo-maniac, so I define:

#define sinhcronised synchronized

But of course, you can't do that in D ;-)


Christophe

Im Artikel <3B7D331B.A63C155A@earthlink.net> schrieb "Christophe de Dinechin" <descubes@earthlink.net>:

> Sheldon Simms wrote:
> 
>> Im Artikel <9lhi4r$5u3$1@digitaldaemon.com> schrieb "Matt Busigin" <mbusigin@helios.spang.org.uk>:
>>
>> > On the subject of identifiers, I believe you should use international English, not American English.  For example, 'synchronized' should be 'synchronised'.  At least have _both_ - that's a pet peeve of mine (and would probably be a pet peeve for Americans if we made them use proper English spellings!).
>>
>> You are making a worse mistake by assuming that your preferred spelling is "international". It isn't. American spelling is taught as standard is many countries. In any case, it's ridiculous to gripe about this. As least the words are in your language. Think of all the people who don't have english as a native language that have to put up with english words as programming language reserved words. By your argument there should be different reserved words for each natural language, or perhaps thousands upon thousands of reserved words from every natural language to make sure that no one feels left out.
> 
> Another use for the preprocessor. I am personally illiterate and typo-maniac, so I define:
> 
> #define sinhcronised synchronized
> 
> But of course, you can't do that in D ;-)

:-)

-- 
Sheldon Simms / sheldon@semanticedge.com

kaffiene wrote:

> Personally, as a New Zealander who is a programmer, I'm used to using both interchangably (International English in everyday life, American English in software APIs).  Would it really hurt to support both spellings?

Interestingly, the C++ compiler on which I worked (HP Ansi C++ compiler) has an
error message for "misspelled keyword". I never tried to trigger that error (I
suspect it's disabled). But what if I have:

    int synchronizzed

Is this a misspelled keyword, or a valid declaration?


Christophe

Matt Busigin wrote in message <9lhi4r$5u3$1@digitaldaemon.com>...
>I think your specification actually quite well nearly embodies Java, and I doubt that is your goal!


D seriously departs from Java. Here are some of the ways, in no particular order:

1. D has out and inout function parameters, i.e. functions can return
multiple values.
2. D has enums.
3. D's floating point is the best available on the target machine.
4. D has design by contract.
5. D has a direct interface to C and operating system APIs.
6. D has lightweight structs.
7. D has strings implemented as arrays, not objects.
8. D has broad basic type support.
9. D has imaginary and complex floating point types.
10. D has typedefs.
11. D does not do dynamic class loading.
12. D has turn-offable array bounds checking.
13. D has support for assert()s and debug statements.
14. D works with your other existing dev tools (make, linkers, debuggers,
etc.)

Java is designed to be write once, run everywhere. D is designed for writing efficient native system apps. Although D and Java share the notion that garbage collection is good and multiple inheritance is bad <g>, their different design goals mean the languages have very different feels.

Christophe de Dinechin wrote in message <3B7D331B.A63C155A@earthlink.net>...
>I am personally illiterate and
>typo-maniac, so I define:
>
>#define sinhcronised synchronized
>
>But of course, you can't do that in D ;-)


d*mn right!

Christophe de Dinechin wrote:

> #define sinhcronised synchronized

sinhcronised = ?calculate sinh with cron?

"Walter" <walter@digitalmars.com> wrote in message news:9lt5k7$1th6$1@digitaldaemon.com...
>
> Matt Busigin wrote in message <9lhi4r$5u3$1@digitaldaemon.com>...
> >I think your specification actually quite well nearly embodies Java, and
I
> >doubt that is your goal!
>
>
> D seriously departs from Java. Here are some of the ways, in no particular order:
>
> 1. D has out and inout function parameters, i.e. functions can return
> multiple values.
> 2. D has enums.
> 3. D's floating point is the best available on the target machine.
> 4. D has design by contract.
> 5. D has a direct interface to C and operating system APIs.
> 6. D has lightweight structs.
> 7. D has strings implemented as arrays, not objects.
> 8. D has broad basic type support.
> 9. D has imaginary and complex floating point types.
> 10. D has typedefs.
> 11. D does not do dynamic class loading.
> 12. D has turn-offable array bounds checking.
> 13. D has support for assert()s and debug statements.
> 14. D works with your other existing dev tools (make, linkers, debuggers,
> etc.)
>
> Java is designed to be write once, run everywhere. D is designed for
writing
> efficient native system apps. Although D and Java share the notion that garbage collection is good and multiple inheritance is bad <g>, their different design goals mean the languages have very different feels.
>

<applause>
Well put, and exactly why I'm awaiting even a preliminary D compiler to
start messing around with  :)

-Brady

Kent Sandvik wrote in message <9lhsv6$ev7$1@digitaldaemon.com>...
>But in general, if the first taste of a new compiler is slowness, how good the language itself is, it will be rejected (and hard to repair the image long term). --Kent


Also, compilers for new languages tend to have poor code generators. D has an advantage of using a well developed optimizing back end. There will be no need for early adopters to suffer with long compile times and lousy generated code.

Just bugs <g>.