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 
system and #2).
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, NullPointerException that plagues Java applications. C# has the 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 has used Visual Studio and C# will tell you a nice feature is that Visual Studio can tell you what exceptions get thrown when calling a method (very useful). C# does it in a different way, but 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, NullPointerException that plagues Java applications. C# has the 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
 has used Visual Studio and C# will tell you a nice feature is
 that Visual Studio can tell you what exceptions get thrown when 
 calling a
 method (very useful). C# does it in a different way, but 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?
Disagree. Traditionally also handled by throwing exceptions. C# 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, NullPointerException that plagues Java applications. C# has the 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:
 Disagree. Traditionally also handled by throwing exceptions. C#
 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:
 Disagree. Traditionally also handled by throwing exceptions. C#
 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:
 Disagree. Traditionally also handled by throwing exceptions. C#
 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