www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest

reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
 
http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/

Ali
Jun 09 2015
next sibling parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Tuesday, 9 June 2015 at 18:02:55 UTC, Ali Çehreli wrote:

 http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/


"I might've said D, but I don't think it qualifies as "emerging" 
since it's over a decade old."

Well, it's just ridiculous, although I often see people trying to 
say that minus D is "a decade of transition from D1 to D2. Many 
call D `the dead` :) But I believe that sooner or later D will 
destroy C++, because it is still in development, though not very 
fast, but stable and it is good! D will rise to the top of the 
mountain `Uphill`, despite all the prejudices of the people, 
knowing nothing about the history of D.
And, by the way, I have never heard of the Crystal :)
Jun 09 2015
next sibling parent reply "Israel" <tl12000 live.com> writes:
On Tuesday, 9 June 2015 at 18:25:36 UTC, Dennis Ritchie wrote:

 On Tuesday, 9 June 2015 at 18:02:55 UTC, Ali Çehreli wrote:

 http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/


 And, by the way, I have never heard of the Crystal :)


Ruby that compiles?
Jun 09 2015
parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Tuesday, 9 June 2015 at 18:46:48 UTC, Israel wrote:

 Ruby that compiles?


Yet Rust, Nim and Crystal is a very young languages. And alas, 
life is not eternal to wait five years of a flourishing language 
:) There are already ready to be used option. This is D.
Jun 09 2015
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 9 June 2015 at 18:53:06 UTC, Dennis Ritchie wrote:

 On Tuesday, 9 June 2015 at 18:46:48 UTC, Israel wrote:

 Ruby that compiles?


 Yet Rust, Nim and Crystal is a very young languages. And alas, 
 life is not eternal to wait five years of a flourishing 
 language :) There are already ready to be used option. This is 
 D.


Exactly. Nim for example sounds interesting, however, we already 
have D. I've used it for years and I know that it scales and that 
I can write reliable real world applications in it. With Nim etc. 
it would take years to actually know, if it scales or if you hit 
a brick wall after a couple of years. D has overcome many of the 
"child diseases" that Nim, Crystal etc still have to face.

One big difference between the D community and other languages' 
communities is is that D people keep criticizing the language and 
see every little flaw in every little corner, which is good and 
which is why D is the way it is. Other languages' communities are 
more like "This is theeeeeee language of the future, it's 
super-duper, no question asked, none permitted either!"
Jun 10 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 One big difference between the D community and other languages' 
 communities is is that D people keep criticizing the language 
 and see every little flaw in every little corner, which is good 
 and which is why D is the way it is. Other languages' 
 communities are more like "This is theeeeeee language of the 
 future, it's super-duper, no question asked, none permitted 
 either!"


this is actually one of my favorite parts of the D community 
too(besides it being extremely friendly/helpful)

bunch of language snobs on this NG ;)
Jun 10 2015
prev sibling next sibling parent reply "Thiez" <thiezz gmail.com> writes:
On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 One big difference between the D community and other languages' 
 communities is is that D people keep criticizing the language 
 and see every little flaw in every little corner, which is good 
 and which is why D is the way it is.


Or perhaps D simply has more flaws to criticize.

On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 Other languages' communities are more like "This is theeeeeee
 language of the future, it's super-duper, no question asked,
 none permitted either!"


Perhaps you are depicting other communities as a bunch of 
group-think hipsters because you are insecure about your own 
community?

Look, I can make baseless accusations too. Wouldn't you agree it 
would be nicer (and more effective, I imagine) to promote your 
community by calling attention rather to its positive qualities, 
rather than demonizing other communities? Especially when your 
negative portrayals of other communities are not accompanied by 
any evidence?

I'm sure you're a smart person and will for each of the 
communities in question be able to find evidence of at least one 
person who at some point in time acted in the way you suggested. 
Of course such a thing would not prove that the behaviour is 
representative of the community, so please don't.
Jun 10 2015
next sibling parent reply "anonymous" <anonymous anonymous.com> writes:
On Wednesday, 10 June 2015 at 14:29:51 UTC, Thiez wrote:

 On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 One big difference between the D community and other 
 languages' communities is is that D people keep criticizing 
 the language and see every little flaw in every little corner, 
 which is good and which is why D is the way it is.


 Or perhaps D simply has more flaws to criticize.

 On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 Other languages' communities are more like "This is theeeeeee
 language of the future, it's super-duper, no question asked,
 none permitted either!"


 Perhaps you are depicting other communities as a bunch of 
 group-think hipsters because you are insecure about your own 
 community?

 Look, I can make baseless accusations too. Wouldn't you agree 
 it would be nicer (and more effective, I imagine) to promote 
 your community by calling attention rather to its positive 
 qualities, rather than demonizing other communities? Especially 
 when your negative portrayals of other communities are not 
 accompanied by any evidence?

 I'm sure you're a smart person and will for each of the 
 communities in question be able to find evidence of at least 
 one person who at some point in time acted in the way you 
 suggested. Of course such a thing would not prove that the 
 behaviour is representative of the community, so please don't.


any community dumb enough to buy merchandise with a programming 
language's name on it is full of idiots.
bye.
Jun 10 2015
parent reply "anonymous" <anonymous anonymous.com> writes:
On Wednesday, 10 June 2015 at 15:08:08 UTC, anonymous wrote:

 any community dumb enough to buy merchandise with a programming 
 language's name on it is full of idiots.
 bye.


p.s., Nim has the absolute worst community out of any of these 
languages.
http://slashdot.org/comments.pl?sid=6771453&cid=48860921
Jun 10 2015
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Wednesday, 10 June 2015 at 15:09:21 UTC, anonymous wrote:

 On Wednesday, 10 June 2015 at 15:08:08 UTC, anonymous wrote:

 any community dumb enough to buy merchandise with a 
 programming language's name on it is full of idiots.
 bye.


 p.s., Nim has the absolute worst community out of any of these 
 languages.
 http://slashdot.org/comments.pl?sid=6771453&cid=48860921


You're not doing the D community any great credit with this post, 
either. Try and stay classy.
Jun 10 2015
next sibling parent "anonymous" <anonymous anonymous.com> writes:
On Wednesday, 10 June 2015 at 15:13:41 UTC, Brian Rogoff wrote:

 On Wednesday, 10 June 2015 at 15:09:21 UTC, anonymous wrote:

 On Wednesday, 10 June 2015 at 15:08:08 UTC, anonymous wrote:

 any community dumb enough to buy merchandise with a 
 programming language's name on it is full of idiots.
 bye.


 p.s., Nim has the absolute worst community out of any of these 
 languages.
 http://slashdot.org/comments.pl?sid=6771453&cid=48860921


 You're not doing the D community any great credit with this 
 post, either. Try and stay classy.


not from the D community.
Jun 10 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 10 June 2015 at 15:13:41 UTC, Brian Rogoff wrote:

 On Wednesday, 10 June 2015 at 15:09:21 UTC, anonymous wrote:

 On Wednesday, 10 June 2015 at 15:08:08 UTC, anonymous wrote:

 any community dumb enough to buy merchandise with a 
 programming language's name on it is full of idiots.
 bye.


 p.s., Nim has the absolute worst community out of any of these 
 languages.
 http://slashdot.org/comments.pl?sid=6771453&cid=48860921


 You're not doing the D community any great credit with this 
 post, either. Try and stay classy.


Translation: "Let me try to shame you because I don't have any 
actual argument..."
Jun 10 2015
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Wednesday, 10 June 2015 at 17:34:48 UTC, deadalnix wrote:

 On Wednesday, 10 June 2015 at 15:13:41 UTC, Brian Rogoff wrote:

 On Wednesday, 10 June 2015 at 15:09:21 UTC, anonymous wrote:

 On Wednesday, 10 June 2015 at 15:08:08 UTC, anonymous wrote:

 any community dumb enough to buy merchandise with a 
 programming language's name on it is full of idiots.
 bye.


 p.s., Nim has the absolute worst community out of any of 
 these languages.
 http://slashdot.org/comments.pl?sid=6771453&cid=48860921


 You're not doing the D community any great credit with this 
 post, either. Try and stay classy.


 Translation: "Let me try to shame you because I don't have any 
 actual argument..."


Stick with your day job and leave mind reading and translation to 
experts! :-)

What's the actual argument? Is cherry picking comments from 
unmoderated fora and posting them here in an effort to put down 
some other language community supposed to be good behavior, or 
rather rude and hypocritical? I say the latter, and the general 
way to deal with rude behavior is to point it out, what you seem 
to believe is 'shaming'. If you don't think that was rude, we 
simply disagree.

The Rust community is probably the absolute best because 
tolerance for that is near zero. Too much I think, but perhaps 
they're right and it's for the best.
Jun 10 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/10/15 10:54 AM, Brian Rogoff wrote:

 The Rust community is probably the absolute best because tolerance for
 that is near zero. Too much I think, but perhaps they're right and it's
 for the best.


I'm glad to notice the tone of posts here, say, after DConf has improved 
substantially. -- Andrei
Jun 10 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 10 June 2015 at 18:06:16 UTC, Andrei Alexandrescu 
wrote:

 On 6/10/15 10:54 AM, Brian Rogoff wrote:

 The Rust community is probably the absolute best because 
 tolerance for
 that is near zero. Too much I think, but perhaps they're right 
 and it's
 for the best.


 I'm glad to notice the tone of posts here, say, after DConf has 
 improved substantially. -- Andrei


*sigh* Indeed. Some of the posts do seem to be too 
confrontational lately. But it'll probably blow over like it 
usually does. It would be nice though if we stayed civil around 
here.

- Jonathan M Davis
Jun 10 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 10 June 2015 at 17:54:15 UTC, Brian Rogoff wrote:

 The Rust community is probably the absolute best because 
 tolerance for that is near zero. Too much I think, but perhaps 
 they're right and it's for the best.


It's always a good idea to not go personal, but I think they 
overdo it when you're not allowed to write "he" as a general term 
because it is gender specific. I suspect the design of Rust 
suffers a bit from group think:

http://en.wikipedia.org/wiki/Groupthink
Jun 10 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 10 June 2015 at 18:18:55 UTC, Ola Fosheim Grøstad 
wrote:

 It's always a good idea to not go personal, but I think they 
 overdo it when you're not allowed to write "he" as a general 
 term because it is gender specific.


That's actually a good idea, you might not have noticed it, but I 
rarely use "he" alone as a general term and I notice it when 
other people do. Little things like this in language can make a 
difference in people's feelings and cause discomfort in the 
environment.
Jun 10 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 10 June 2015 at 18:41:56 UTC, Adam D. Ruppe wrote:

 That's actually a good idea, you might not have noticed it, but 
 I rarely use "he" alone as a general term and I notice it when 
 other people do. Little things like this in language can make a 
 difference in people's feelings and cause discomfort in the 
 environment.


Sure, follow your own ethics, but that won't work in an 
international environment as a rule without coming off as 
censorship. You cannot force people globally to follow a local 
culture. I also try to cut down on the term "you" as a general 
term since people might think I mean them personally.

At some point you just have question intent if there is a 
misunderstanding, rather than control every expression or else 
everything becomes "it":

"A bad programmer create bugs when it edits its files...".

And if people force you to write "it", it is quite reasonable to 
wonder what else they strongly object to so you better just stay 
silent. I really do try to cut down on the term "you"?
Jun 10 2015
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/10/2015 09:05 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 ...

 At some point you just have question intent if there is a
 misunderstanding, rather than control every expression or else
 everything becomes "it":

 "A bad programmer create bugs when it edits its files...".


Just use plural, it's what you mean anyway.

"Bad programmers create bugs when they edit their files...".


 And if people force you to write "it", ...


"it" doesn't seem appropriate.

http://en.wikipedia.org/wiki/Gender-specific_and_gender-neutral_pronouns#It_and_one_as_gender-neutral_pronouns

"However, when not referring specifically to children, "it" is not 
generally applied to people, even in cases where their gender is unknown."
Jun 10 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 10 June 2015 at 19:22:37 UTC, Timon Gehr wrote:

 Just use plural, it's what you mean anyway.


I was being ironic...

Variation is good for language. Artificial constraints like 
"gender neutral terms" harm expression. It is not a reasonable 
policy making arena in non-official contexts. But even then the 
best option is to vary, sometimes use "she", sometimes "he", 
sometimes "thin", sometimes "fat", sometimes "black", sometimes 
"white", etc...

But the real point is _culture_. Most people are happy they make 
themselves understood in a foreign language.
Jun 10 2015
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
Please note, OED (which is the definition of the English language
whatever any USA upstarts may try to pretend) is gearing up to define
"they" as both singular and plural, thus at a stroke solving all the
he/she, she/he, (s)he, it faffing.

On Wed, 2015-06-10 at 19:05 +0000, via Digitalmars-d wrote:

 On Wednesday, 10 June 2015 at 18:41:56 UTC, Adam D. Ruppe wrote:

 That's actually a good idea, you might not have noticed it, but=20
 I rarely use "he" alone as a general term and I notice it when=20
 other people do. Little things like this in language can make a=20
 difference in people's feelings and cause discomfort in the=20
 environment.


=20
 Sure, follow your own ethics, but that won't work in an=20
 international environment as a rule without coming off as=20
 censorship. You cannot force people globally to follow a local=20
 culture. I also try to cut down on the term "you" as a general=20
 term since people might think I mean them personally.
=20
 At some point you just have question intent if there is a=20
 misunderstanding, rather than control every expression or else=20
 everything becomes "it":
=20
 "A bad programmer create bugs when it edits its files...".
=20
 And if people force you to write "it", it is quite reasonable to=20
 wonder what else they strongly object to so you better just stay=20
 silent. I really do try to cut down on the term "you"?


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 10 2015
next sibling parent David Gileadi <gileadis NSPMgmail.com> writes:
On 6/10/15 12:56 PM, Russel Winder via Digitalmars-d wrote:

 Please note, OED (which is the definition of the English language
 whatever any USA upstarts may try to pretend) is gearing up to define
 "they" as both singular and plural, thus at a stroke solving all the
 he/she, she/he, (s)he, it faffing.


Is they out of its mind? :)
Jun 10 2015
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Wednesday, 10 June 2015 at 19:57:15 UTC, Russel Winder wrote:

 Please note, OED (which is the definition of the English 
 language


OED is a reflection(an approximate one at that) of what the 
English language is, not the definition.
Jun 10 2015
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Wednesday, 10 June 2015 at 19:57:15 UTC, Russel Winder wrote:

 Please note, OED (which is the definition of the English 
 language


As Tofu Ninja said, a dictionary only (partly) reflects the 
current usage of a language. Look up the word "sophisticated" and 
you'll find out that it had a different meaning in the 1920s. In 
fact, dictionaries invariably lag behind and as soon as a new 
version is published it's already out of date.

Also, do not forget that those who create and revise dictionaries 
are not representative of all speakers. They will typically be 
part of an elite that defines the language in terms of their own 
belief system. Most certainly so in Great Britain.


 whatever any USA upstarts may try to pretend)


I shouldn't really comment on this cultural snobbery. However, 
different linguistic communities have different linguistic 
realities. The English spoken in the US, Ireland or Scotland is 
not the same as in England. The linguistic reality for a speaker 
in Liverpool is not the same as for a speaker in London. But who 
cares, English is beyond the grasp of Oxford now. You only have 
yourselves to blame, nobody asked you to go and spread the 
language all over the globe.


 is gearing up to define
 "they" as both singular and plural, thus at a stroke solving 
 all the
 he/she, she/he, (s)he, it faffing.





 On Wed, 2015-06-10 at 19:05 +0000, via Digitalmars-d wrote:

 On Wednesday, 10 June 2015 at 18:41:56 UTC, Adam D. Ruppe 
 wrote:

 That's actually a good idea, you might not have noticed it, 
 but I rarely use "he" alone as a general term and I notice 
 it when other people do. Little things like this in language 
 can make a difference in people's feelings and cause 
 discomfort in the environment.


 
 Sure, follow your own ethics, but that won't work in an 
 international environment as a rule without coming off as 
 censorship. You cannot force people globally to follow a local 
 culture. I also try to cut down on the term "you" as a general 
 term since people might think I mean them personally.
 
 At some point you just have question intent if there is a 
 misunderstanding, rather than control every expression or else 
 everything becomes "it":
 
 "A bad programmer create bugs when it edits its files...".
 
 And if people force you to write "it", it is quite reasonable 
 to wonder what else they strongly object to so you better just 
 stay silent. I really do try to cut down on the term "you"?
Jun 11 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/10/2015 12:56 PM, Russel Winder via Digitalmars-d wrote:

 Please note, OED (which is the definition of the English language
 whatever any USA upstarts may try to pretend) is gearing up to define
 "they" as both singular and plural, thus at a stroke solving all the
 he/she, she/he, (s)he, it faffing.


Hmm, so instead of the documenting the language now the OED is trying to invent 
it? Such cheek! :-)
Jun 11 2015
parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 12/06/2015 2:53 AM, Walter Bright wrote:

 On 6/10/2015 12:56 PM, Russel Winder via Digitalmars-d wrote:

 Please note, OED (which is the definition of the English language
 whatever any USA upstarts may try to pretend) is gearing up to define
 "they" as both singular and plural, thus at a stroke solving all the
 he/she, she/he, (s)he, it faffing.


 Hmm, so instead of the documenting the language now the OED is trying to
 invent it? Such cheek! :-)


Nope, singular they has existed since at least the 1600s. It was an act 
of prejudice in the 1920s[1] that began its decline in usage. The 
current move by the OED is to reverse that act of invention and document 
actual use.

A...

[1] See Modern English Usage (3rd edition or later) [ISBN: 0-19-860263-4]
Jun 12 2015
prev sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Wednesday, 10 June 2015 at 19:57:15 UTC, Russel Winder wrote:

 Please note, OED (which is the definition of the English 
 language
 whatever any USA upstarts may try to pretend)


Glad to hear it. Please tell your countrymen to prefer the '-ize' 
suffix, as we colonials do, to the '-ise' one, which is a French 
affectation.

http://en.wikipedia.org/wiki/Oxford_spelling
Jun 11 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 12 June 2015 at 02:12:39 UTC, Brian Rogoff wrote:

 On Wednesday, 10 June 2015 at 19:57:15 UTC, Russel Winder wrote:

 Please note, OED (which is the definition of the English 
 language
 whatever any USA upstarts may try to pretend)


 Glad to hear it. Please tell your countrymen to prefer the 
 '-ize' suffix, as we colonials do, to the '-ise' one, which is 
 a French affectation.

 http://en.wikipedia.org/wiki/Oxford_spelling


Funny how people argue about English spelling, because English 
has no spelling at all. It's irrational, inconsistent and part of 
the English class system. Why is it that English has the highest 
rate of dyslexics while Spanish has a very low rate of dyslexics? 
Because Spanish spelling is much more consistent and phonetic 
than English spelling. Gosh, you dare not say this!

Apart from that, spelling is merely a convention you get used to. 
People oppose to "-ize" because they were brought up with "-ise". 
If you have a new generation of Englishmen that were taught 
"-ize", they would find "-ise" strange. It's ridiculous how 
people get attached to stuff like this.
Jun 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 12 June 2015 at 11:13:08 UTC, Chris wrote:

 "-ise". If you have a new generation of Englishmen that were 
 taught "-ize", they would find "-ise" strange. It's ridiculous 
 how people get attached to stuff like this.


I have to admit I use "-ize" over "-ise" because I think it 
visually looks cooler. I always felt I did something wrong by 
mixing "colour" and "-ize", but this thread has finally lifted 
this guilt off my shoulders!

"They" as singular feels weird tho, but maybe it is related to 
the archaic "thou" and "thee"? We had the same in norwegian ~60 
years ago. "De" (they) was used as singular towards strangers and 
"du" (you) was used with people you were familiar with. Then you 
could claim to be "dus" (friendly) with people you knew 
(referring to the fact that you use "du" when adressing them). 
Kinda like german "Sie".
Jun 12 2015
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 12 June 2015 at 11:35:30 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 12 June 2015 at 11:13:08 UTC, Chris wrote:

 "-ise". If you have a new generation of Englishmen that were 
 taught "-ize", they would find "-ise" strange. It's ridiculous 
 how people get attached to stuff like this.


 I have to admit I use "-ize" over "-ise" because I think it 
 visually looks cooler. I always felt I did something wrong by 
 mixing "colour" and "-ize", but this thread has finally lifted 
 this guilt off my shoulders!

 "They" as singular feels weird tho, but maybe it is related to 
 the archaic "thou" and "thee"? We had the same in norwegian ~60 
 years ago. "De" (they) was used as singular towards strangers 
 and "du" (you) was used with people you were familiar with. 
 Then you could claim to be "dus" (friendly) with people you 
 knew (referring to the fact that you use "du" when adressing 
 them). Kinda like german "Sie".


Do you speak Bokmål or Nynorsk?

Here's a nice piece about "Language Mavens". They are quite 
common in every country, and invariably they don't have a clue 
about how languages and the human mind work:

http://www.sp.uconn.edu/~sih01001/english/fall2007/TheLanguageMavens.pdf
Jun 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 12 June 2015 at 13:05:36 UTC, Chris wrote:

 Do you speak Bokmål or Nynorsk?


Bokmål, but neither Bokmål or Nynorsk are naturally spoken 
languages, they are written languages.

Nobody actually speaks Nynorsk (only in poetry, drama and movies 
where it is read in a rather literal way), it is a synthetic 
language, but it is quite close to some dialects (and I sometimes 
flip over when talking to people who are close to it). Nynorsk 
came about as part of the national romantic movement, an attempt 
to find the "true norwegian language". Then again Bokmål (which I 
do speak) is also a "synthetic" language that came about as 
"mispronounced" Danish (which was the formal official language 
for a long time). Kind of like Danish spoken letter-by-letter 
thus getting more clear consonants than in a natural language. 
Some decades ago they decided to create a new united languages 
that basically was a new synthetic bastardized language that 
nobody wanted to speak, and they gave up on it. In the districts 
Bokmål is more natural and "rounded" than here in Oslo though and 
some dialects sounds like a natural mix and it wouldn't make much 
sense to say they speak Bokmål or Nynorsk. I believe pure Bokmål 
as a spoken language was more of an upper class thing and is 
called Riksmål (Bokmål that tends towards archaic forms)

The funny thing is that Danish and Bokmål almost reads the same, 
but sounds completely different and some words even have opposite 
meanings ("grine" means to laugh in Danish, but to cry in 
Norwegian). Norwegians sometimes joke that in order to get a Dane 
to understand what you are saying you have get really drunk and 
mumble, then they will understand you perfectly! Or maybe it is 
just factual and based on experience? Alcohol is cheaper in 
Denmark…


 Here's a nice piece about "Language Mavens". They are quite 
 common in every country, and invariably they don't have a clue 
 about how languages and the human mind work:

 http://www.sp.uconn.edu/~sih01001/english/fall2007/TheLanguageMavens.pdf


Looks very interesting, I have to give that a closer look later.
Jun 12 2015
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 12 June 2015 at 13:51:55 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 12 June 2015 at 13:05:36 UTC, Chris wrote:

 Do you speak Bokmål or Nynorsk?


 Bokmål, but neither Bokmål or Nynorsk are naturally spoken 
 languages, they are written languages.

 Nobody actually speaks Nynorsk (only in poetry, drama and 
 movies where it is read in a rather literal way), it is a 
 synthetic language, but it is quite close to some dialects (and 
 I sometimes flip over when talking to people who are close to 
 it). Nynorsk came about as part of the national romantic 
 movement, an attempt to find the "true norwegian language". 
 Then again Bokmål (which I do speak) is also a "synthetic" 
 language that came about as "mispronounced" Danish (which was 
 the formal official language for a long time). Kind of like 
 Danish spoken letter-by-letter thus getting more clear 
 consonants than in a natural language. Some decades ago they 
 decided to create a new united languages that basically was a 
 new synthetic bastardized language that nobody wanted to speak, 
 and they gave up on it. In the districts Bokmål is more natural 
 and "rounded" than here in Oslo though and some dialects sounds 
 like a natural mix and it wouldn't make much sense to say they 
 speak Bokmål or Nynorsk. I believe pure Bokmål as a spoken 
 language was more of an upper class thing and is called Riksmål 
 (Bokmål that tends towards archaic forms)

 The funny thing is that Danish and Bokmål almost reads the 
 same, but sounds completely different and some words even have 
 opposite meanings ("grine" means to laugh in Danish, but to cry 
 in Norwegian). Norwegians sometimes joke that in order to get a 
 Dane to understand what you are saying you have get really 
 drunk and mumble, then they will understand you perfectly! Or 
 maybe it is just factual and based on experience? Alcohol is 
 cheaper in Denmark…


Very interesting. I wish I could speak all languages on the 
planet!


 Here's a nice piece about "Language Mavens". They are quite 
 common in every country, and invariably they don't have a clue 
 about how languages and the human mind work:

 http://www.sp.uconn.edu/~sih01001/english/fall2007/TheLanguageMavens.pdf


 Looks very interesting, I have to give that a closer look later.


Yes, it's a nice read. I've had my fair share of language mavens, 
they really don't know nothing, oops, anything about natural 
languages. They're just opinionated pricks that are full of 
themselves.
Jun 12 2015
prev sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Friday, 12 June 2015 at 11:35:30 UTC, Ola Fosheim Grøstad 
wrote:

 "They" as singular feels weird tho, but maybe it is related to 
 the archaic "thou" and "thee"? We had the same in norwegian ~60 
 years ago. "De" (they) was used as singular towards strangers 
 and "du" (you) was used with people you were familiar with. 
 Then you could claim to be "dus" (friendly) with people you 
 knew (referring to the fact that you use "du" when adressing 
 them). Kinda like german "Sie".


"Hey, you see that person over there? What are they doing? Is 
that their big red stuffed dinosaur?"

"A person came in to the shop today and the entire time they just 
keept asking for corks, we sell paint..."

"I am going to wear this big pink sombrero and if anyone has a 
problem with it, well they can just suckit"

Just as a few examples of gender neutral singular they/their.
Jun 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 12 June 2015 at 15:02:35 UTC, Tofu Ninja wrote:

 "Hey, you see that person over there? What are they doing? Is 
 that their big red stuffed dinosaur?"

 "A person came in to the shop today and the entire time they 
 just keept asking for corks, we sell paint..."

 "I am going to wear this big pink sombrero and if anyone has a 
 problem with it, well they can just suckit"

 Just as a few examples of gender neutral singular they/their.


But I am thinking more of the origin, that plural form perhaps 
signifies distance?

Is the following wrong? (I wouldn't know, but it looks wrong to 
me.)

"My friend came in to the shop today and the entire time they 
just kept asking for corks..."
Jun 12 2015
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Friday, 12 June 2015 at 15:19:40 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 12 June 2015 at 15:02:35 UTC, Tofu Ninja wrote:

 "Hey, you see that person over there? What are they doing? Is 
 that their big red stuffed dinosaur?"

 "A person came in to the shop today and the entire time they 
 just keept asking for corks, we sell paint..."

 "I am going to wear this big pink sombrero and if anyone has a 
 problem with it, well they can just suckit"

 Just as a few examples of gender neutral singular they/their.


 But I am thinking more of the origin, that plural form perhaps 
 signifies distance?

 Is the following wrong? (I wouldn't know, but it looks wrong to 
 me.)

 "My friend came in to the shop today and the entire time they 
 just kept asking for corks..."


For me that sounds 100% fine...
Jun 12 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 12 June 2015 at 18:32:22 UTC, Tofu Ninja wrote:

 On Friday, 12 June 2015 at 15:19:40 UTC, Ola Fosheim Grøstad 
 wrote:

 "My friend came in to the shop today and the entire time they 
 just kept asking for corks..."


 For me that sounds 100% fine...


Ah, ok. I found this link interesting:

http://blog.dictionary.com/oldenglishgender/

Apparently Old English may have lost its gendered nouns when it 
was melted with Old Norse due to conflicting genders on same noun.

And it is rather obvious that english "they" have common root 
with norwegian "de" from Old Norse "þeir":

https://en.wiktionary.org/wiki/þeir

So I'd find it an odd coincidence if norwegian singular "De" was 
not related to english singular "they"… but it could also come 
from "Sie" through the trade German influence in Bergen around 
1300…

Wikipedia has no real answer I think except that the first 
written occurrence of singular they was early 1300.

https://en.wikipedia.org/wiki/Singular_they
Jun 12 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 12 June 2015 at 19:52:56 UTC, Ola Fosheim Grøstad 
wrote:

 was not related to english singular "they"… but it could also 
 come from "Sie" through the trade German influence in Bergen 
 around 1300…


Or more likely Danish…  I think they have same polite singular 
form "De". It makes sense that one might pick up polite forms 
through trading. Oh well.
Jun 12 2015
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 6/13/2015 3:32 AM, Tofu Ninja wrote:


 "My friend came in to the shop today and the entire time they just
 kept asking for corks..."


 For me that sounds 100% fine...


Not to me. Gender-neutrality is for the cases when the gender is unknown 
or the subject is generic, e.g. "A person". I would assume that you are 
likely to know the gender of a friend, in which case 'they' makes no 
sense here.

When I used to play Dark Age of Camelot, there was one line of text that 
annoyed me to no end. Anytime someone summoned their horse, you would 
see a message like this:

"Dougal mounts their horse."

Wrong, wrong, wrong!
Jun 12 2015
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Saturday, 13 June 2015 at 01:09:48 UTC, Mike Parker wrote:

 On 6/13/2015 3:32 AM, Tofu Ninja wrote:
 Not to me. Gender-neutrality is for the cases when the gender 
 is unknown or the subject is generic, e.g. "A person". I would 
 assume that you are likely to know the gender of a friend, in 
 which case 'they' makes no sense here.

 When I used to play Dark Age of Camelot, there was one line of 
 text that annoyed me to no end. Anytime someone summoned their 
 horse, you would see a message like this:

 "Dougal mounts their horse."

 Wrong, wrong, wrong!


Actually I think it matters more if the person you are talking to 
knows the gender of the person you are talking about, in the shop 
sentence the gender of the friend is unknown to the person you 
are talking to so "they" still works.

I suppose the Dark Age of Camelot line doesn't make sense because 
you as the listener know the gender of Dougal, though honestly it 
still sounds fine to me because I am not really sure if Dougal is 
supposed to be male or female.
Jun 12 2015
parent Mike Parker <aldacron gmail.com> writes:
On 6/13/2015 10:26 AM, Tofu Ninja wrote:


 Actually I think it matters more if the person you are talking to knows
 the gender of the person you are talking about, in the shop sentence the
 gender of the friend is unknown to the person you are talking to so
 "they" still works.


So then, use the gender-specific pronoun and the listener is no longer 
in the dark! What the listener knows or doesn't know doesn't play into 
it in this case. 'My friend' is a specific person, and specific people 
have a gender. Someone, anyone, a person, a human, etc... are all 
generic, so the gender is always unknown to the speaker.
Jun 13 2015
prev sibling parent "Laeeth Isharc" <laeeth nospamlaeeth.com> writes:
On Wednesday, 10 June 2015 at 19:05:15 UTC, Ola Fosheim Grøstad 
wrote:

 Sure, follow your own ethics, but that won't work in an 
 international environment as a rule without coming off as 
 censorship. You cannot force people globally to follow a local 
 culture.


True, and a question of balance.  A little bit of mutual 
adjustment goes a long way.


 I also try to cut down on the term "you" as a general term 
 since people might think I mean them personally.


That's what 'one' (rather than 'you') is for.  But if one uses 
the word 'one' in this context it comes off as archaic and 
elitist.  So be it.


 "A bad programmer create bugs when it edits its files...".

 And if people force you to write "it", it is quite reasonable 
 to wonder what else they strongly object to so you better just 
 stay silent. I really do try to cut down on the term "you"?


Quite!
Jun 10 2015
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
On Wednesday, 10 June 2015 at 18:41:56 UTC, Adam D. Ruppe wrote:

 On Wednesday, 10 June 2015 at 18:18:55 UTC, Ola Fosheim Grøstad 
 wrote:

 It's always a good idea to not go personal, but I think they 
 overdo it when you're not allowed to write "he" as a general 
 term because it is gender specific.


 That's actually a good idea, you might not have noticed it, but 
 I rarely use "he" alone as a general term and I notice it when 
 other people do. Little things like this in language can make a 
 difference in people's feelings and cause discomfort in the 
 environment.


Contrary to technical official definition, in REAL WORLD usage, 
"he" is BOTH a masuline AND a gender-neutral pronoun. A few 
occasional nutbags who deliberately ignore the "gender-neutral" 
possibility in order to promote their "you are all sexists" 
agenda is NO excuse for bowing to thier pressure.
Jun 10 2015
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Wednesday, 10 June 2015 at 20:14:10 UTC, Nick Sabalausky wrote:

 Contrary to technical official definition, in REAL WORLD usage, 
 "he" is BOTH a masuline AND a gender-neutral pronoun. A few 
 occasional nutbags who deliberately ignore the "gender-neutral" 
 possibility in order to promote their "you are all sexists" 
 agenda is NO excuse for bowing to thier pressure.


Personally I don't perceive he as ever being gender neutral(us 
native speaker). If I am trying to be gender neutral then I will 
use "they" or "that person" or "one". If some one did try to use 
he in a gender neutral context then I think it would sound weird 
to me.
Jun 10 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 11 June 2015 at 00:57:34 UTC, Tofu Ninja wrote:

 On Wednesday, 10 June 2015 at 20:14:10 UTC, Nick Sabalausky 
 wrote:

 Contrary to technical official definition, in REAL WORLD 
 usage, "he" is BOTH a masuline AND a gender-neutral pronoun. A 
 few occasional nutbags who deliberately ignore the 
 "gender-neutral" possibility in order to promote their "you 
 are all sexists" agenda is NO excuse for bowing to thier 
 pressure.


 Personally I don't perceive he as ever being gender neutral(us 
 native speaker). If I am trying to be gender neutral then I 
 will use "they" or "that person" or "one". If some one did try 
 to use he in a gender neutral context then I think it would 
 sound weird to me.


'he' has been a gender neutral pronoun for centuries, and as far 
as I'm aware this has its roots in latin using 'man'(vir?) as a 
gender neutral pronoun.
Jun 10 2015
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 11 June 2015 at 01:30:08 UTC, weaselcat wrote:

 'he' has been a gender neutral pronoun for centuries, and as 
 far as I'm aware this has its roots in latin using 'man'(vir?) 
 as a gender neutral pronoun.


I am just saying that personally it sounds odd to me to use it 
that way and I don't hear people use it that way either. In 
gender neutral contexts where you don't know the gender I almost 
always say/hear they/their. Maybe he losing its gender neutrality 
is a recent thing, I don't know. Maybe its just a thing with 
mid-westerners?
Jun 10 2015
parent David Gileadi <gileadis NSPMgmail.com> writes:
On 6/10/15 6:43 PM, Tofu Ninja wrote:

 On Thursday, 11 June 2015 at 01:30:08 UTC, weaselcat wrote:

 'he' has been a gender neutral pronoun for centuries, and as far as
 I'm aware this has its roots in latin using 'man'(vir?) as a gender
 neutral pronoun.


 I am just saying that personally it sounds odd to me to use it that way
 and I don't hear people use it that way either. In gender neutral
 contexts where you don't know the gender I almost always say/hear
 they/their. Maybe he losing its gender neutrality is a recent thing, I
 don't know. Maybe its just a thing with mid-westerners?


It does appear to be a recent thing, if you trust Wikipedia:

http://en.wikipedia.org/wiki/Gender-specific_and_gender-neutral_pronouns#Generic_he

Also the earlier section on "Historical and dialectal gender-neutral 
pronouns" is interesting: maybe we can start using "a" or "yo" as pronouns.
Jun 11 2015
prev sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 11/06/2015 2:30 AM, weaselcat wrote:

 On Thursday, 11 June 2015 at 00:57:34 UTC, Tofu Ninja wrote:

 On Wednesday, 10 June 2015 at 20:14:10 UTC, Nick Sabalausky wrote:

 Contrary to technical official definition, in REAL WORLD usage, "he"
 is BOTH a masuline AND a gender-neutral pronoun. A few occasional
 nutbags who deliberately ignore the "gender-neutral" possibility in
 order to promote their "you are all sexists" agenda is NO excuse for
 bowing to thier pressure.


 Personally I don't perceive he as ever being gender neutral(us native
 speaker). If I am trying to be gender neutral then I will use "they"
 or "that person" or "one". If some one did try to use he in a gender
 neutral context then I think it would sound weird to me.


 'he' has been a gender neutral pronoun for centuries, and as far as I'm
 aware this has its roots in latin using 'man'(vir?) as a gender neutral
 pronoun.


As far as I know, "he" was not historically gender neutral, but "man" 
used to be. In Old English, "man" was simply the suffix that meant 
"person" ("person" being a newer loan word), hence words like "chairman" 
and "foreman" are gender neutral (The rise of "chairperson" is feminism 
gone mad (or ignorant) -- she said). The Old English word for man was 
weiman (or werman), literally a male-person and was probably dropped as 
in some dialects it would likely be pronounced to similarly to "woman".

A...
Jun 12 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 12 June 2015 at 09:26:29 UTC, Alix Pexton wrote:

 On 11/06/2015 2:30 AM, weaselcat wrote:

 On Thursday, 11 June 2015 at 00:57:34 UTC, Tofu Ninja wrote:

 On Wednesday, 10 June 2015 at 20:14:10 UTC, Nick Sabalausky 
 wrote:

 Contrary to technical official definition, in REAL WORLD 
 usage, "he"
 is BOTH a masuline AND a gender-neutral pronoun. A few 
 occasional
 nutbags who deliberately ignore the "gender-neutral" 
 possibility in
 order to promote their "you are all sexists" agenda is NO 
 excuse for
 bowing to thier pressure.


 Personally I don't perceive he as ever being gender 
 neutral(us native
 speaker). If I am trying to be gender neutral then I will use 
 "they"
 or "that person" or "one". If some one did try to use he in a 
 gender
 neutral context then I think it would sound weird to me.


 'he' has been a gender neutral pronoun for centuries, and as 
 far as I'm
 aware this has its roots in latin using 'man'(vir?) as a 
 gender neutral
 pronoun.


 As far as I know, "he" was not historically gender neutral, but 
 "man" used to be. In Old English, "man" was simply the suffix 
 that meant "person" ("person" being a newer loan word), hence 
 words like "chairman" and "foreman" are gender neutral (The 
 rise of "chairperson" is feminism gone mad (or ignorant) -- she 
 said). The Old English word for man was weiman (or werman), 
 literally a male-person and was probably dropped as in some 
 dialects it would likely be pronounced to similarly to "woman".

 A...


"man" is still used as a gender neutral pronoun in German, 
however, for some reason it's frowned upon these days, just like 
"one" in English. It's considered "arrogant" and old fashioned, 
but it's effin useful and solves a lot of problems.

Mind you, decisions made by those who compile dictionaries and 
"standards" are not at all based on the reality of a given 
language. Double negation exists in English (and many other 
languages), but it's stigmati(s|z)ed as being "incorrect". The 
vote was 5 to 4 when this decision was made in England. The 
official reasoning behind it was that minus + minus = plus, i.e. 
"I don't have no money" would mean "I do have money", which is 
complete horsesh*t. Of course it means "I don't have money". The 
real reason, of course, was class snobbery and elitism: double 
negation was and still is commonly used in working class English 
in England (and the US, I think). Ironically enough, double 
negation is obligatory in standard French, while it is not used 
in colloquial French. This shows you how arbitrary these 
standards are. Don't take them too seriously, and don't start 
religious wars about some eggheads' decisions ;)

The same goes for "ain't". There's no reason why "ain't" should 
be "bad English". "I ain't got no money" is perfectly fine, 
although it might make the odd Oxbridge fellow cringe and spill 
his tea. But what the Dickens, old chap!
Jun 12 2015
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/12/2015 07:48 AM, Chris wrote:

 The same goes for "ain't". There's no reason why "ain't" should be "bad
 English". "I ain't got no money" is perfectly fine, although it might
 make the odd Oxbridge fellow cringe and spill his tea. But what the
 Dickens, old chap!


Yea, I'm fine with "ain't" being considered an actual word. Years ago, I 
used to hear a lot of "'Ain't' isn't a real word", but meh, it's used as 
a word, even the people who don't like it still know full-well exactly 
what it means, so...I ain't got a big problem with it :)

But there was one particular argument in favor of "ain't" that I never 
liked: "It's a contraction for 'are not'."

Well, no, it isn't a contraction for "are not" (maybe it originally was, 
I dunno). Because "I ain't going" vs "I are not going." So no, it may be 
a word, but it ain't a contraction for "are not".
Jun 12 2015
parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 12/06/2015 10:37 PM, Nick Sabalausky wrote:

 Yea, I'm fine with "ain't" being considered an actual word. Years ago, I
 used to hear a lot of "'Ain't' isn't a real word", but meh, it's used as
 a word, even the people who don't like it still know full-well exactly
 what it means, so...I ain't got a big problem with it :)

 But there was one particular argument in favor of "ain't" that I never
 liked: "It's a contraction for 'are not'."

 Well, no, it isn't a contraction for "are not" (maybe it originally was,
 I dunno). Because "I ain't going" vs "I are not going." So no, it may be
 a word, but it ain't a contraction for "are not".


It is a contraction of "are not" because it originates from a 
time/dialect where the verb to-be was conjugated differently than 
today's English. Many of the irregularities of to-be are ignored in 
international English which gives rise to dialects among ESL speakers 
that sound wrong but endearing (at least to my ears).

A...
Jun 14 2015
prev sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 12/06/2015 12:48 PM, Chris wrote:

 "man" is still used as a gender neutral pronoun in German, however, for
 some reason it's frowned upon these days, just like "one" in English.
 It's considered "arrogant" and old fashioned, but it's effin useful and
 solves a lot of problems.

 Mind you, decisions made by those who compile dictionaries and
 "standards" are not at all based on the reality of a given language.
 Double negation exists in English (and many other languages), but it's
 stigmati(s|z)ed as being "incorrect". The vote was 5 to 4 when this
 decision was made in England. The official reasoning behind it was that
 minus + minus = plus, i.e. "I don't have no money" would mean "I do have
 money", which is complete horsesh*t. Of course it means "I don't have
 money". The real reason, of course, was class snobbery and elitism:
 double negation was and still is commonly used in working class English
 in England (and the US, I think). Ironically enough, double negation is
 obligatory in standard French, while it is not used in colloquial
 French. This shows you how arbitrary these standards are. Don't take
 them too seriously, and don't start religious wars about some eggheads'
 decisions ;)

 The same goes for "ain't". There's no reason why "ain't" should be "bad
 English". "I ain't got no money" is perfectly fine, although it might
 make the odd Oxbridge fellow cringe and spill his tea. But what the
 Dickens, old chap!


I must be rare, cos I ain't posh n' well educated but I deplore the use 
of double negatives in English. I might be heard t'say "I ain't got n' 
money" (cos it be true) but in that case the "n'" is the local dialect 
contraction of "any". Other areas of the UK can't use the same excuse, 
maybe they got it from us but didn't understand what we were say'n, 
which is very common, but am more inclined to blame ignorance.

Don't know anything about double negative usage in French, but I do know 
that they are a way making super polite requests in Japanese.

Lets all not not stop arguing the minutia.

A...
Jun 14 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Sunday, 14 June 2015 at 09:38:02 UTC, Alix Pexton wrote:

 On 12/06/2015 12:48 PM, Chris wrote:

 "man" is still used as a gender neutral pronoun in German, 
 however, for
 some reason it's frowned upon these days, just like "one" in 
 English.
 It's considered "arrogant" and old fashioned, but it's effin 
 useful and
 solves a lot of problems.

 Mind you, decisions made by those who compile dictionaries and
 "standards" are not at all based on the reality of a given 
 language.
 Double negation exists in English (and many other languages), 
 but it's
 stigmati(s|z)ed as being "incorrect". The vote was 5 to 4 when 
 this
 decision was made in England. The official reasoning behind it 
 was that
 minus + minus = plus, i.e. "I don't have no money" would mean 
 "I do have
 money", which is complete horsesh*t. Of course it means "I 
 don't have
 money". The real reason, of course, was class snobbery and 
 elitism:
 double negation was and still is commonly used in working 
 class English
 in England (and the US, I think). Ironically enough, double 
 negation is
 obligatory in standard French, while it is not used in 
 colloquial
 French. This shows you how arbitrary these standards are. 
 Don't take
 them too seriously, and don't start religious wars about some 
 eggheads'
 decisions ;)

 The same goes for "ain't". There's no reason why "ain't" 
 should be "bad
 English". "I ain't got no money" is perfectly fine, although 
 it might
 make the odd Oxbridge fellow cringe and spill his tea. But 
 what the
 Dickens, old chap!


 I must be rare, cos I ain't posh n' well educated but I deplore 
 the use of double negatives in English. I might be heard t'say 
 "I ain't got n' money" (cos it be true) but in that case the 
 "n'" is the local dialect contraction of "any". Other areas of 
 the UK can't use the same excuse, maybe they got it from us but 
 didn't understand what we were say'n, which is very common, but 
 am more inclined to blame ignorance.

 Don't know anything about double negative usage in French, but 
 I do know that they are a way making super polite requests in 
 Japanese.

 Lets all not not stop arguing the minutia.

 A...


Then generations of music fans were baffled by lyrics like "I 
ain't got no money to show" (Double trouble), "I can't get no 
satisfaction". To use "any" ain't no better, because it still is 
a double negative. I'll give you Pinker's explanation:

"At this point, defenders of the standard are likely to pull out 
the notorious  double negative, as in I can't get no 
satisfaction. Logically speaking, the two negatives cancel each 
other out,
they teach; Mr. Jagger is actually saying that he is satisfied. 
The song should be entitled "I Can't Get Any Satisfaction." But 
this reasoning is not satisfactory. Hundreds of languages require 
their speakers to use a negative element somewhere within the 
"scope," as linguists call it, of a negated verb.

The so-called double negative, far from being a corruption, was
the norm in Chaucer's Middle English, and negation in standard 
French—as in Je ne sais pas, where ne and pas
are both negative—is a familiar contemporary example.
Come to think of it, Standard English is really no different. 
What do any, even, and at all mean in the following sentences?

I didn't buy any lottery tickets.
I didn't eat even a single French fry.
I didn't eat fried food at all today.

Clearly, not much: you can't use them alone, as the following 
strange sentences show:

I bought any lottery tickets.
I ate even a single French fry.
I ate fried food at all today.

What these words are doing is exactly what no is doing in 
nonstandard American English, such as in the equivalent
I didn't buy no lottery tickets—agreeing with the negated verb. 
The slim difference is that nonstandard English co-opted the word 
no as the agreement element,  whereas Standard English co-opted 
the word any ; aside from that, they are pretty much
translations. And one more point has to be made. In the grammar 
of standard English, a double negative does
not assert the corresponding affirmative. No one would dream of 
saying  I can't get no satisfaction out of the blue to boast that 
he easily attains contentment. There are circumstances in which 
one might use the construction to deny a preceding
negation in the discourse, but denying a negation is not the same 
as asserting an affirmative, and even then one could probably 
only use it by putting heavy stress on the negative
element, as in the following contrived example:

As hard as I try not to be smug about the misfortunes of my 
adversaries, I must admit that I can't get no satisfaction out of 
his tenure denial.

So the implication that use of the nonstandard form would lead to 
confusion is pure pedantry."

http://www.sp.uconn.edu/~sih01001/english/fall2007/TheLanguageMavens.pdf
Jun 16 2015
parent reply "Laeeth Isharc" <nospamlaeeth laeethnospam.laeeth.com> writes:
On Tuesday, 16 June 2015 at 08:54:01 UTC, Chris wrote:

 So the implication that use of the nonstandard form would lead 
 to confusion is pure pedantry."


Yes, indeed.

Much of the difficulty with discussions of language in the modern 
world comes from not making a distinction between its denotative 
and connotative aspects.  The former relates to what is actually 
being said, and the latter to all the other thoughts and 
impressions that are evoked by saying it in that way.

Modern people emphasize excessively the denotative aspects, 
whereas connotations do matter since - as the neuroscience tells 
us - there are subtle priming effects and there are consequences 
from shifting the brain into different modes.

That's perhaps also in part why people do care about syntax in 
computer languages, even though at one level anything precise 
might be felt to do the job.

Back to your point, many non-Western cultures have different 
kinds of speech according to the social context.  That's because 
wanting to do so is a human group thing, not a DWEM thing.  Of 
course in the past years there was a relaxation of standards of 
formality due to concerns over it creating a noxious and 
unwarranted exclusivity.  That may have been a good thing in some 
ways.  But I think every human group will ultimately need to 
retain distinctions between different registers of speaking and 
writing...
Jun 16 2015
parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 16 June 2015 at 16:34:59 UTC, Laeeth Isharc wrote:

 On Tuesday, 16 June 2015 at 08:54:01 UTC, Chris wrote:

 So the implication that use of the nonstandard form would lead 
 to confusion is pure pedantry."


 Yes, indeed.

 Much of the difficulty with discussions of language in the 
 modern world comes from not making a distinction between its 
 denotative and connotative aspects.  The former relates to what 
 is actually being said, and the latter to all the other 
 thoughts and impressions that are evoked by saying it in that 
 way.

 Modern people emphasize excessively the denotative aspects, 
 whereas connotations do matter since - as the neuroscience 
 tells us - there are subtle priming effects and there are 
 consequences from shifting the brain into different modes.

 That's perhaps also in part why people do care about syntax in 
 computer languages, even though at one level anything precise 
 might be felt to do the job.

 Back to your point, many non-Western cultures have different 
 kinds of speech according to the social context.  That's 
 because wanting to do so is a human group thing, not a DWEM 
 thing.  Of course in the past years there was a relaxation of 
 standards of formality due to concerns over it creating a 
 noxious and unwarranted exclusivity.  That may have been a good 
 thing in some ways.  But I think every human group will 
 ultimately need to retain distinctions between different 
 registers of speaking and writing...


My point was not so much formal vs non-formal speech but the fact 
that a lot of these decisions are linguistically (not socially) 
arbitrary, often counter intuitive, and made by people who want 
to draw a line between their own (privileged) group and others 
they do not deem worthy of the same privileges. Again in the 
words of Pinker:

"Perhaps most importantly, since prepscriptive rules are so 
psychologically unnatural that only those with access to the 
right schooling can abide by them, they serve as shibboleths, 
differentiating the elite from the rabble."

I couldn't put it better myself. There's no linguistic reason why 
double negatives shouldn't be in the standard varieties of 
English. (Greek logic != linguistic logic)
Jun 16 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 10 June 2015 at 14:29:51 UTC, Thiez wrote:

 On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 One big difference between the D community and other 
 languages' communities is is that D people keep criticizing 
 the language and see every little flaw in every little corner, 
 which is good and which is why D is the way it is.


 Or perhaps D simply has more flaws to criticize.


How can you tell that e.g. Nim has less flaws when it's still so 
young? It's too early to tell.


 On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 Other languages' communities are more like "This is theeeeeee
 language of the future, it's super-duper, no question asked,
 none permitted either!"


 Perhaps you are depicting other communities as a bunch of 
 group-think hipsters because you are insecure about your own 
 community?

 Look, I can make baseless accusations too. Wouldn't you agree 
 it would be nicer (and more effective, I imagine) to promote 
 your community by calling attention rather to its positive 
 qualities, rather than demonizing other communities? Especially 
 when your negative portrayals of other communities are not 
 accompanied by any evidence?

 I'm sure you're a smart person and will for each of the 
 communities in question be able to find evidence of at least 
 one person who at some point in time acted in the way you 
 suggested. Of course such a thing would not prove that the 
 behaviour is representative of the community, so please don't.


I've been following post-C(++) programming languages for quite a 
while now. Back in the day Java was a big thing, and Python was 
also hip. Then we had Ruby and whatnot. The base line would 
always be "it's a cool language, it's the future" and flaws would 
hardly ever be mentioned, critical voices silenced. All the 
benchmarking tricks used by the Java community to make people 
believe it's as fast as native code - while you know from your 
own experience that it's not - are just one example. Ah, and 
there was Ajax, remember? How's jQuery doing, by the way? I've 
used some of these technologies and none of them would live up to 
my expectations. But the pattern is always the same "It's theeee 
thing, wow, a must-have!" Sorry, but whenever I hear a language 
is (almost) perfect and theee way to go, I grow suspicious. If 
all communities are as critical as D's, why then do we have so 
much mediocre technology out there?

I am interested in Nim and welcome it. But it's too early to say 
whether it's good or mediocre. I wonder, though, when you look 
Nim up on Wikipedia it states:

Influenced by
Ada, Modula-3, Lisp, C++, Object Pascal, Python, Oberon

Did they really never get any inspiration from D?? I wonder. 
Seems a bit odd, but well.
Jun 10 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 10 June 2015 at 15:37:46 UTC, Chris wrote:

 I am interested in Nim and welcome it. But it's too early to 
 say whether it's good or mediocre.


Yeah, I think it would be nice if one could change the culture of 
programming so that people easily could combine any 2 languages 
in the same project. But that takes either significant 
creator-goodwill/cooperation or platforms like .NET/JVM. I could 
see myself wanting to do some things in "Prolog", some things in 
"Lisp" and some things in "C". Today that takes too much FFI work.

A problem that both Nim and D share is that they aim broad. I 
think that makes it a harder sell as that tend to make the 
language more complex and unpolished. I think most languages that 
gain traction by starting focused. C was very focused on OS dev. 
C++ piggy-backed on that by adding abstractions. Php was very 
focused on web scripting. Perl on text processing. Erlang on 
fault tolerance. Smalltalk on interactive programming. Pascal 
piggybacked on Algol going too big IIRC.  Turbo Pascal's success 
was IDE focused IMO.


  I wonder, though, when you look Nim up on Wikipedia it states:

 Influenced by
 Ada, Modula-3, Lisp, C++, Object Pascal, Python, Oberon

 Did they really never get any inspiration from D?? I wonder. 
 Seems a bit odd, but well.


Probably related to the main creator's programming-experience, 
but as far as credits go one should really credit the first 
language/author to bring about a concept. (e.g. Lisp, Simula, 
BCPL etc)
Jun 10 2015
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 10 June 2015 at 16:02:36 UTC, Ola Fosheim Grøstad 
wrote:

 Yeah, I think it would be nice if one could change the culture 
 of programming so that people easily could combine any 2 
 languages in the same project.


But shouldn't there be one language that's right for everyone?


(BTW I wanted to use that line in my dconf talk and forgot to!)
Jun 10 2015
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Wednesday, 10 June 2015 at 16:02:36 UTC, Ola Fosheim Grøstad 
wrote:

 Probably related to the main creator's programming-experience, 
 but as far as credits go one should really credit the first 
 language/author to bring about a concept. (e.g. Lisp, Simula, 
 BCPL etc)


I wonder why Walter was inspired to add modules to D, Walter?
Jun 10 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/10/2015 9:22 AM, Joakim wrote:

 I wonder why Walter was inspired to add modules to D, Walter?


It never occurred to me not to. Modules are hardly an innovative idea. It'd be 
like not supporting the + operator.
Jun 10 2015
prev sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 10 June 2015 at 16:02:36 UTC, Ola Fosheim Grøstad 
wrote:

 Yeah, I think it would be nice if one could change the culture 
 of programming so that people easily could combine any 2 
 languages in the same project. But that takes either 
 significant creator-goodwill/cooperation or platforms like 
 .NET/JVM. I could see myself wanting to do some things in 
 "Prolog", some things in "Lisp" and some things in "C". Today 
 that takes too much FFI work.


Wasn't LLVM supposed to solve that, being a "virtual machine" for 
compilation to low level native code?
Jun 10 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Wednesday, 10 June 2015 at 16:22:51 UTC, Idan Arye wrote:

 Wasn't LLVM supposed to solve that, being a "virtual machine" 
 for compilation to low level native code?


May still be possible, Apple just announced that the default 
format to submit apps for iOS will be bitcode from now on, which 
people are speculating is some form of llvm bitcode:

http://arstechnica.com/apple/2015/06/app-thinning-will-be-a-major-boon-for-8gb-and-16gb-iphones-and-ipads/

Apple will then compile the bitcode for you on their servers, 
before sending the final binary to users.
Jun 10 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 10 June 2015 at 16:34:40 UTC, Joakim wrote:

 Apple will then compile the bitcode for you on their servers, 
 before sending the final binary to users.


Thanks for the link. That's pretty interesting. I suspect it 
means they plan to change CPUs in 2 years or so. But it makes me 
feel a bit uneasy that Apple get to control the program at that 
level.
Jun 10 2015
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 10 June 2015 at 16:34:40 UTC, Joakim wrote:

 On Wednesday, 10 June 2015 at 16:22:51 UTC, Idan Arye wrote:

 Wasn't LLVM supposed to solve that, being a "virtual machine" 
 for compilation to low level native code?


 May still be possible, Apple just announced that the default 
 format to submit apps for iOS will be bitcode from now on, 
 which people are speculating is some form of llvm bitcode:

 http://arstechnica.com/apple/2015/06/app-thinning-will-be-a-major-boon-for-8gb-and-16gb-iphones-and-ipads/

 Apple will then compile the bitcode for you on their servers, 
 before sending the final binary to users.


Apple is catching up with Microsoft on Windows 8.x/10 here.

http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-Sollich-Inside-Compiler-in-the-Cloud-and-MDIL

http://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native

--
Paulo
Jun 10 2015
prev sibling next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/10/2015 09:34 AM, Joakim wrote:

 On Wednesday, 10 June 2015 at 16:22:51 UTC, Idan Arye wrote:

 Wasn't LLVM supposed to solve that, being a "virtual machine" for
 compilation to low level native code?


 May still be possible, Apple just announced that the default format to
 submit apps for iOS will be bitcode from now on, which people are
 speculating is some form of llvm bitcode:

 http://arstechnica.com/apple/2015/06/app-thinning-will-be-a-major-boon-for-8gb-and-16gb-iphones-and-ipads/


 Apple will then compile the bitcode for you on their servers, before
 sending the final binary to users.


I wonder whether they will inject code for Natural Security of Apple 
users. :p

Ali
Jun 10 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-06-10 18:34, Joakim wrote:


 May still be possible, Apple just announced that the default format to
 submit apps for iOS will be bitcode from now on, which people are
 speculating is some form of llvm bitcode:


I'm pretty sure they mentioned it was LLVM IR on the "Platform, State of 
the Union" talk.

-- 
/Jacob Carlborg
Jun 11 2015
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 11/06/2015 3:37 a.m., Chris wrote:

 On Wednesday, 10 June 2015 at 14:29:51 UTC, Thiez wrote:

 On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 One big difference between the D community and other languages'
 communities is is that D people keep criticizing the language and see
 every little flaw in every little corner, which is good and which is
 why D is the way it is.


 Or perhaps D simply has more flaws to criticize.


 How can you tell that e.g. Nim has less flaws when it's still so young?
 It's too early to tell.


 On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 Other languages' communities are more like "This is theeeeeee
 language of the future, it's super-duper, no question asked,
 none permitted either!"


 Perhaps you are depicting other communities as a bunch of group-think
 hipsters because you are insecure about your own community?

 Look, I can make baseless accusations too. Wouldn't you agree it would
 be nicer (and more effective, I imagine) to promote your community by
 calling attention rather to its positive qualities, rather than
 demonizing other communities? Especially when your negative portrayals
 of other communities are not accompanied by any evidence?

 I'm sure you're a smart person and will for each of the communities in
 question be able to find evidence of at least one person who at some
 point in time acted in the way you suggested. Of course such a thing
 would not prove that the behaviour is representative of the community,
 so please don't.


 I've been following post-C(++) programming languages for quite a while
 now. Back in the day Java was a big thing, and Python was also hip. Then
 we had Ruby and whatnot. The base line would always be "it's a cool
 language, it's the future" and flaws would hardly ever be mentioned,
 critical voices silenced. All the benchmarking tricks used by the Java
 community to make people believe it's as fast as native code - while you
 know from your own experience that it's not - are just one example. Ah,
 and there was Ajax, remember? How's jQuery doing, by the way? I've used
 some of these technologies and none of them would live up to my
 expectations. But the pattern is always the same "It's theeee thing,
 wow, a must-have!" Sorry, but whenever I hear a language is (almost)
 perfect and theee way to go, I grow suspicious. If all communities are
 as critical as D's, why then do we have so much mediocre technology out
 there?

 I am interested in Nim and welcome it. But it's too early to say whether
 it's good or mediocre. I wonder, though, when you look Nim up on
 Wikipedia it states:

 Influenced by
 Ada, Modula-3, Lisp, C++, Object Pascal, Python, Oberon

 Did they really never get any inspiration from D?? I wonder. Seems a bit
 odd, but well.


The biggest difference between the D community in general and other 
communities is actually quite simple.

Experience.

That's right. As mentioned we accept bugs, we accept issues. Discuss 
them at length and fix them when a good solution is found. Not only that 
but we look for problems to fix.
This is the mentality of a good software engineer. One who doesn't care 
about their own pride or ego but genuinely wants to make good code.

In a lot of ways this makes us the best developers on the planet. It 
would explain a lot, including how other language communities snob us 
yet we look at them for ideas.

Just a thought.
Jun 10 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 03:04:50 UTC, Rikki Cattermole wrote:

 The biggest difference between the D community in general and 
 other communities is actually quite simple.

 Experience.


Indeed! The world has never seen a more experienced collection of 
freshmen language designers. Theory does not apply.

Rust and Go are doomed.


 That's right. As mentioned we accept bugs, we accept issues.


Submit and accept, no regrets.


 Discuss them at length and fix them when a good solution is 
 found.


A ground breaking GC will emerge from the synthesis of the 
unsurpassable number of endless GC debates. That is the 
sanctimony of meritocracy.

A non-breaking solution will eventually be found. Time is no 
issue in such an important matter. We just wait and a solution 
will emerge, through discussions based on pure experience.


 Not only that but we look for problems to fix.
 This is the mentality of a good software engineer. One who 
 doesn't care about their own pride or ego but genuinely wants 
 to make good code.


This community is the UNICEF of programming. We are all meek and 
humble individuals, divine servants of humanity.

People in these forums all express gratitude when they are on the 
loosing end of a technical debate. Nobody go silent or resort to 
rhetorical excesses. Ever. We are all grateful for being proven 
wrong, because that is how we become better programmers.


 In a lot of ways this makes us the best developers on the 
 planet. It would explain a lot, including how other language 
 communities snob us yet we look at them for ideas.


Indeed, we never snob anyone, and they all snob us. Especially 
the ignorant C++ community that never mentions us.
Jun 11 2015
next sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
On Thursday, 11 June 2015 at 07:08:02 UTC, Ola Fosheim Grøstad 
wrote:

 A ground breaking GC will emerge from the synthesis of the 
 unsurpassable number of endless GC debates. That is the 
 sanctimony of meritocracy.


actually making a good GC for D is difficult because the only 
type of barrier you can use it hardware protection faults. The 
performance dropoff isn't _that_ bad from what I've read in 
various papers.

I should have an article up in a few weeks detailing my summer 
research project on this.

bye.
Jun 11 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 11 June 2015 at 07:11:33 UTC, rsw0x wrote:

 On Thursday, 11 June 2015 at 07:08:02 UTC, Ola Fosheim Grøstad 
 wrote:

 A ground breaking GC will emerge from the synthesis of the 
 unsurpassable number of endless GC debates. That is the 
 sanctimony of meritocracy.


 actually making a good GC for D is difficult because the only 
 type of barrier you can use it hardware protection faults. The 
 performance dropoff isn't _that_ bad from what I've read in 
 various papers.

 I should have an article up in a few weeks detailing my summer 
 research project on this.

 bye.


It IS that bad, and any paper that tell you otherwise is lying to 
you.
Jun 11 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
On Thursday, 11 June 2015 at 07:13:10 UTC, deadalnix wrote:

 On Thursday, 11 June 2015 at 07:11:33 UTC, rsw0x wrote:

 On Thursday, 11 June 2015 at 07:08:02 UTC, Ola Fosheim Grøstad 
 wrote:

 A ground breaking GC will emerge from the synthesis of the 
 unsurpassable number of endless GC debates. That is the 
 sanctimony of meritocracy.


 actually making a good GC for D is difficult because the only 
 type of barrier you can use it hardware protection faults. The 
 performance dropoff isn't _that_ bad from what I've read in 
 various papers.

 I should have an article up in a few weeks detailing my summer 
 research project on this.

 bye.


 It IS that bad, and any paper that tell you otherwise is lying 
 to you.


after extensive testing I found a hardware protection fault + 
mprotect to take 2000nsecs on every hardware I tested, the only 
time you need them active is during a concurrent mark and sweep. 
I'll find out I guess.

Boehm's GC uses this and regularly kept up(~5-10%) with 
essentially all of the top of the line GCs in all the papers I 
read.
Jun 11 2015
parent reply "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 11 June 2015 at 07:15:31 UTC, rsw0x wrote:

 Boehm's GC uses this and regularly kept up(~5-10%) with 
 essentially all of the top of the line GCs in all the papers I 
 read.


Ah, so you only read papers about very bad GCs, that explains it. 
;)
Jun 11 2015
parent "rsw0x" <anonymous anonymous.com> writes:
On Thursday, 11 June 2015 at 07:45:49 UTC, thedeemon wrote:

 On Thursday, 11 June 2015 at 07:15:31 UTC, rsw0x wrote:

 Boehm's GC uses this and regularly kept up(~5-10%) with 
 essentially all of the top of the line GCs in all the papers I 
 read.


 Ah, so you only read papers about very bad GCs, that explains 
 it. ;)


I don't consider immix, schism, or C4 to be a bad GCs.
but maybe we have different definitions.
Jun 11 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 07:11:33 UTC, rsw0x wrote:

 actually making a good GC for D is difficult because the only 
 type of barrier you can use it hardware protection faults. The 
 performance dropoff isn't _that_ bad from what I've read in 
 various papers.

 I should have an article up in a few weeks detailing my summer 
 research project on this.


That sounds like an interesting project!

I think it is possible to modify the language slightly and make 
(to me) acceptable restrictions on where GC is allowed to get 
better performance. Still, I am sure you will be able to find 
some new opportunities in your research project.

I am looking forward to see what you come up with.
Jun 11 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 11 June 2015 at 07:08:02 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 11 June 2015 at 03:04:50 UTC, Rikki Cattermole 
 wrote:

 The biggest difference between the D community in general and 
 other communities is actually quite simple.

 Experience.


 Indeed! The world has never seen a more experienced collection 
 of freshmen language designers. Theory does not apply.

 Rust and Go are doomed.


Now, now. It is true that bad and frustrating experience with 
other languages drove me (and probably others) to D. D is open to 
suggestions, while other languages still live by the "one size 
fits all" mentality. std.allocator is a good example of trying to 
offer a variety of different memory models. What's wrong with 
that?

People here often request features you can only ask for after 
years of programming experience. This shows that there is a lot 
of experience in the D community. Without experience D wouldn't 
be where it is, having only limited resources.


 That's right. As mentioned we accept bugs, we accept issues.


 Submit and accept, no regrets.


 Discuss them at length and fix them when a good solution is 
 found.


 A ground breaking GC will emerge from the synthesis of the 
 unsurpassable number of endless GC debates. That is the 
 sanctimony of meritocracy.

 A non-breaking solution will eventually be found. Time is no 
 issue in such an important matter. We just wait and a solution 
 will emerge, through discussions based on pure experience.


 Not only that but we look for problems to fix.
 This is the mentality of a good software engineer. One who 
 doesn't care about their own pride or ego but genuinely wants 
 to make good code.


 This community is the UNICEF of programming. We are all meek 
 and humble individuals, divine servants of humanity.


Just trying to create the best tool possible for our own daily 
tasks.


 People in these forums all express gratitude when they are on 
 the loosing end of a technical debate. Nobody go silent or 
 resort to rhetorical excesses. Ever. We are all grateful for 
 being proven wrong, because that is how we become better 
 programmers.


But we keep coming back. So it cannot be that bad ;)


 In a lot of ways this makes us the best developers on the 
 planet. It would explain a lot, including how other language 
 communities snob us yet we look at them for ideas.


 Indeed, we never snob anyone, and they all snob us. Especially 
 the ignorant C++ community that never mentions us.


Because this hurts some people. The D crowd doesn't snob other 
languages, in fact, people here often point at features of other 
languages saying "Da', can I have this, pleeeeeze?". All most of 
us do is to point out the strengths of D when ever the occasion 
arises, trying to convince people to at least give it a try. Of 
course it can be annoying when D is snobbed at while its features 
are being ripped.

Talking about UNICEF, feel free to be a humble servant of 
humani-D. The more the merrier!
Jun 11 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 11 June 2015 at 09:14:00 UTC, Chris wrote:

 Because this hurts some people. The D crowd doesn't snob other 
 languages, in fact, people here often point at features of 
 other languages saying "Da', can I have this, pleeeeeze?".


http://forum.dlang.org/thread/mki78k$6k5$1 digitalmars.com?page=8#post-cnprllcbxwinzclvwtib:40forum.dlang.org
Jun 11 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 09:14:00 UTC, Chris wrote:

 Now, now. It is true that bad and frustrating experience with 
 other languages drove me (and probably others) to D.


Suggesting that a language like D is based on experience in 
comparison to Go is... not right... given the experienced 
language designers behind Go.

If experience is key, then Go wins.


 People here often request features you can only ask for after 
 years of programming experience. This shows that there is a lot 
 of experience in the D community. Without experience D wouldn't 
 be where it is, having only limited resources.


Language designers that design more than one language tend to 
make smaller and tighter languages as they gain design experience 
and get better at delegating 
nice-to-have-but-not-essential-features to libraries. Features 
have a higher cost than initial implementation.

Walter has been more open to feature suggestions than many other 
designers, and implemented them in a timely fashion, that is 
true. And that can be both a good thing and a bad thing, but 
obviously engaging and fun from a community point of view.

The process around Go is very closed. So not fun. Rust is 
inbetween.


 Just trying to create the best tool possible for our own daily 
 tasks.


Just like everybody else?


 But we keep coming back. So it cannot be that bad ;)


;o)


 Indeed, we never snob anyone, and they all snob us. Especially 
 the ignorant C++ community that never mentions us.


 Because this hurts some people. The D crowd doesn't snob other 
 languages, in fact, people here often point at features of


I see jabs at other languages, especially the ones that is 
stealing attention from D: Rust, Go, C++… I guess it is all 
natural,  but it can be perceived as "envy" by outsiders, and 
there is no advantage to it.

I really wish people would stop complaining about other languages 
having the same features as D without giving credit. It is 
impossible to figure out exactly where ideas from features come 
from, but most features predate even C++ if being first is the 
main point.

The hard part about designing an imperative language is not the 
individual features, the palette is given. The hard part is 
turning it into beautiful whole that is greater than the sum of 
the parts. And that is important, but difficult (or impossible) 
to achieve.

It is kinda like music, I sometimes create a melody that I feel I 
have heard something similar to, but I cannot pin it down to 
anything specific. So phrases of the melody might be things I 
have picked up. However, if we go for novelty the roots for 
musical elements might go 300 years back or more. Far beyond my 
knowledge horizon.

A month ago I made a poptune-sketch I kinda find catchy, but 
familiar. But which tune is it familiar to? Who should I credit? 
Maybe you can help me out?

https://soundcloud.com/bambinella/anad-dreamer-sketch
Jun 11 2015
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 11 June 2015 at 10:17:26 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 11 June 2015 at 09:14:00 UTC, Chris wrote:

 Now, now. It is true that bad and frustrating experience with 
 other languages drove me (and probably others) to D.


 Suggesting that a language like D is based on experience in 
 comparison to Go is... not right... given the experienced 
 language designers behind Go.

 If experience is key, then Go wins.


 People here often request features you can only ask for after 
 years of programming experience. This shows that there is a 
 lot of experience in the D community. Without experience D 
 wouldn't be where it is, having only limited resources.


 Language designers that design more than one language tend to 
 make smaller and tighter languages as they gain design 
 experience and get better at delegating 
 nice-to-have-but-not-essential-features to libraries. Features 
 have a higher cost than initial implementation.

 Walter has been more open to feature suggestions than many 
 other designers, and implemented them in a timely fashion, that 
 is true. And that can be both a good thing and a bad thing, but 
 obviously engaging and fun from a community point of view.

 The process around Go is very closed. So not fun. Rust is 
 inbetween.


 Just trying to create the best tool possible for our own daily 
 tasks.


 Just like everybody else?


 But we keep coming back. So it cannot be that bad ;)


 ;o)


 Indeed, we never snob anyone, and they all snob us. 
 Especially the ignorant C++ community that never mentions us.


 Because this hurts some people. The D crowd doesn't snob other 
 languages, in fact, people here often point at features of


 I see jabs at other languages, especially the ones that is 
 stealing attention from D: Rust, Go, C++… I guess it is all 
 natural,  but it can be perceived as "envy" by outsiders, and 
 there is no advantage to it.

 I really wish people would stop complaining about other 
 languages having the same features as D without giving credit. 
 It is impossible to figure out exactly where ideas from 
 features come from, but most features predate even C++ if being 
 first is the main point.

 The hard part about designing an imperative language is not the 
 individual features, the palette is given. The hard part is 
 turning it into beautiful whole that is greater than the sum of 
 the parts. And that is important, but difficult (or impossible) 
 to achieve.

 It is kinda like music, I sometimes create a melody that I feel 
 I have heard something similar to, but I cannot pin it down to 
 anything specific. So phrases of the melody might be things I 
 have picked up. However, if we go for novelty the roots for 
 musical elements might go 300 years back or more. Far beyond my 
 knowledge horizon.

 A month ago I made a poptune-sketch I kinda find catchy, but 
 familiar. But which tune is it familiar to? Who should I 
 credit? Maybe you can help me out?

 https://soundcloud.com/bambinella/anad-dreamer-sketch


I have the same problem when composing. Some things sound vaguely 
familiar but I cannot put my finger on it. Usually I don't follow 
an idea that somehow sounds familiar.

In your case, the song reminds me of:

Wouldn't It Be Good - Nik Kershaw

https://www.youtube.com/watch?v=AYMAtbq0bjY

(God, I'm so old!) :-)
Jun 11 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 10:52:06 UTC, Chris wrote:

 vaguely familiar but I cannot put my finger on it. Usually I 
 don't follow an idea that somehow sounds familiar.


Well, in this case it might sound familiar to me because it is 
based manipulated sample of another tune I made... But I cannot 
know for sure ;)


 In your case, the song reminds me of:

 Wouldn't It Be Good - Nik Kershaw

 https://www.youtube.com/watch?v=AYMAtbq0bjY

 (God, I'm so old!) :-)


That's not all that old... (hrmph!) But I don't see the 
resemblance so it's not from there, if it is from anywhere 
outside my own head.
Jun 11 2015
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/11/2015 06:52 AM, Chris wrote:

 In your case, the song reminds me of:

 Wouldn't It Be Good - Nik Kershaw

 https://www.youtube.com/watch?v=AYMAtbq0bjY

 (God, I'm so old!) :-)


Oh man, that takes me back. 80's had the best pop music, IMHO. Miss that 
stuff. Although, I still have trouble accepting anything from that 
decade as "old", but maybe that just dates me too ;)
Jun 11 2015
parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 11 June 2015 at 16:14:46 UTC, Nick Sabalausky wrote:

 On 06/11/2015 06:52 AM, Chris wrote:

 In your case, the song reminds me of:

 Wouldn't It Be Good - Nik Kershaw

 https://www.youtube.com/watch?v=AYMAtbq0bjY

 (God, I'm so old!) :-)


 Oh man, that takes me back. 80's had the best pop music, IMHO. 
 Miss that stuff. Although, I still have trouble accepting 
 anything from that decade as "old", but maybe that just dates 
 me too ;)


https://youtu.be/VjNVPO8ff84 :3
https://youtu.be/bJDY5zTiWUk maybe this too(?)
Jun 11 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 20:14:24 UTC, Kagamin wrote:

 On Thursday, 11 June 2015 at 16:14:46 UTC, Nick Sabalausky 
 wrote:
 https://youtu.be/VjNVPO8ff84 :3
 https://youtu.be/bJDY5zTiWUk maybe this too(?)


Nono, the 80's was more like this:

https://youtu.be/Az_GCJnXAI0
https://youtu.be/PN7dd2fW3OQ
https://youtu.be/Ug8WeZyTxXg
https://youtu.be/drGeLouMm6s
Jun 11 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 11 June 2015 at 20:44:52 UTC, Ola Fosheim Grøstad 
wrote:

 Nono, the 80's was more like this:

 https://youtu.be/Az_GCJnXAI0
 https://youtu.be/PN7dd2fW3OQ
 https://youtu.be/Ug8WeZyTxXg
 https://youtu.be/drGeLouMm6s


Ouch, guess will stick with modern art -_-
Jun 11 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 21:53:57 UTC, Kagamin wrote:

 Ouch, guess will stick with modern art -_-


The modern art of early 80s pop would be Yello and Art of Noise. 
Music with a at-the-time new sample-based sound image heavily 
based on these expensive beasts:

http://www.synthtopia.com/content/2013/10/23/buy-boris-blanks-yello-fairlight-cmi-iii/

You probably could replace this with an iPhone today...
Jun 11 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 11 June 2015 at 20:44:52 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 11 June 2015 at 20:14:24 UTC, Kagamin wrote:

 On Thursday, 11 June 2015 at 16:14:46 UTC, Nick Sabalausky 
 wrote:
 https://youtu.be/VjNVPO8ff84 :3
 https://youtu.be/bJDY5zTiWUk maybe this too(?)


 Nono, the 80's was more like this:

 https://youtu.be/Az_GCJnXAI0
 https://youtu.be/PN7dd2fW3OQ
 https://youtu.be/Ug8WeZyTxXg
 https://youtu.be/drGeLouMm6s


Here is a nice documentary about the 80s : 
https://www.youtube.com/watch?v=bS5P_LAqiVg
Jun 11 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/11/2015 06:35 PM, deadalnix wrote:

 On Thursday, 11 June 2015 at 20:44:52 UTC, Ola Fosheim Grøstad wrote:

 On Thursday, 11 June 2015 at 20:14:24 UTC, Kagamin wrote:

 https://youtu.be/VjNVPO8ff84 :3
 https://youtu.be/bJDY5zTiWUk maybe this too(?)






Never heard those before, those are really good!

Some of my favorite 80's-ish sounding Japanese stuff:

https://youtu.be/WL2hBFhyo6Q (Anzen Chitai: Jirettai)
https://youtu.be/ZY_h_bW8CK0 (Anzen Chitai: Suki Sa)
http://www.dailymotion.com/video/x2pz4h_ai-yori-aoshi-enishi-ending-1_news 
(The Indigo - I Do!)
https://youtu.be/p6Q9gtBmZK8 (Yume no Nake e)
https://youtu.be/y0N3w90Hmh0#t=3m10s (TM Revolution: Light My Fire)

Some other J favorites, but these aren't 80's-ish:

https://youtu.be/7E9ycq5ZXD0 (Kotoko: Meconopsis)
https://youtu.be/bimJUWROSIk (Kotoko: Uzu-Maki)
https://youtu.be/POQVWetuNv8#t=16m35s (TM Revolution: Timeless Mobius Rover)
https://youtu.be/0Nd5Ce_RXbI (Namie Amuro: Come My Way)
https://youtu.be/xFqhyUHicQU (Yoko Kanno & Origa: Inner Universe)
https://youtu.be/baUY9LFlYh0 (<-- It's like audio/visual crack, can't 
turn away...)
https://youtu.be/OjkvQzWBpsA (Blood+ OP1)
https://youtu.be/5hkA2ivm4wU (Madoka Magica ED2)
https://vimeo.com/67644299 (Aira Yuhki: Blue sky, True sky)

'Course with this stuff, I could keep listing awesome ones all day, like 
just about every opening/closing for Noein, Inuyasha, Scientific 
Railgun, K-On, Nadia, Nana and Shinichirou Watanabe's shows, every 
opening for Pani Poni Dash, xxxHolic, Luck Star OP, damn near everything 
in Project Diva (both F and F2 are like digital crack), anything off 
Kotoko's "Glass no Kaze" and "Epsilon no Fune" albums, and a whole ton 
of others.


 Nono, the 80's was more like this:

 https://youtu.be/Az_GCJnXAI0
 https://youtu.be/PN7dd2fW3OQ
 https://youtu.be/Ug8WeZyTxXg
 https://youtu.be/drGeLouMm6s




Banned in the US: "Public Image Limited - This Is Not A Love Song" and 
"SABRINA - Boys (Video Original) - HD."

Those other two are absolutely wild though. Hilarious. :)


 Here is a nice documentary about the 80s :
 https://www.youtube.com/watch?v=bS5P_LAqiVg


Wow, just watched the first minute, that's freaking sweet! Definitely 
gonna watch the rest of that later.
Jun 12 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 12 June 2015 at 19:16:39 UTC, Nick Sabalausky wrote:

 Banned in the US: "Public Image Limited - This Is Not A Love 
 Song" and "SABRINA - Boys (Video Original) - HD."


Banned? Oh well, Lydon of Sex Pistols is an anarchist and Sabrina 
shows of her tits with a wardrobe malfunction. I guess that 
explains it well enough.
Jun 12 2015
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/12/2015 03:58 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 12 June 2015 at 19:16:39 UTC, Nick Sabalausky wrote:

 Banned in the US: "Public Image Limited - This Is Not A Love Song" and
 "SABRINA - Boys (Video Original) - HD."


 Banned? Oh well, Lydon of Sex Pistols is an anarchist and Sabrina shows
 of her tits with a wardrobe malfunction. I guess that explains it well
 enough.


Well, "banned", "blocked by youtube for copyright reasons", whatever ;)
Jun 12 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 12 June 2015 at 19:16:39 UTC, Nick Sabalausky wrote:

 Here is a nice documentary about the 80s :
 https://www.youtube.com/watch?v=bS5P_LAqiVg


 Wow, just watched the first minute, that's freaking sweet! 
 Definitely gonna watch the rest of that later.


The historical accuracy is indeed striking :)
Jun 12 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/11/2015 3:52 AM, Chris wrote:

 https://www.youtube.com/watch?v=AYMAtbq0bjY

 (God, I'm so old!) :-)


There's no business like compiler business:

https://www.youtube.com/watch?v=inzhNkQENOs

I'm in the compiler business:

https://www.youtube.com/watch?v=DwIyClDuBgo
Jun 11 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-06-12 01:52, Walter Bright wrote:


 I'm in the compiler business:

 https://www.youtube.com/watch?v=DwIyClDuBgo


You're in the Empire business as well ;) Or was.

-- 
/Jacob Carlborg
Jun 12 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 11 June 2015 at 10:17:26 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 11 June 2015 at 09:14:00 UTC, Chris wrote:

 Now, now. It is true that bad and frustrating experience with 
 other languages drove me (and probably others) to D.


 Suggesting that a language like D is based on experience in 
 comparison to Go is... not right... given the experienced 
 language designers behind Go.

 If experience is key, then Go wins.


heavily disagree honestly.
Ken Thompson - B?
Rob Pike - Limbo? Joking?
Jun 11 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 10:52:08 UTC, weaselcat wrote:

 heavily disagree honestly.
 Ken Thompson - B?
 Rob Pike - Limbo? Joking?


Not your kind of experience? But still experience...

So there is a limit to how far experience can take you.

Anyway, language designers that do multiple languages on their 
own accord appears to stay within the same paradigm. Kind of like 
an artist trying to perfect the aesthetics of their original 
piece. So if you don't like the original, you'll probably not 
like the sequel either...
Jun 11 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 11 June 2015 at 10:17:26 UTC, Ola Fosheim Grøstad 
wrote:

 People here often request features you can only ask for after 
 years of programming experience. This shows that there is a 
 lot of experience in the D community. Without experience D 
 wouldn't be where it is, having only limited resources.


 Language designers that design more than one language tend to 
 make smaller and tighter languages as they gain design 
 experience and get better at delegating 
 nice-to-have-but-not-essential-features to libraries.


Then brainfuck wins.
Jun 11 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 11:20:12 UTC, Kagamin wrote:

 Then brainfuck wins.


Always.
Jun 11 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/11/2015 07:31 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 11 June 2015 at 11:20:12 UTC, Kagamin wrote:

 Then brainfuck wins.


 Always.


It *is* very fun to implement. I'm more partial to this one though: 
https://esolangs.org/wiki/Fuckfuck

And then there's http://compsoc.dur.ac.uk/whitespace/
Jun 11 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 16:49:15 UTC, Nick Sabalausky wrote:

 On 06/11/2015 07:31 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 11 June 2015 at 11:20:12 UTC, Kagamin wrote:

 Then brainfuck wins.


 Always.


 It *is* very fun to implement. I'm more partial to this one 
 though: https://esolangs.org/wiki/Fuckfuck

 And then there's http://compsoc.dur.ac.uk/whitespace/


https://esolangs.org/wiki/Emoticon

I think it would be nice to have a language that used smileys for 
exceptions.

"if error then :-D"
Jun 11 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 11 June 2015 at 17:42:48 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 11 June 2015 at 16:49:15 UTC, Nick Sabalausky 
 wrote:

 On 06/11/2015 07:31 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 11 June 2015 at 11:20:12 UTC, Kagamin wrote:

 Then brainfuck wins.


 Always.


 It *is* very fun to implement. I'm more partial to this one 
 though: https://esolangs.org/wiki/Fuckfuck

 And then there's http://compsoc.dur.ac.uk/whitespace/


 https://esolangs.org/wiki/Emoticon

 I think it would be nice to have a language that used smileys 
 for exceptions.

 "if error then :-D"


https://gist.github.com/sprain/be75c6c456146b272178
Jun 11 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 17:45:32 UTC, weaselcat wrote:

 https://gist.github.com/sprain/be75c6c456146b272178


Ah, that's awsome! Instead of using true and false you get to use 
thumbs-up and thumbs-down...
Jun 11 2015
prev sibling parent reply "Abdulhaq" <alynch4047 gmail.com> writes:
 I really wish people would stop complaining about other 
 languages having the same features as D without giving credit. 
 It is impossible to figure out exactly where ideas from 
 features come from, but most features predate even C++ if being 
 first is the main point.


Hear, hear, is it so unlikely that one footstep should fall in 
the footprint of another?


 The hard part about designing an imperative language is not the 
 individual features, the palette is given. The hard part is 
 turning it into beautiful whole that is greater than the sum of 
 the parts. And that is important, but difficult (or impossible) 
 to achieve.


This is it. Great languages (IMO) have condensed their features 
down to the smallest set of orthogonal features that they could 
manage. This makes the language easier to reason about, to share 
code, to maintain code, to learn, to read code, even writing it 
is often easier!

Right now I feel that D is growing in 'features' and corner cases 
beyond the point where I want to explore it's depths. It's gone 
from a swim in the bay into crossing the Channel. I always think 
about Herb Sutters Guru of the Week column and how it made me 
think "ugh - too many oddities to learn". I could be wrong and I 
hope I am.

It's quite a nice twist that the thread discussing which language 
is better branched into what version of English is the right one 
- as if such a thing is meaningful. Arguing about definitions and 
terminology is surely such a useless diversion.
Jun 11 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 11:40:55 UTC, Abdulhaq wrote:

 Hear, hear, is it so unlikely that one footstep should fall in 
 the footprint of another?


We all stand on the shoulders of giants, etc.


 This is it. Great languages (IMO) have condensed their features 
 down to the smallest set of orthogonal features that they could 
 manage. This makes the language easier to reason about, to 
 share code, to maintain code, to learn, to read code, even 
 writing it is often easier!

 Right now I feel that D is growing in 'features' and corner 
 cases beyond the point where I want to explore it's depths. 
 It's gone from a swim in the bay into crossing the Channel. I 
 always think about Herb Sutters Guru of the Week column and how 
 it made me think "ugh - too many oddities to learn". I could be 
 wrong and I hope I am.


Aye. I think what I totally dislike about C++ is that I cannot 
hold the whole language in my head. It is unthinkable that I 
could just type in a C++ program using the full feature set and 
compile it with no complaints from the compiler and quite a bit 
of head-scratching to figure out why it won't take code that 
looks sensible.

Corner cases is a major reason for increased cognitive load. Even 
javascript gives me that feeling, caused by the odd weird 
non-intuitive flaws that makes such a simple language not so 
simple after all.

We'll see what happens when DMD is translated to D and 
refactored. Maybe someone creates an experimental D3 from it to 
see if it can be made a bit more orthogonal. I think that could 
be an important move.


 It's quite a nice twist that the thread discussing which 
 language is better branched into what version of English is the 
 right one - as if such a thing is meaningful.


As a norwegian I can't make up my mind as to whether I should 
write "color" or "colour". I suspect it will be taken as some 
kind of political statement. Hey, I am neutral! I use "color" in 
source code and "colour" in writing. :)
Jun 11 2015
parent "Abdulhaq" <alynch4047 gmail.com> writes:
On Thursday, 11 June 2015 at 12:11:49 UTC, Ola Fosheim Grøstad 
wrote:

 As a norwegian I can't make up my mind as to whether I should 
 write "color" or "colour". I suspect it will be taken as some 
 kind of political statement. Hey, I am neutral! I use "color" 
 in source code and "colour" in writing. :)


As an Englishman I used to rail against the USA-ification of the 
language but now I've learnt to bite the bullet and actually 
follow the same rule as yourself. Saves a lot of indigestion :-)
Jun 11 2015
prev sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 11 June 2015 at 11:40:55 UTC, Abdulhaq wrote:

 It's quite a nice twist that the thread discussing which 
 language is better branched into what version of English is the 
 right one - as if such a thing is meaningful. Arguing about 
 definitions and terminology is surely such a useless diversion.


The irony is strong...
Jun 11 2015
prev sibling next sibling parent "Laeeth Isharc" <laeeth nospamlaeeth.com> writes:
On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 One big difference between the D community and other languages' 
 communities is is that D people keep criticizing the language 
 and see every little flaw in every little corner, which is good 
 and which is why D is the way it is. Other languages' 
 communities are more like "This is theeeeeee language of the 
 future, it's super-duper, no question asked, none permitted 
 either!"


spot on!
Jun 10 2015
prev sibling parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:

 One big difference between the D community and other languages' 
 communities is is that D people keep criticizing the language 
 and see every little flaw in every little corner, which is good 
 and which is why D is the way it is. Other languages' 
 communities are more like "This is theeeeeee language of the 
 future, it's super-duper, no question asked, none permitted 
 either!"


Yes, I have not seen a better community than that. It's awesome!
Jun 10 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 9 June 2015 at 18:53:06 UTC, Dennis Ritchie wrote:

 On Tuesday, 9 June 2015 at 18:46:48 UTC, Israel wrote:

 Ruby that compiles?


 Yet Rust, Nim and Crystal is a very young languages. And alas, 
 life is not eternal to wait five years of a flourishing 
 language :) There are already ready to be used option. This is 
 D.


Yes, Nim and Crystal have a couple of more years to go. Rust has 
been backed by Mozilla for 6 years and is being used in 
production projects, so I would not downplay the potential 
uptake. I think Rust has an advantage over Go in the name Mozilla 
alone, they are more idealistic than Google.

But the Rust memory model will be hard on many programmers, also 
game programmers who don't want a "single-threaded memory model", 
so D can reach a non-Rust segment over time by focusing on 
ease-of-use. I think D needs to change focus to get there though, 
like tweaking the semantics to support faster/local GC and 
perhaps even move to benchmark-driven design.

I don't really think people pick an AoT language because of 
meta-programming. There are so many semi/dynamic languages with 
excellent meta-programming-capabilities.
Jun 10 2015
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 I think Rust has an advantage over Go in the name Mozilla alone, they
 are more idealistic than Google.


Agreed. In concrete terms, Mozilla is a non-profit, whereas Google is 
not. Google can easily drop (or reduce) support for Go if it doesn't 
serve whatever business goal they want. Or alternatively they might not 
be interested in evolving Go (or Go's toolchain) in directions that are 
useful for other people, but have little value for their business or 
technical goals.

Mozilla may see in their heart the will to develop a language such as 
Rust in part for the benefit of the programming community in general. 
Even if they don't, and they remain mainly concerned with Servo/browser 
development, if Rust's core goals are of developing large-scale 
programs, with strong static checking / verification (safeness), and 
being able to write highly optimized/fast programs - then that is 
already a project vision that can make the language highly successful.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 11 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 11 June 2015 at 11:37:21 UTC, Bruno Medeiros wrote:

 On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 I think Rust has an advantage over Go in the name Mozilla 
 alone, they
 are more idealistic than Google.


 Agreed. In concrete terms, Mozilla is a non-profit, whereas 
 Google is not. Google can easily drop (or reduce) support for 
 Go if it doesn't serve whatever business goal they want. Or 
 alternatively they might not be interested in evolving Go (or 
 Go's toolchain) in directions that are useful for other people, 
 but have little value for their business or technical goals.


I'm afraid, Mozilla is the same: picks a group of people to 
prioritize and ignores others.
Jun 11 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 11 June 2015 at 12:15:21 UTC, Kagamin wrote:

 On Thursday, 11 June 2015 at 11:37:21 UTC, Bruno Medeiros wrote:

 On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 I think Rust has an advantage over Go in the name Mozilla 
 alone, they
 are more idealistic than Google.


 Agreed. In concrete terms, Mozilla is a non-profit, whereas 
 Google is not. Google can easily drop (or reduce) support for 
 Go if it doesn't serve whatever business goal they want. Or 
 alternatively they might not be interested in evolving Go (or 
 Go's toolchain) in directions that are useful for other 
 people, but have little value for their business or technical 
 goals.


 I'm afraid, Mozilla is the same: picks a group of people to 
 prioritize and ignores others.


You will live to see splinter groups. Go++, Open Rust etc. It's 
always the same, languages that follow a narrow path will p**s 
off people enough for them to role their own.

D is really unique in the sense that it's open enough for people 
not to feel that they have to role their own. D also has enough 
features to satisfy many different users, although - and this is 
often forgotten - you don't _have_ to use them all. People like 
Go and Rust, because it tells them exactly what to do. D doesn't, 
they have to think for themselves, and a lot of people hate that, 
which is sad, because having loads of things to choose from makes 
you think more about your code and software design in general and 
it makes you a better programmer/coder/architect.
Jun 11 2015
parent reply "Abdulhaq" <alynch4047 gmail.com> writes:
 D is really unique in the sense that it's open enough for 
 people not to feel that they have to role their own. D also has 
 enough features to satisfy many different users, although - and 
 this is often forgotten - you don't _have_ to use them all. 
 People like Go and Rust, because it tells them exactly what to 
 do. D doesn't, they have to think for themselves, and a lot of 
 people hate that, which is sad, because having loads of things 
 to choose from makes you think more about your code and 
 software design in general and it makes you a better 
 programmer/coder/architect.


Thinking like that is fine when you work on your own, but when 
you're in a large team and working on a large code base the 
prospect of trying to grok a dozen different coding approaches 
using different feature sets of some uber language is entirely 
unappealing and best avoided.
Jun 11 2015
parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 11 June 2015 at 12:49:20 UTC, Abdulhaq wrote:

 D is really unique in the sense that it's open enough for 
 people not to feel that they have to role their own. D also 
 has enough features to satisfy many different users, although 
 - and this is often forgotten - you don't _have_ to use them 
 all. People like Go and Rust, because it tells them exactly 
 what to do. D doesn't, they have to think for themselves, and 
 a lot of people hate that, which is sad, because having loads 
 of things to choose from makes you think more about your code 
 and software design in general and it makes you a better 
 programmer/coder/architect.


 Thinking like that is fine when you work on your own, but when 
 you're in a large team and working on a large code base the 
 prospect of trying to grok a dozen different coding approaches 
 using different feature sets of some uber language is entirely 
 unappealing and best avoided.


Good point. But teams have to decide what's best for their 
project(s) and lay down rules and guidelines, regardless of the 
language they use.
Jun 11 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 11 June 2015 at 11:37:21 UTC, Bruno Medeiros wrote:

 On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 I think Rust has an advantage over Go in the name Mozilla 
 alone, they
 are more idealistic than Google.


 Agreed. In concrete terms, Mozilla is a non-profit, whereas 
 Google is not. Google can easily drop (or reduce) support for 
 Go if it doesn't serve whatever business goal they want. Or 
 alternatively they might not be interested in evolving Go (or 
 Go's toolchain) in directions that are useful for other people, 
 but have little value for their business or technical goals.


And Google will be right in abandoning an unsuccessful project. 
Supporting such project wouldn't benefit anyone and reusing 
resources in other promising projects is to the benefit of 
everyone.
Jun 11 2015
next sibling parent "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
On Thursday, 11 June 2015 at 12:21:30 UTC, Kagamin wrote:

 On Thursday, 11 June 2015 at 11:37:21 UTC, Bruno Medeiros wrote:

 On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 I think Rust has an advantage over Go in the name Mozilla 
 alone, they
 are more idealistic than Google.


 Agreed. In concrete terms, Mozilla is a non-profit, whereas 
 Google is not. Google can easily drop (or reduce) support for 
 Go if it doesn't serve whatever business goal they want. Or 
 alternatively they might not be interested in evolving Go (or 
 Go's toolchain) in directions that are useful for other 
 people, but have little value for their business or technical 
 goals.


 And Google will be right in abandoning an unsuccessful project.





 Supporting such project wouldn't benefit anyone and reusing 
 resources in other promising projects is to the benefit of 
 everyone.


Thinking as an economist and as a businessman that simply isn't 
true.  Whether a project fits with their own business goals is 
one thing; whether their business decisions might leave me 
stranded high and dry is another.  Now, a state of affairs where 
they are forced to support projects they wish to abandon would 
hardly be consistent with dynamic economic efficiency - it's not 
time consistent for one thing.  But in my experience one is 
foolish to create long-lived specific capital (a code base) whose 
value is complementary to services provided by another 
organisation without considering the incentives and habitual 
behaviour of this organisation.
Jun 11 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 12:21:30 UTC, Kagamin wrote:

 And Google will be right in abandoning an unsuccessful project. 
 Supporting such project wouldn't benefit anyone and reusing 
 resources in other promising projects is to the benefit of 
 everyone.


Actually, it is a problem that makes people reluctant to use 
Google technologies and that overall harms the Google eco-system 
way beyond individual projects.

Dart recently announced that they are now on github. In the 
comment field on that announcement people complained about how 
their workplaces choose Typescript over it, despite Dart being 
more suitable. They think Google will abandon it. In other news 
Google claimed to have 1 million lines of internal Dart code and 
use it for their ad sales services. So apparently they would like 
to keep the eco system alive.

People are not abandoning Dart because shows any signs of being a 
dead or a bad language, they do it because they don't trust 
Google.
Jun 11 2015
parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 11 June 2015 at 12:42:36 UTC, Ola Fosheim Grøstad 
wrote:

 People are not abandoning Dart because shows any signs of being 
 a dead or a bad language, they do it because they don't trust 
 Google.


My experience is many believe in corporate backing. Is it just PR?
Jun 11 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 11 June 2015 at 13:05:14 UTC, Kagamin wrote:

 On Thursday, 11 June 2015 at 12:42:36 UTC, Ola Fosheim Grøstad 
 wrote:

 People are not abandoning Dart because shows any signs of 
 being a dead or a bad language, they do it because they don't 
 trust Google.


 My experience is many believe in corporate backing. Is it just 
 PR?


I don't know, but I think so. Lack of stability in Google forward 
looking statements causing trust issues? It would probably be 
different if Google offered support contracts.

I also suspect that Google projects are perceived as being too 
big to be taken over by an open source community, thus a move to 
github can be viewed as an long term attempt to ditch the project 
while saving face.

I don't think the idea that "open source means nobody can take it 
away from us" is something people believe in now that there are 
so many open source projects.
Jun 11 2015
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 06/11/2015 07:37 AM, Bruno Medeiros wrote:

 On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 I think Rust has an advantage over Go in the name Mozilla alone, they
 are more idealistic than Google.


 Agreed. In concrete terms, Mozilla is a non-profit, whereas Google is
 not. Google can easily drop (or reduce) support for Go if it doesn't
 serve whatever business goal they want. Or alternatively they might not
 be interested in evolving Go (or Go's toolchain) in directions that are
 useful for other people, but have little value for their business or
 technical goals.


Well, Mozilla's really a for-profit owned by a non-profit, which is a 
little weird.

In any case, Mozilla's demonstrated enough times in their history that 
they're not particularly worried about alienating and ignoring big 
groups of users. (Heck, they don't even try to promote their products as 
customizable anymore.) Of course, whether this will actually translate 
into similar issues with Rust remains to be seen. Hopefully they'll be 
more reasonable with Rust.
Jun 11 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Tuesday, 9 June 2015 at 18:25:36 UTC, Dennis Ritchie wrote:

 On Tuesday, 9 June 2015 at 18:02:55 UTC, Ali Çehreli wrote:

 http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/


 "I might've said D, but I don't think it qualifies as 
 "emerging" since it's over a decade old."

 Well, it's just ridiculous, although I often see people trying 
 to say that minus D is "a decade of transition from D1 to D2. 
 Many call D `the dead` :) But I believe that sooner or later D 
 will destroy C++, because it is still in development, though 
 not very fast, but stable and it is good! D will rise to the 
 top of the mountain `Uphill`, despite all the prejudices of the 
 people, knowing nothing about the history of D.
 And, by the way, I have never heard of the Crystal :)


D isn't an emerging language.
And that's a good thing.

Dozens of languages pop up and die before anyone notices them, D 
has been around for what, 15 years? It's obvious that it's not 
going away anytime soon.

People also refer to Haskell as if it's some new hip language and 
it's almost as old as ANSI C.
Jun 09 2015
next sibling parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Wednesday, 10 June 2015 at 01:21:05 UTC, weaselcat wrote:

 D isn't an emerging language.
 And that's a good thing.


Yes, of course. I just read the title of this topic:
"Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the 
strongest and why?"

And I do not read the name of the theme on reddit :)
"Of the emerging systems languages Rust, D, Go, Nim and Crystal 
which is the strongest and why?"

So my comment was not the point :)


 People also refer to Haskell as if it's some new hip language 
 and it's almost as old as ANSI C.


Haskell is a creature with a deep inner world. But I don't think 
I will ever put their hands on this language as well as Perl. 
They too strange syntax, so they are clearly not the strongest. 
Of course, Lisp programmers think that the strongest language is 
a Lisp and only Lisp and nothing more. But this statement is also 
very ironic.
Jun 09 2015
parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
Why D can not be done, as in the Go:

package main
import "fmt"

func main() {
     var a, b, c = 1, 2, 3
     fmt.Printf("%d %d %d", a, b, c) // prints 1 2 3
}

http://rextester.com/WICH50477
Jun 09 2015
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 10 June 2015 at 01:21:05 UTC, weaselcat wrote:

 Dozens of languages pop up and die before anyone notices them, 
 D has been around for what, 15 years? It's obvious that it's 
 not going away anytime soon.


Talking about how old D is is a bit of a funny thing. IIRC, 
Walter started it in 1999, but it was a while before he released 
it, and it didn't hit 1.0 until 2007, and at that point we got 
D2, which wasn't even remotely stable until at least 2010. And 
while D2 builds on D1, it's a very different beast.

It really gets to the point that talking about D's age is almost 
meaningless. You really need to talk in more detail in order to 
get any useful information out of the number.

- Jonathan M Davis
Jun 09 2015
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 10 June 2015 at 01:21:05 UTC, weaselcat wrote:

 On Tuesday, 9 June 2015 at 18:25:36 UTC, Dennis Ritchie wrote:

 On Tuesday, 9 June 2015 at 18:02:55 UTC, Ali Çehreli wrote:

 http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/


 ...


 People also refer to Haskell as if it's some new hip language 
 and it's almost as old as ANSI C.


It is hip, because all those years have made its compilers quite 
good and made it one of most important languages currently in the 
world for Functional Programming research.

It also has all these companies paying money for using/improving 
it:

http://industry.haskell.org/partners

https://github.com/commercialhaskell/commercialhaskell#readme

You will find a few well known names there.

--
Paulo
Jun 10 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 10 June 2015 at 07:40:23 UTC, Paulo  Pinto wrote:

 On Wednesday, 10 June 2015 at 01:21:05 UTC, weaselcat wrote:

 On Tuesday, 9 June 2015 at 18:25:36 UTC, Dennis Ritchie wrote:

 On Tuesday, 9 June 2015 at 18:02:55 UTC, Ali Çehreli wrote:

 http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/


 ...


 People also refer to Haskell as if it's some new hip language 
 and it's almost as old as ANSI C.


 It is hip, because all those years have made its compilers 
 quite good and made it one of most important languages 
 currently in the world for Functional Programming research.

 It also has all these companies paying money for 
 using/improving it:

 http://industry.haskell.org/partners

 https://github.com/commercialhaskell/commercialhaskell#readme

 You will find a few well known names there.

 --
 Paulo


only one that really stands out is microsoft, and haskell is 
basically a microsoft research project at this point.
Jun 10 2015
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 10 June 2015 at 08:17:05 UTC, weaselcat wrote:

 On Wednesday, 10 June 2015 at 07:40:23 UTC, Paulo  Pinto wrote:

 On Wednesday, 10 June 2015 at 01:21:05 UTC, weaselcat wrote:

 On Tuesday, 9 June 2015 at 18:25:36 UTC, Dennis Ritchie wrote:

 On Tuesday, 9 June 2015 at 18:02:55 UTC, Ali Çehreli wrote:

 http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/


 ...


 People also refer to Haskell as if it's some new hip language 
 and it's almost as old as ANSI C.


 It is hip, because all those years have made its compilers 
 quite good and made it one of most important languages 
 currently in the world for Functional Programming research.

 It also has all these companies paying money for 
 using/improving it:

 http://industry.haskell.org/partners

 https://github.com/commercialhaskell/commercialhaskell#readme

 You will find a few well known names there.

 --
 Paulo


 only one that really stands out is microsoft, and haskell is 
 basically a microsoft research project at this point.


Facebook

Banks like Standard Chartered, Tsuru Capital, Capital Match,...
Jun 10 2015
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/9/15 11:02 AM, Ali Çehreli wrote:

 http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/


Also found this: 
http://www.reddit.com/r/programming/comments/3971qf/this_week_in_d_dconf_2015_report_new_forum_site/


Andrei
Jun 09 2015
prev sibling parent reply "jmh530" <john.michael.hall gmail.com> writes:
I'm not really familiar with Go, Nim, or Crystal, but I spent 
some time learning about Rust yesterday. I thought it was pretty 
interesting. In particular,
1) The GC is optional (memory safety is enforced by the type 

2) Smart pointers with separate operators and support for 
reference counting.
3) Immutability by default. Someone (somewhere) made an 
interesting point that it can be conceptually convenient to have 
the most restrictive choice as the default. I'm not sure I agree 
with that (maybe the most common choice used in good code), but 
at least immutability by default it can be helpful for concurrent 
programming.

All of the above seems to have a downside too
1) The memory safety stuff is pretty confusing. Move and copy 
both use the equality operator, but you're not always able to use 
it depending on the type. I think a separate move operator would 
clear up some of the confusion. I also didn't really get a good 
handle on how borrowing and lifetimes worked, but it seemed in 
need of a simpler explanation.
2) The plethora of options for smart pointers and reference 
counting
2) No prefix operators like ++a. Perhaps a consequence of 
immutability.
Jun 10 2015
parent reply "Dave" <whatever whatever.com> writes:
On Wednesday, 10 June 2015 at 17:34:55 UTC, jmh530 wrote:

 3) Immutability by default. Someone (somewhere) made an 
 interesting point that it can be conceptually convenient to 
 have the most restrictive choice as the default. I'm not sure I 
 agree with that (maybe the most common choice used in good 
 code), but at least immutability by default it can be helpful 
 for concurrent programming.


I am one of those that think that a language should allow you to
do whatever you want, but be restrictive by default. For example
immutability unless you explicitly ask for mutability (like in
Rust). D sort of has the ability to do this, but it's sort of
backwards due to it's defaults. For instance D is mutable by
default (an inherited trait due to the C subset of the language),
with the ability to explicitly mark values as immutable. Another
backwards annotation is nothrow. I don't really care if something
doesn't throw, I care when it throws, because then I have to do
something (or my program may crash unexpectedly). Even if the
enforcement is kind of there (although unannotated functions can
do whatever), it would have been a better guarantee to disallow
this by default.

Then you have purity, garbage collection and final which also
seem backwards from what they should have been (although better
arguments can be made for these than immutability and nothrow). D
did get thread local storage correct, but I think people are
starting to get on board with having restrictions by default
because it prevents bugs (and the annotations are grepable). Kind
of like what Rust is doing. If this is the case, D might find
itself being discarded in favor of languages that offer better
guarantees.

Just a thought from a random spectator ;)
Jun 10 2015
next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote:

 On Wednesday, 10 June 2015 at 17:34:55 UTC, jmh530 wrote:

 3) Immutability by default. Someone (somewhere) made an 
 interesting point that it can be conceptually convenient to 
 have the most restrictive choice as the default. I'm not sure 
 I agree with that (maybe the most common choice used in good 
 code), but at least immutability by default it can be helpful 
 for concurrent programming.


 I am one of those that think that a language should allow you to
 do whatever you want, but be restrictive by default. For example
 immutability unless you explicitly ask for mutability (like in
 Rust). D sort of has the ability to do this, but it's sort of
 backwards due to it's defaults. For instance D is mutable by
 default (an inherited trait due to the C subset of the 
 language),
 with the ability to explicitly mark values as immutable. Another
 backwards annotation is nothrow. I don't really care if 
 something
 doesn't throw, I care when it throws, because then I have to do
 something (or my program may crash unexpectedly). Even if the
 enforcement is kind of there (although unannotated functions can
 do whatever), it would have been a better guarantee to disallow
 this by default.


I usually agree that the more restrictive option should be the 
default, but exceptions is... well... the exception. The whole 
point of the exceptions system is to limit the number of points 
where you need to worry about something going wrong to the place 
where it happens and the places where you want to do something 
special with it. nothrow by default means you can't do that - you 
have to care about the exception at every single point in 
between. The result is a better syntax for the exact same thing 
the exceptions idiom was supposed to prevent...
Jun 10 2015
parent reply "Dave" <whatever whatever.com> writes:
 I usually agree that the more restrictive option should be the 
 default, but exceptions is... well... the exception. The whole 
 point of the exceptions system is to limit the number of points 
 where you need to worry about something going wrong to the 
 place where it happens and the places where you want to do 
 something special with it.


The point of exceptions is to communicate errors and where they
originate. As long as this is respected, then I am not following
your complaint.


 you have to care about the exception at every single point in 
 between.


That's the point. If you don't annotate the function (with a
throw keyword for instance), then you are forced to catch and
handle the exception. If you annotate it (saying this function 
will throw), no catch is needed, but at least you are 
communicating to the next layer that
this code *does* have errors that should be accounted for.


 nothrow by default means you can't do that


Actually no guarantees by default means you can't do what I 
explained above.
Jun 10 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 10 June 2015 at 19:56:00 UTC, Dave wrote:

 I usually agree that the more restrictive option should be the 
 default, but exceptions is... well... the exception. The whole 
 point of the exceptions system is to limit the number of 
 points where you need to worry about something going wrong to 
 the place where it happens and the places where you want to do 
 something special with it.


 The point of exceptions is to communicate errors and where they
 originate. As long as this is respected, then I am not following
 your complaint.


 you have to care about the exception at every single point in 
 between.


 That's the point. If you don't annotate the function (with a
 throw keyword for instance), then you are forced to catch and
 handle the exception. If you annotate it (saying this function 
 will throw), no catch is needed, but at least you are 
 communicating to the next layer that
 this code *does* have errors that should be accounted for.


 nothrow by default means you can't do that


 Actually no guarantees by default means you can't do what I 
 explained above.


The promise of exceptions isn't to not have to specifically 
handle errors in every layer - it's to not care about exceptions 
in every layer. I don't want to pass the annotation in each and 
every intermediate layer - I want only the throwing layer and the 
catching layer to acknowledge the exception's existence. The 
middle layers should be written like there is no exception, and 
when there is one, they will simply fail and let RAII to 
automatically do the cleanup.

I've programmed enough Java to know how harmful 
nothrow-by-default is. It doesn't really guarantee the functions 
not annotated as throwing won't crash - only that if they do 
crash there is nothing you can do about it. This mechanism is so 
easy to bypass in harmful ways(catch and rethrow something that 
doesn't need annotation(like Error), or terminate the process 
with a special exit function), and annotating the layers all the 
way up is so cumbersome(and sometimes impossible - when you 
override functions, or pass delegates) that this mechanism tends 
to encourage to bypass it, which harms the debugging.

Of course, nothrow as the optional annotation is a different 
syntax for the same semantics, so it suffers from the same 
drawbacks but it has the benefit of seldom being use therefore 
seldom getting in your way. Which leads me to the final 
conclusion - there shouldn't be nothrow, not by default and not 
as special annotation!

(I'm not talking about D here - this isn't worth the code 
breakage - but generally on programming languages)

If it's an error that the caller needs to know about - make it 
part of the return type. If it doesn't need to know about it - 
throw an exception and let someone up the line handle it. Rust 
got it right - though they made it a bit cumbersome to catch 
`panic`s. Why would I need to catch panic? To display them nicely 
to the user(don't just dump to stderr - pop up a window that 
apologizes and prompts the user to email the exception data to 
the developers) or to rollback the changes(yes, there was an 
irrecoverable error in the program. That doesn't give me the 
right to corrupt user data when I can avoid it). But the point is 
- you can either handle it or ignore it. The "sign here and we'll 
pass it on" bureaucracy is not benefiting anyone.
Jun 10 2015
parent reply "Dave" <Whatever whatever.com> writes:
 The promise of exceptions isn't to not have to specifically 
 handle errors in every layer


Correct me if I am wrong, but aren't exceptions in D used for
general error handling? Doesn't Phobos prefer exceptions over
return codes?


 it's to not care about exceptions in every layer.


My second job was working in the sustaining department of a large
company. One of the most frequent cause of bugs were people not
checking errors. The fix was almost always handle the error at
its source and log or signal a message to some IO informing the
user. Users tend to prefer messages over complete meltdowns. Too
many avoidable outages and crashes came by my desk due to this
attitude. Very few domains/cases require hard fails.


 I don't want to pass the annotation in each and every 
 intermediate layer


Seems like an odd comment to have on the forum of a language that
frequently has functions in the standard library annotated like
this:
pure nothrow  nogc  safe real abs(Num)(Num y)


 The middle layers should be written like there is no exception, 
 and when there is one, they will simply fail and let RAII to 
 automatically do the cleanup.


Everything works better than expect...


 I've programmed enough Java to know how harmful 
 nothrow-by-default is.


I disagree one this. Lets agree to disagree.


 It doesn't really guarantee the functions not annotated as 
 throwing won't > crash


Combined with other guarantees (such as immutability, thread
local storage, safe memory management, side-effect free code, no
recursion, etc), you can make a reasonable guarantee about the
safety of your code.


 Of course, nothrow as the optional annotation is a different 
 syntax for the same semantics, so it suffers from the same 
 drawbacks but it has the benefit of seldom being use therefore 
 seldom getting in your way. Which leads me to the final 
 conclusion - there shouldn't be nothrow, not by default and not 
 as special annotation!


The guarantee is useful in many cases. Again lets agree to
disagree. But I agree most people will "opt-out".


 (I'm not talking about D here - this isn't worth the code 
 breakage - but generally on programming languages)


As am I. My initial comment was not meant to encourage change in
the D language. But perhaps it may spin the right dials on
someone else and they may think of a better fitting solution.


 If it's an error that the caller needs to know about - make it 
 part of the return type. If it doesn't need to know about it - 
 throw an exception and let someone up the line handle it.


I don't agree with this. Too much to worry about. Impractical to
maintain both paradigms. What errors don't you need to know about?


 Rust got it right - though they made it a bit cumbersome to 
 catch `panic`s. Why would I need to catch panic? To display 
 them nicely to the user(don't just dump to stderr - pop up a 
 window that apologizes and prompts the user to email the 
 exception data to the developers) or to rollback the 
 changes(yes, there was an irrecoverable error in the program.


I am not anywhere near proficient enough in Rust to really
comment much on it's methods.


 handle it or ignore it.


The process I mentioned would not prevent this in anyway. Just
inform others of the decision you made that may have adverse
effects on the stability of their code.
Jun 10 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 11 June 2015 at 00:27:09 UTC, Dave wrote:

 The promise of exceptions isn't to not have to specifically 
 handle errors in every layer


 Correct me if I am wrong, but aren't exceptions in D used for
 general error handling? Doesn't Phobos prefer exceptions over
 return codes?


It seems to be a controversial subject: 
https://github.com/D-Programming-Language/phobos/pull/1090#issuecomment-12737986


 it's to not care about exceptions in every layer.


 My second job was working in the sustaining department of a 
 large
 company. One of the most frequent cause of bugs were people not
 checking errors. The fix was almost always handle the error at
 its source and log or signal a message to some IO informing the
 user. Users tend to prefer messages over complete meltdowns. Too
 many avoidable outages and crashes came by my desk due to this
 attitude. Very few domains/cases require hard fails.


Exceptions are not meant to force handling errors at he source. 
If you want to force handling errors at the source they should be 
part of the return type. I'm not talking about C style 
return-error-code-and-write-the-actual-result-into-a-variable
passed-by-reference 
- functional languages like Haskell, Scala and Rust have shown 
that monadic sum types of result/error are both safe(don't allow 
you to access the returned value unless you do it in a path that 
makes sure there wasn't an error, or convert the error into an 
exception) and easy to use(adds very little syntactic overhead 
for the good path, and the bad path code is simpler than in 
exception handling)

Exceptions are not "hard fails". You don't have to crash the 
entire program - just fail the action the user was trying to do 
and display a nice error message with whatever information you 
can and want to provide to the user. Even if you don't handle 
them, they provide information useful for debugging.


 I don't want to pass the annotation in each and every 
 intermediate layer


 Seems like an odd comment to have on the forum of a language 
 that
 frequently has functions in the standard library annotated like
 this:
 pure nothrow  nogc  safe real abs(Num)(Num y)


Just because I use the language doesn't mean I have to like every 
single one of it's features...


 I've programmed enough Java to know how harmful 
 nothrow-by-default is.


 I disagree one this. Lets agree to disagree.


I agree to disagree


 It doesn't really guarantee the functions not annotated as 
 throwing won't > crash


 Combined with other guarantees (such as immutability, thread
 local storage, safe memory management, side-effect free code, no
 recursion, etc), you can make a reasonable guarantee about the
 safety of your code.


And a superhero cape, combined with an airplane, airplane fuel 
and flight school, allow you to fly in the air.

It is the other restrictions(without getting into a discussion 
about each and every restriction in the list) that make the code 
safer - nothrow doesn't really contribute IMO.


 If it's an error that the caller needs to know about - make it 
 part of the return type. If it doesn't need to know about it - 
 throw an exception and let someone up the line handle it.


 I don't agree with this. Too much to worry about. Impractical to
 maintain both paradigms. What errors don't you need to know 
 about?


Scala and Rust seem to maintain both paradigms just fine. It's 
actually beneficial to have both - you have to acknowledge 
return-type-based exceptions, and you can always bypass them by 
turning them to exceptions, which are good for logging and 
debugging. If exception handling is enforced, they can only by 
bypassed by converting them to errors or crashes, which are much 
less nice than exceptions when it comes to debugging, logging and 
cleanup.

If I have to be explicit about not handling an error somewhere, I 
prefer the "this exact thing here can return an error, I assume 
it won't, but if it does you'll get an exception so it can be 
debugged" approach over the "not that I care, but something, 
somewhere down that path might throw" approach.


 handle it or ignore it.


 The process I mentioned would not prevent this in anyway. Just
 inform others of the decision you made that may have adverse
 effects on the stability of their code.


Writing code that acknowledges that this code can fail due to an 
exception somewhere else does not count as ignoring it.
Jun 11 2015
parent reply "Dave" <Whatever whatever.com> writes:
 It seems to be a controversial subject: 
 https://github.com/D-Programming-Language/phobos/pull/1090#issuecomment-12737986


As the topic has been argued for the past 50 years. No one ever 
agrees
on the best way to handle errors. But I think most of this is 
because programmers tend to be the most stubborn and unchanging 
type of folks in the world. They often care that they look right. 
Not that they are right ;)


 Exceptions are not meant to force handling errors at he source.


This attitude is why so many exceptions go unhandled at the upper
layers. When you have a top level that calls a function that 
calls 50 other functions, each that throw a handful or more 
different exceptions, it's unreasonable to expect the upper layer 
coder to account for all of them. In fact, in practice they 
usually don't until bugs arise. This is provably bad practice.


 If you want to force handling errors at the source they should 
 be part of the return type.


Again what errors are worth throwing as exceptions in your
paradigm? Which ones are worth returning? This separation is very
arbitrary for my taste.


 Exceptions are not "hard fails".


They can be if they go unaccounted for (depending on the
language/environment). Java has the infamous,

NullReferenceException.


 You don't have to crash the entire program just fail the action 
 the user was trying to do and display a nice error message with 
 whatever information you can and want to provide to the user. 
 Even if you don't handle them, they > provide information 
 useful for debugging.


Not gonna disagree there.


 It doesn't really guarantee the functions not annotated as 
 throwing won't > crash


 Combined with other guarantees (such as immutability, thread
 local storage, safe memory management, side-effect free code, 
 no
 recursion, etc), you can make a reasonable guarantee about the
 safety of your code.


 And a superhero cape, combined with an airplane, airplane fuel 
 and flight school, allow you to fly in the air.


Not really sure how to parse this...Doesn't seem like you have 
any good argument against what I said. Again I said you can make 
a *reasonable* guarantee. And I am not alone here. If you look at 
Rust, it really does illustrate a trend that functional 
programming has been pushing for a long time. Provable 
guarantees. Problems are very rarely unique. There are a core set 
of things that happen frequently that cause problems. And these 
things are easily recognizable by compilers. You can't prevent 
everything, but you can prevent a good deal of the obvious stuff. 
This is just an extension of that mindset. So it is not really 
that outlandish.


 It is the other restrictions(without getting into a discussion 
 about each and every restriction in the list) that make the 
 code safer - nothrow doesn't really contribute IMO.


Without the nothrow, you cannot guarantee it won't cause problems
with unhandled errors ;) Seems like a nice guarantee to me. I
would at least like this option, because library writers often
try to write in an idiomatic way (and I tend to use the most 
reputable libraries I can find), which gives you some guarantees. 
The guarantee would be better served by default IMHO though.

Having a 'throw' keyword is also useful for IDE's. Anybody that

that Visual Studio can tell you what exceptions get thrown when 
calling a

'throw' keyword would actually help scanners figure this out very 
trivially as well as programmers just reading the header of a 
function.


 Scala and Rust seem to maintain both paradigms just fine. It's 
 actually beneficial to have both - you have to acknowledge 
 return-type-based exceptions, and you can always bypass them by 
 turning them to exceptions, which are good for logging and 
 debugging.


I do not believe Rust has exceptions.

I don't mind a language having multiple ways to handle errors.
Seeing how its a topic no one ever is on the same page about,
it's actually a wise design decision. But you don't often see
library writers mixing them for consistency purposes. It's just
easier for people to learn your library when you have one error
handling scheme. It's usually encountered only where two
libraries written by different vendors have to interact in
application code.


 If exception handling is enforced, they can only be bypassed by 
 converting them to errors or crashes, which are much less nice 
 than exceptions when it comes to debugging, logging and cleanup.


Exceptions have many benefits. They have many disadvantages too.
They are often very slow on the exceptional path, which occur
more frequently than most admit.


 Writing code that acknowledges that this code can fail due to 
 an exception somewhere else does not count as ignoring it.


You could not handle it all the way up the chain (at the cost of
adding something to a definition, not much trade-off there). That
would essentially be ignoring it. From a design perspective you
could also have some mechanism (be it a keyword or whatever) that
you use to explicitly 'suppress' them for code that needs to be
faster, or code that you literally don't care. In application
code, you care. It's a good default to force people to handle
errors as they occur (which is what I am talking about,
defaults). If they wish to not handle them there, it's not at all
hard to imagine ways to allow people to 'suppress' them or 'pass
them up' when the situation calls for it. Force people to deal
with them by default, let them explicitly handle it in another
way. Or they can just use return types.
Jun 11 2015
next sibling parent reply "Dave" <Whatever whatever.com> writes:
I should also mention that D has essentially enabled this
philosophy that I am speaking about concerning errors by using
the 'scope' keyword. I believe handling errors with scope
literally translates to try\catch blocks behind the scenes. I
also believe this is an encouraged way of dealing with errors in
D.
Jun 11 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/11/2015 6:40 AM, Dave wrote:

 I believe handling errors with scope
 literally translates to try\catch blocks behind the scenes.


Yes, exactly.
Jun 11 2015
prev sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 11 June 2015 at 13:21:27 UTC, Dave wrote:

 Exceptions are not meant to force handling errors at he source.


 This attitude is why so many exceptions go unhandled at the 
 upper
 layers. When you have a top level that calls a function that 
 calls 50 other functions, each that throw a handful or more 
 different exceptions, it's unreasonable to expect the upper 
 layer coder to account for all of them. In fact, in practice 
 they usually don't until bugs arise. This is provably bad 
 practice.


I'd rather have an exception unhandled at the top level than 
discarded at a middle level. Much easier to debug when you get a 
proper stack trace. Also, the top level handling can be very 
generic if it's purpose is not to solve the problem but to log it 
and to allow to use to continue using the other parts of the 
program as much as possible.


 If you want to force handling errors at the source they should 
 be part of the return type.


 Again what errors are worth throwing as exceptions in your
 paradigm? Which ones are worth returning? This separation is 
 very
 arbitrary for my taste.


Exceptions are for when something went wrong. Returned errors are 
for when the function can't do what you asked it to do, but that 
doesn't mean that something went wrong.

For example, if you try to write to a file and fail that's an 
exception, because something went wrong(e.g. - not enough disk 
space, or a permissions problem).

But if you have a function that parses a string to a number and 
you call it with a non-numeric string - that doesn't necessarily 
mean that something went wrong. Maybe I don't expect all strings 
to be convertible to numbers, and instead of parsing each string 
twice(once for validation and once for the actual conversion) I 
prefer to just convert and rely on the conversion function to 
tell me if it's not a number?

Note that doesn't mean that every time a function returns an 
error it's not a problem - they can indicate problems, the point 
is that it's not up to the callee to decide, it's up to the 
caller. The conversion function doesn't know if I'm parsing a 
YAML file and if field value is not a number that just means it's 
a string, or if I'm parsing my own custom file format and if 
something specific is not a number that means the file is 
corrupted.

In the latter case, I can convert the returned error to 
exception(the returned error's type should have a method that 
returns the underlying result if it's OK and if there was an 
error raises an exception), but it's the caller's decision, not 
the callee.


 Exceptions are not "hard fails".


 They can be if they go unaccounted for (depending on the
 language/environment). Java has the infamous,

 NullReferenceException.


Even if they go unaccounted for, you still get a nice stack trace 
that helps you debug them. Maybe we have different definitions 
for "hard fail"...


 It doesn't really guarantee the functions not annotated as 
 throwing won't > crash


 Combined with other guarantees (such as immutability, thread
 local storage, safe memory management, side-effect free code, 
 no
 recursion, etc), you can make a reasonable guarantee about the
 safety of your code.


 And a superhero cape, combined with an airplane, airplane fuel 
 and flight school, allow you to fly in the air.


 Not really sure how to parse this...Doesn't seem like you have 
 any good argument against what I said. Again I said you can 
 make a *reasonable* guarantee. And I am not alone here. If you 
 look at Rust, it really does illustrate a trend that functional 
 programming has been pushing for a long time. Provable 
 guarantees. Problems are very rarely unique. There are a core 
 set of things that happen frequently that cause problems. And 
 these things are easily recognizable by compilers. You can't 
 prevent everything, but you can prevent a good deal of the 
 obvious stuff. This is just an extension of that mindset. So it 
 is not really that outlandish.


 It is the other restrictions(without getting into a discussion 
 about each and every restriction in the list) that make the 
 code safer - nothrow doesn't really contribute IMO.


 Without the nothrow, you cannot guarantee it won't cause 
 problems
 with unhandled errors ;) Seems like a nice guarantee to me. I
 would at least like this option, because library writers often
 try to write in an idiomatic way (and I tend to use the most 
 reputable libraries I can find), which gives you some 
 guarantees. The guarantee would be better served by default 
 IMHO though.


Even with no throw you can't guarantee a function won't cause 
problems with unhandled errors - unless you use a very strict 
definition of handling errors, that include discarding them or 
crashing the program. nothrow can only guarantee the function 
won't expose any problems you can use the exceptions mechanism to 
debug or deal with - not very useful, considering how easy it is 
to convert an error that plays nice with the exceptions mechanism 
to an error that horribly crashes the program...


 Having a 'throw' keyword is also useful for IDE's. Anybody that

 that Visual Studio can tell you what exceptions get thrown when 
 calling a

 'throw' keyword would actually help scanners figure this out 
 very trivially as well as programmers just reading the header 
 of a function.


If you insist on forcing developers to handle exceptions close to 
the source, or to explicitly pass them on, I guess it can be 
useful let them know what it is that they are require to 
handle/pass on. Still, I don't think it's a good idea to 
needlessly burden people just so you could provide them with the 
tool to better handle that burden.


 Scala and Rust seem to maintain both paradigms just fine. It's 
 actually beneficial to have both - you have to acknowledge 
 return-type-based exceptions, and you can always bypass them 
 by turning them to exceptions, which are good for logging and 
 debugging.


 I do not believe Rust has exceptions.


It has panics, which are different from exceptions in that you 
can't catch them(unless it's from another thread), but close in 
their usage to what I have in mind when referring to exceptions - 
they don't allow you to go on with what you where trying to do, 
but allow you to debug the problem and/or back down from it 
gracefully.


 I don't mind a language having multiple ways to handle errors.
 Seeing how its a topic no one ever is on the same page about,
 it's actually a wise design decision. But you don't often see
 library writers mixing them for consistency purposes. It's just
 easier for people to learn your library when you have one error
 handling scheme. It's usually encountered only where two
 libraries written by different vendors have to interact in
 application code.


It's not a matter of preferences, just like choosing between int 
and float is not a matter of preferences. Each type of error has 
it's own purpose, and a library can use them both.


 If exception handling is enforced, they can only be bypassed 
 by converting them to errors or crashes, which are much less 
 nice than exceptions when it comes to debugging, logging and 
 cleanup.


 Exceptions have many benefits. They have many disadvantages too.
 They are often very slow on the exceptional path, which occur
 more frequently than most admit.


Returned errors provide a faster error path, and when you have to 
decide if an error should be returned or thrown, the ones that 
should be thrown are usually the ones where you don't care as 
much about speed.


 Writing code that acknowledges that this code can fail due to 
 an exception somewhere else does not count as ignoring it.


 You could not handle it all the way up the chain (at the cost of
 adding something to a definition, not much trade-off there).


Assuming you have control over the definition, which is not 
always the case. In Java, for example, when you implement an 
interface you have no control over the signature of it's methods. 
The library that have provided that interface doesn't know what 
the implementers are going to do, so it has to either mark the 
methods as all-throwing(kind of defeats the purpose of the 
`throws` annotation), or pretend it's implementers can't 
throw(which we know is not true).


 That
 would essentially be ignoring it. From a design perspective you
 could also have some mechanism (be it a keyword or whatever) 
 that
 you use to explicitly 'suppress' them for code that needs to be
 faster, or code that you literally don't care. In application
 code, you care. It's a good default to force people to handle
 errors as they occur (which is what I am talking about,
 defaults). If they wish to not handle them there, it's not at 
 all
 hard to imagine ways to allow people to 'suppress' them or 'pass
 them up' when the situation calls for it. Force people to deal
 with them by default, let them explicitly handle it in another
 way. Or they can just use return types.


Returned errors are a faster mechanism that forces to deal with 
the error at the source, or explicitly transfer it to the upper 
level at the cost of changing the function's signature. 
Exceptions are a slower mechanism that allows to deal with the 
errors far from the source without requiring special function 
signatures in the middle levels(when they do require it's a 
syntactic salt, not a requirement of the mechanism).

nothrow by default is combining the slowness of exceptions with 
the limitness of returned errors. Why would anyone want to do 
that?
Jun 11 2015
parent reply "Dave" <whatever whatever.com> writes:
 Exceptions are for when something went wrong. Returned errors 
 are for when the function can't do what you asked it to do, but 
 that doesn't mean that something went wrong.


You seem to be implying this as a fact, when traditionally this
is not how things are done.


 For example, if you try to write to a file and fail that's an 
 exception, because something went wrong(e.g. - not enough disk


Agreed. Traditionally handled with an exception.


 But if you have a function that parses a string to a number and 
 you call it with a non-numeric string - that doesn't 
 necessarily mean that something went wrong. Maybe I don't 
 expect all strings to be convertible to numbers, and instead of 
 parsing each string twice(once for validation and once for the 
 actual conversion) I prefer to just convert and rely on the 
 conversion function to tell me if it's not a number?



throws a Format exception if a parse fails. Java throws...a
ParseException. Just for some real-world examples.


 Note that doesn't mean that every time a function returns an 
 error it's not a problem - they can indicate problems, the 
 point is that it's not up to the callee to decide, it's up to 
 the caller. The conversion function doesn't know if I'm parsing 
 a YAML file and if field value is not a number that just means 
 it's a string, or if I'm parsing my own custom file format and 
 if something specific is not a number that means the file is 
 corrupted.


In a lot of C/C++ code a lot of functions just inform you that it
failed. Sometimes they push it onto an error queue you can check.
Sometimes they throw exceptions. Sometimes the return is an error
code itself. But you very rarely see them return an error code
AND throw an exception or push on an error queue. If they do they
are being redundant.


 In the latter case, I can convert the returned error to 
 exception(the returned error's type should have a method that 
 returns the underlying result if it's OK and if there was an 
 error raises an exception), but it's the caller's decision, not 
 the callee.


The implementer makes the decision on how errors are
communicated.The caller has no control over the mechanism minus
editing their code.


 Exceptions are not "hard fails".


 They can be if they go unaccounted for (depending on the
 language/environment). Java has the infamous,

 NullReferenceException.


 Even if they go unaccounted for, you still get a nice stack 
 trace that helps you debug them.


You still would. This is not being debated. However, programmers
seem to forget their code is often for customers. They care more
that their program just crashed. Very rarely are the exceptions
in forms where they can go "you know what would fix this?". No.
They write a defect up and send it to the company that made the
product.


 Maybe we have different definitions for "hard fail"...


A crash? Or abrupt termination of an entire execution stack?
Often unnecessarily?


 Even with no throw you can't guarantee a function won't cause 
 problems with unhandled errors - unless you use a very strict 
 definition of handling errors, that include discarding them or 
 crashing the program.


A very strict definition of handling errors is EXACTLY what I am
advocating for. You should be able to do what you want. But when
you do something naughty or potentially disruptive, you should
inform others.


 nothrow can only guarantee the function won't expose any 
 problems


That's a solid guarantee. I'd advocate that so much I might even
go as far as suggesting it as a default ;)


 If you insist on forcing developers to handle exceptions close 
 to the source, or to explicitly pass them on, I guess it can be 
 useful let them know what it is that they are require to 
 handle/pass on.


Exactly.


 Still, I don't think it's a good idea to needlessly burden 
 people just so > you could provide them with the tool to better 
 handle that burden.


I am not sure any *real* burden is here. People should be doing
this in the form of documentation anyhow. However, if it's part
of the definition, the work on documenting a function or type
becomes easier. Because functionally they have an idea of what is
needed by the language's definition and the header of the
function or type.


 It has panics, which are different from exceptions in that you 
 can't catch them(unless it's from another thread), but close in 
 their usage to what I have in mind when referring to exceptions 
 - they don't allow you to go on with what you where trying to 
 do, but allow you to debug the problem and/or back down from it 
 gracefully.


I know very little about Rust. I only recently encountered a
discussion about RAII where one of the developers said Rust has
RAII but no exceptions. That is the only reason why I commented
about anything regarding Rust with any certainty.


 It's not a matter of preferences, just like choosing between 
 int and float is not a matter of preferences. Each type of 
 error has it's own purpose, and a library can use them both.


It seems to be a matter of preference to others. Most library
writers literally choose one error handling scheme. It's not
common that you see too much of a mix.


 Returned errors provide a faster error path, and when you have 
 to decide if an error should be returned or thrown, the ones 
 that should be thrown are usually the ones where you don't care 
 as much about speed.


Not arguing the merits of returning error codes. The benefit of
returning errors it that it doesn't have the potential to disrupt
a process directly. Now ignoring the error is bad practice, as it
could indirectly cause problems with something down the line
(which is why I said checking errors in all cases is good
practice). Unchecked exceptions have the potential to directly
disrupt a process. 99.999% of the time unexpectedly.


 Writing code that acknowledges that this code can fail due to 
 an exception somewhere else does not count as ignoring it.


 You could not handle it all the way up the chain (at the cost 
 of
 adding something to a definition, not much trade-off there).


 Assuming you have control over the definition, which is not 
 always the case. In Java, for example, when you implement an 
 interface you have no control over the signature of it's 
 methods. The library that have provided that interface doesn't 
 know what the implementers are going to do, so it has to either 
 mark the methods as all-throwing(kind of defeats the purpose of 
 the `throws` annotation),


It does not defeat the purpose of 'throws' completely. Because
now people know you need to 'catch' at some point due to
something in this method. Most languages allow for a wildcard
catch statement to match wildcard throws.


 Returned errors are a faster mechanism that forces to deal with 
 the error at the source, or explicitly transfer it to the upper 
 level at the cost of changing the function's signature.


Yes what is your point? Some people go this direction. Others say
it doesn't provide enough information at times. Which is why many
turn to exceptions.


 Exceptions are a slower mechanism that allows to deal with the 
 errors far from the source without requiring special function 
 signatures in the middle levels(when they do require it's a 
 syntactic salt, not a requirement of the mechanism).


Again what's your point. I agree exceptions are slow. I disagree
on your usage.


 nothrow by default is combining the slowness of exceptions with 
 the limitness of returned errors. Why would anyone want to do 
 that?


How would something that is guaranteeing that exceptions won't be
used, combining anything with the idea they are forbidding? You
literally are getting a guarantee that any slow down is not due
to exceptions. So this last statement is non-sense (I am sorry to
be blunt, but it is).
Jun 11 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 11 June 2015 at 18:17:01 UTC, Dave wrote:


 throws a Format exception if a parse fails.


https://msdn.microsoft.com/en-us/library/f02979c7%28v=vs.110%29.aspx
https://msdn.microsoft.com/en-us/library/bb299639%28v=vs.110%29.aspx
Jun 11 2015
parent reply "Dave" <whatever whatever.com> writes:
On Thursday, 11 June 2015 at 20:06:45 UTC, Kagamin wrote:

 On Thursday, 11 June 2015 at 18:17:01 UTC, Dave wrote:


 throws a Format exception if a parse fails.


 https://msdn.microsoft.com/en-us/library/f02979c7%28v=vs.110%29.aspx
 https://msdn.microsoft.com/en-us/library/bb299639%28v=vs.110%29.aspx


Forgot the one named "Parse"...

https://msdn.microsoft.com/en-us/library/b3h1hf19(v=vs.110).aspx

Microsoft does lets you opt out (as I suggested). The default 
function, the one actually named "Parse" (Int32.Parse), throws an 
exception by default.
Jun 11 2015
parent reply =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
"Dave" <whatever whatever.com> wrote:

 On Thursday, 11 June 2015 at 20:06:45 UTC, Kagamin wrote:

 On Thursday, 11 June 2015 at 18:17:01 UTC, Dave wrote:


 throws a Format exception if a parse fails.


 
 https://msdn.microsoft.com/en-us/library/f02979c7%28v=vs.110%29.aspx
 https://msdn.microsoft.com/en-us/library/bb299639%28v=vs.110%29.aspx


 
 Forgot the one named "Parse"...
 
 https://msdn.microsoft.com/en-us/library/b3h1hf19(v=vs.110).aspx
 
 Microsoft does lets you opt out (as I suggested). The default function,
 the one actually named "Parse" (Int32.Parse), throws an exception by default.


Originally (.Net 1) there was only 'Parse', 'TryParse' came in .Net 2, I
guess they had to admit that exceptions are not always practical.
Jun 12 2015
parent "Dave" <whatever whatever.com> writes:
 Originally (.Net 1) there was only 'Parse', 'TryParse' came in 
 .Net 2, I
 guess they had to admit that exceptions are not always 
 practical.


I think TryParse (and anything marked prefixed with Try) is meant
for quick stuff. It doesn't return any error. Just a boolean
indicating that it failed. The entire function seems to be a
wrapper around the actual try mechanism. So Parse will give you
an error, TryParse will just tell you it failed.
Jun 12 2015
prev sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 11 June 2015 at 18:17:01 UTC, Dave wrote:

 nothrow by default is combining the slowness of exceptions 
 with the limitness of returned errors. Why would anyone want 
 to do that?


 How would something that is guaranteeing that exceptions won't 
 be
 used, combining anything with the idea they are forbidding? You
 literally are getting a guarantee that any slow down is not due
 to exceptions. So this last statement is non-sense (I am sorry 
 to
 be blunt, but it is).


He is saying that now anything that throws will not only be slow 
but also have the same limitations as returned errors. Which at 
that point begs the question of why use exceptions at all? If you 
have to acknowledge it anyways, then might as well just use 
returned errors because they are faster.
Jun 11 2015
parent reply "Dave" <whatever whatever.com> writes:
 He is saying that now anything that throws will not only be 
 slow but also have the same limitations as returned errors.


"nothrow by default is combining the slowness of exceptions with
the limitness of returned errors."

He literally said combine the slowness of exceptions. So I don't
know how to read that other than he said it's slow. But perhaps I
am just misunderstanding his wording, so perhaps it's best I just
assume I misunderstood him.


 but also have the same limitations as returned errors


That is a legitimate concern, but I don't think it is correct.
The transitive nature would enforce that you at least handle it
at some point along the chain. Nothing would force you to handle
it right away. Although I think in most cases it's far better to
do it when the error occurs(but this is my style). But when you
don't there would be at least a flag saying "this might fail"
that you and others could see. You can ignore that all the way up
the turtles, but at some point you are going to be like "I should
handle these errors".


 If you have to acknowledge it anyways, then might as well just 
 use returned errors because they are faster.


I guess you could think of nothrow as an acknowledgement. I'd
view it more like a warning to others. As I said before, I don't
think you should be *forced* to do anything. Handle it right away
and you don't have to mark your own function as 'throw'. Don't
handle it, then your function should be marked 'throw', and the
compiler can help others out and tell them to expect to have to
handle the exception at some point.

In regards to being faster, I'm not a big fan of exceptions in
the first place. This probably explains my perspective on them,
but I am familiar with their typical use case. And it's to
communicate errors. I'd much prefer something like what Andrei
presented during one of his C++ talks (Expected<T>). If I were to
design a language today, I might try to incorporate that somehow
with some semantic sugar and a "handle by default" mentality.
Jun 11 2015
next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 11 June 2015 at 21:57:36 UTC, Dave wrote:


 assume I misunderstood him.


Yeah, its whatever, maybe I am misunderstanding him and your 
original interpretation is correct.


 That is a legitimate concern, but I don't think it is correct.
 The transitive nature would enforce that you at least handle it
 at some point along the chain. Nothing would force you to handle
 it right away.


I think the sticky point is where this starts to hit virtual 
functions, function pointers, delegates and the such as its not 
really known if they are going to throw or not. You basically 
have to assume that they will throw which means annotating a lot 
of code that you didn't have to before.


 I guess you could think of nothrow as an acknowledgement. I'd
 view it more like a warning to others. As I said before, I don't
 think you should be *forced* to do anything. Handle it right 
 away
 and you don't have to mark your own function as 'throw'. Don't
 handle it, then your function should be marked 'throw', and the
 compiler can help others out and tell them to expect to have to
 handle the exception at some point.


Personally I would get annoyed by that because now I would have 
to go though and mark almost all of my code as throw. I strongly 
dislike having to add a bunch of annotations to my code just to 
get it to work.

I get that warning others is a good thing, but its also not 
necessary. Personally I would prefer something like that to be a 
tool, some one mentioned IDE's that can display what exceptions 
could be thrown, I think that would be nifty without bogging my 
code down with a bunch of annotations. Though the list it 
displays may be incomplete due to function pointers and such.
Jun 11 2015
prev sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Thursday, 11 June 2015 at 21:57:36 UTC, Dave wrote:

 In regards to being faster, I'm not a big fan of exceptions in
 the first place. This probably explains my perspective on them,
 but I am familiar with their typical use case. And it's to
 communicate errors. I'd much prefer something like what Andrei
 presented during one of his C++ talks (Expected<T>). If I were 
 to
 design a language today, I might try to incorporate that somehow
 with some semantic sugar and a "handle by default" mentality.


I've reordered your post a bit so I can refer to this part first. 
I think you and I refer to different things when we talk about 
returned errors, and with the definition I think you have in mind 
I do see how my arguments can look like the mumbling of a madman. 
So I'm going to clear it out first.

At a previous post 
here(http://forum.dlang.org/post/riiuqazmqfyftppmxxgz forum.dlang.org), 
I've said that "I'm not talking about C style 
return-error-code-and-write-the-actual-result-into-a-variable
passed-by-reference 
- functional languages like Haskell, Scala and Rust have shown 
that monadic sum types of result/error are both safe(...) and 
easy to use(...)"

What I refer by "monadic sum types of result/error" is pretty 
similar in concept to Expected<T>, though what I in mind is much 
closer to what functional languages have, which makes allows both 
easier handling inside expressions and a guarantee that the 
underlying result will only be used in a path where it was 
checked that there is no error or after the user explicitly said 
it's OK to convert it to an exception.

This is what's done in Rust(except it's converted to panics, 
which are harder to log and contain than exceptions), it can be 
done in D, and of course a new language that chooses this 
approach can have syntax for it. Here is an example for how it 
would be used in D:

     Expected!int parseInt(string txt) {
         if (/*parsing successful*/) {
             return expected(parsedValue);
         } else {
             return error();
         }
     }

     // Propogation - functional style
     Expected!string formatNextValueText(string origNumber) {
         return parseInt(origNumber).ifOK!(
             // good path
             parsedValue => "After %s comes %s".format(
                 parsedValue, parsedValue + 1).expected,
             // error path
             () => error());
     }

     // Propogation - imperative style
     Expected!string formatNextValueText(string origNumber) {
         auto parsedValue = parseInt(origNumber);
         if (auto parsedValuePtr = parsedValue.getIfOK()) {
             return "After %s comes %s".format(
                 *parsedValuePtr, *parsedValuePtr + 1).expected,
         } else {
             return error();
         }
     }

     // Convertion to exception
     string formatNextValueText(string origNumber) {
         // This will throw an exception if the parsing, and
         // return the parsed value if it succeeded:
         auto parsedValue = parseInt(origNumber).enforceOK();
         return "After %s comes %s".format(
             *parsedValue, *parsedValue + 1);
     }


Now to answer the rest of your post, which actually came first:


 He is saying that now anything that throws will not only be 
 slow but also have the same limitations as returned errors.


 "nothrow by default is combining the slowness of exceptions with
 the limitness of returned errors."

 He literally said combine the slowness of exceptions. So I don't
 know how to read that other than he said it's slow. But perhaps 
 I
 am just misunderstanding his wording, so perhaps it's best I 
 just
 assume I misunderstood him.


I also literally said "with the limitness of returned errors.". 
That part is important part of the sentence. My point is that the 
exception mechanism is much less limited from the returned value 
mechanism, because it lets you handler the error in a higher 
level without modifying the middle levels to acknowledge it. The 
price for this is slowness.

The benefits of nothrow by default come naturally with returned 
errors - the users can't implicitly ignore them, and since the 
possible errors are encoded into the return type any tool that 
can display the return type can show you these errors.

With nothrow by default, you are paying the performance price of 
an exception mechanism, and then do extra work to add to it the 
limitations of returned errors, just so you can get the benefits 
that come naturally with returned errors. Wouldn't it be better 
to just use returned errors in the first place?


 but also have the same limitations as returned errors


 That is a legitimate concern, but I don't think it is correct.
 The transitive nature would enforce that you at least handle it
 at some point along the chain. Nothing would force you to handle
 it right away. Although I think in most cases it's far better to
 do it when the error occurs(but this is my style). But when you
 don't there would be at least a flag saying "this might fail"
 that you and others could see. You can ignore that all the way 
 up
 the turtles, but at some point you are going to be like "I 
 should
 handle these errors".


 If you have to acknowledge it anyways, then might as well just 
 use returned errors because they are faster.


 I guess you could think of nothrow as an acknowledgement. I'd
 view it more like a warning to others. As I said before, I don't
 think you should be *forced* to do anything. Handle it right 
 away
 and you don't have to mark your own function as 'throw'. Don't
 handle it, then your function should be marked 'throw', and the
 compiler can help others out and tell them to expect to have to
 handle the exception at some point.


This is not very different than returned errors: you either 
handle the error or change the function's signature so it can 
pass the error to it's caller.

The big benefit of unchecked exceptions is that they require 
minimal effort to use - when I code and encounter a path that you 
can't handle, I just throw an exception(I can also use helper 
assert/enforce functions). I don't need to interrupt the flow and 
start adding `throws` all over the project, making my brain do a 
"context switch" that makes me forget the immediate thing I was 
working on, and increasing the chances of my commit conflicting 
with other concurrent commits(because it was touching general 
functions all over the place). No - I throw the exception, and 
leave worrying to how it will be handled to later.

The alternative is not that I leave my current task to implement 
something that'll handle the exception at the right place - the 
alternative is that I continue my current task without throwing 
the exception, and only deal with it later on when something 
crashes or doesn't work properly.

Why? Because I have a task to do, and if every time I encounter a 
place that *might* indicate an error I'll need to make sure that 
error is handled, I won't be able to focus on the actual task.

Out of the unhandled error possibilities, exceptions are easiest 
to fix when they do happen. Forbidding unchecked exceptions 
doesn't mean there are no errors - just that you don't have this 
amazing mechanism for tracking and debugging them.
Jun 11 2015
parent "Dave" <Whatever whatever.com> writes:
It should be noted that functional languages that utilize monads
often make you consider the exceptional case, and this is
enforced by the compiler (sound familiar?)


 I also literally said "with the limitness of returned errors.". 
 That part is important part of the sentence. My point is that 
 the exception mechanism is much less limited from the returned 
 value mechanism, because it lets you handler the error in a 
 higher level without modifying the middle levels to acknowledge 
 it. The price for this is slowness.

 The benefits of nothrow by default come naturally with returned 
 errors - the users can't implicitly ignore them, and since the 
 possible errors are encoded into the return type any tool that 
 can display the return type can show you these errors.

 With nothrow by default, you are paying the performance price 
 of an exception mechanism, and then do extra work to add to it 
 the limitations of returned errors, just so you can get the 
 benefits that come naturally with returned errors. Wouldn't it 
 be better to just use returned errors in the first place?


Perhaps I am missing something big, but I don't see the
performance price that is being paid with nothrow as an
annotation nor as a default. Even with your explanation. No throw
means no throw. No expensive exception mechanism is used. You can
still return whatever you want. You are just guaranteeing no
exceptions.


 This is not very different than returned errors: you either 
 handle the error or change the function's signature so it can 
 pass the error to it's caller.


I agree for the most part on this.


 The big benefit of unchecked exceptions is that they require 
 minimal effort to use - when I code and encounter a path that 
 you can't handle, I just throw an exception(I can also use 
 helper assert/enforce functions). I don't need to interrupt the 
 flow and start adding `throws` all over the project, making my 
 brain do a "context switch" that makes me forget the immediate 
 thing I was working on, and increasing the chances of my commit 
 conflicting with other concurrent commits(because it was 
 touching general functions all over the place). No - I throw 
 the exception, and leave worrying to how it will be handled to 
 later.


The one issues with returned errors is unless you wrap it up in
something like Expected<T> or a specialized struct of some sort,
you can only return one thing in many languages. Even if the
language supports a tuple syntax, in the desired case (where
things work as expected) you return information that is unneeded
(the error). This is something that the Expected<T> object
considers. I'd say this is where exceptions are beneficial (not
the fact that you can throw them and not worry about them),
because you only pay the price when needed, at the expense of
some overhead with the exception handler and the code slowing on
the exceptional path. Take as a counter example of Go which uses
multiple return values to inform users of errors, you get
information that is only useful sometimes.


 The alternative is not that I leave my current task to 
 implement something that'll handle the exception at the right 
 place - the alternative is that I continue my current task 
 without throwing the exception, and only deal with it later on 
 when something crashes or doesn't work properly.

 Why? Because I have a task to do, and if every time I encounter 
 a place that *might* indicate an error I'll need to make sure 
 that error is handled, I won't be able to focus on the actual 
 task.


Dealing with the exceptional case should be "part" of the task.
It may be boring, but that is how you write solid code. Because
if your sequence of logic requires Parse() to succeed to get a
result to pass into B(), but Parse() fails, continuing on and
using B() may cause issues. Now throwing an exception is really
useful in this case because you guarantee that you aren't going
to do B with undefined data or defaulted data. However, unless it
is clear, people may not know they need to catch an exception.
Thus the exception propagates up to the top and we now have a
problem.

So now imagine a call server where we have multiple processes
each handling thousands of calls. A call comes in and during the
processing of the call an error occurred and an exception is
thrown. Now if you catch the exception at it's source, no
problem. You can just log that something unexpected happen and
not accept that specific call. If you don't handle the exception
and it manages to escape to the top of the process, bye bye to
all those calls rather than just one. You now have thousands of
upset customers rather than one.

If you are using returned errors and you ignore the error for
some reason and continue on with the process and try to use a
pointer that you expected to be set by a function in which you
didn't check the error for, bye bye thousands of calls (if your
lucky...). Long story short. Respect your errors.

You can often get away with not catching exceptions in UI code,
because often times the UI code intercepts the exception at an
upper level and prints out an error in a window or something.
This becomes trickier in server code.


 Out of the unhandled error possibilities, exceptions are 
 easiest to fix when they do happen. Forbidding unchecked 
 exceptions doesn't mean there are no errors - just that you 
 don't have this amazing mechanism for tracking and debugging 
 them.


Why have unhandled errors in the first place? Design this problem
away.
Jun 11 2015
prev sibling next sibling parent reply "jmh530" <john.michael.hall gmail.com> writes:
On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote:


 Just a thought from a random spectator ;)


Interesting perspective. While I find the plethora of keywords in 
D a tad confusing (nowhere near as confusing as rust's 
borrowing!), I'm not sure it would necessarily mean that D would 
be discarded in favor of something else. There's a lot to like 
about D as a language.

More generally, it's a question of what paradigm you are trying 
to enforce. I think your paradigm is really about minimizing 
bugs, rather than necessarily wanting restriction. Nevertheless, 
I'm sure there are many who agree. My preference is a bit 
simpler: I want to write good code without a lot of clutter. So I 
think that the default option should be whatever enforces that. I 
don't see a reason why you should have a whole string of keywords 
before every function. Anything that simplifies that is a 
positive to me.

To your grepable point, another alternative is that you allow the 
annotations in either case so you could have a throw keyword and 
a nothrow keyword. If nothrow is default, you could still put it 
in there and then grep to change it to throw later. For that 
matter, it might be interesting to have some way to specify the 
default behavior for each .d file.
Jun 10 2015
next sibling parent "Dave" <whatever whatever.com> writes:
On Wednesday, 10 June 2015 at 21:09:23 UTC, jmh530 wrote:

 On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote:


 Just a thought from a random spectator ;)


 Interesting perspective. While I find the plethora of keywords 
 in D a tad confusing (nowhere near as confusing as rust's 
 borrowing!),


I won't try to defend Rust's syntax (and they certainly don't let
you opt out of a whole lot).


 I'm not sure it would necessarily mean that D would be 
 discarded in favor of something else. There's a lot to like 
 about D as a language.


If that something is more favorable why would they not? Only
answers to that is stubbornness and resistance to change ;)


 More generally, it's a question of what paradigm you are trying 
 to enforce. I think your paradigm is really about minimizing 
 bugs, rather than necessarily wanting restriction.


If someone wants to annotate  system and do all the dirty things
they want. So be it. At least others that use their code
(assuming transitiveness) knows that they are doing it.


 Nevertheless, I'm sure there are many who agree. My preference 
 is a bit simpler: I want to write good code without a lot of 
 clutter. So I think that the default option should be whatever 
 enforces that. I don't see a reason why you should have a whole 
 string of keywords before every function.


That would depend on the syntax of the language mostly. I'm sure
if designed well, you could avoid unnecessary "clutter". Maybe by
allow people to define their own attributes that can be used in
place of many attributes (as long as it is easy to look it up).


 To your grepable point, another alternative is that you allow 
 the annotations in either case so you could have a throw 
 keyword and a nothrow keyword.


Problem with "opt-in" constructs, is if people don't have to they
generally "opt-out". So expect the default to be the most common.
You might get library writers writing idiomatically, but I
wouldn't expect it from an application development side. Adding
an extra keyword per function is probably not that big of a deal
in the long run. Especially if it prevents code.

All of this is kind of late for D. Waaaay too many breaking 
changes. But maybe something for D3...;)
Jun 10 2015
prev sibling parent "Dave" <whatever whatever.com> writes:
 There's a lot to like about D as a language.


Agreed.
Jun 10 2015
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote:

 D did get thread local storage correct, but I think people are
 starting to get on board with having restrictions by default
 because it prevents bugs (and the annotations are grepable). 
 Kind
 of like what Rust is doing. If this is the case, D might find
 itself being discarded in favor of languages that offer better
 guarantees.


Chances are they prevent one bugs at the cost of causing other 
bugs and raising cost of software development, which in the end 
may be not a better guarantee. And you can't prevent bugs by 
learning languages instead of, well, bugs.
Jun 11 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote:

 Another backwards annotation is nothrow. I don't really care if 
 something doesn't throw, I care when it throws, because then I 
 have to do
 something (or my program may crash unexpectedly).


I recently debugged such "no crash" bug: the code decided that 
the program shouldn't crash and caught exception and silenced it, 
the program indeed didn't crash, but misbehaved. It was a 
critical bug, which blew into the face of the customer, there was 
nothing in the log, we had to connect to the customer's database 
and debugged with catching first chance exceptions. What we 
should do if we had no access to the customer's database? If the 
code wouldn't catch the exception, the application would crash 
and we would have an entry in the log and debugged it quickly. 
That's how nothrow works in practice.
Jun 11 2015