www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why D is not popular enough?

reply Emre Temelkuran <etemelkuran gmail.com> writes:
For years, i was travelling along Golang, Rust, Perl, Ruby, 
Python, PHP, JScript, JVM Languages.
Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
more that i can't remember.

I'm 24 years old, my first lang was PHP and VBasic then C,C++ and 
i first heard about D after 2005 when i was 14-15 years old.

I always ignored D, i prejudiced that D failed, because nobody 
were talking about it. I decided to check it yesterday, it has 
excellent documentation, i almost covered all aspects. I think D 
is much better than the most of the other popular langs. It's 
clear as JScript, Swift, Julia and PHP, also it's capable enough 
as C,C++. I think D deserves a bigger community.

Why people need NodeJS, Typescript etc, when there is already 
better looking lang?
Everyone talking about how ugly is Golang. So why people are 
going on it? Performance concerns? Why languages that are not 
backed up by huge companies are looking like they failed?
Aug 01 2016
next sibling parent reply ciechowoj <keepitsimplesirius gmail.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

 I'm 24 years old, my first lang was PHP and VBasic then C,C++ 
 and i first heard about D after 2005 when i was 14-15 years old.

 I always ignored D, i prejudiced that D failed, because nobody 
 were talking about it. I decided to check it yesterday, it has 
 excellent documentation, i almost covered all aspects. I think 
 D is much better than the most of the other popular langs. It's 
 clear as JScript, Swift, Julia and PHP, also it's capable 
 enough as C,C++. I think D deserves a bigger community.

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?
There were similar threads recently. https://forum.dlang.org/thread/tvrngtghzogqoeqvkovo forum.dlang.org https://forum.dlang.org/thread/erfyeseptuxjkpihqcsg forum.dlang.org https://forum.dlang.org/thread/qaufzyhrngrjfkhobcnk forum.dlang.org TL;DR There is no simple answer to your questions.
Aug 01 2016
parent reply eugene <egordeev18 gmail.com> writes:
it would be ok if someone in the community would try to make 
things clear about old problems of D1 and the current state of 
D2, so to remove old(and maybe new) hype about the language
Aug 01 2016
parent reply Emre Temelkuran <etemelkuran gmail.com> writes:
On Monday, 1 August 2016 at 16:43:40 UTC, eugene wrote:
 it would be ok if someone in the community would try to make 
 things clear about old problems of D1 and the current state of 
 D2, so to remove old(and maybe new) hype about the language
All of you are right. I just saw that on stats, Apple Swift 3 is fastest growing language ever and if you check what's behind, it's D.
Aug 01 2016
parent Guillaume Piolat <first.last gmail.com> writes:
On Monday, 1 August 2016 at 18:54:08 UTC, Emre Temelkuran wrote:
 I just saw that on stats, Apple Swift 3 is fastest growing 
 language ever and if you check what's behind, it's D.
Swift is the outlier here in the language landscape. - pushed and marketed by Apple as an important lockin into their ecosystem (why invest so much effort else?) - replaces Objective-C which is not the most pleasant or sensical language - explicitely targets newcomers to programming, in XCode a new Swift program is a "Playground" - consultants don't want to be left behind and now sell Swift to clients Swift could succeed whatever it does.
Aug 02 2016
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

 I'm 24 years old, my first lang was PHP and VBasic then C,C++ 
 and i first heard about D after 2005 when i was 14-15 years old.

 I always ignored D, i prejudiced that D failed, because nobody 
 were talking about it. I decided to check it yesterday, it has 
 excellent documentation, i almost covered all aspects. I think 
 D is much better than the most of the other popular langs. It's 
 clear as JScript, Swift, Julia and PHP, also it's capable 
 enough as C,C++. I think D deserves a bigger community.

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?
Dear Emre, we have had such threads in the past and experience shows that there will be a huge non-productive debate about it. I think all the people here agree that "D deserves a bigger community", but everyone has a different view on how to achieve that. My personal opinion is that we all can do a tiny contribution to make D more popular. For example you should start actively promoting D at your university, workplace and among friends and maybe you can even start a local Meetup or developer group. Of course, the online pedant is actively complaining on a discussion, site, ... if D is not listed or mentioned in a bad light. If you have more time, doing great projects or libraries in D will help it's adaption too ;-) In any case I highly encourage you to have a look at Walter and Andrei's Action List and contribute to it. You know, writing a unittest for a non-covered line in Phobos takes around the time to post here, but it's a helpful contribution! https://wiki.dlang.org/Wish_list https://wiki.dlang.org/Vision/2016H2_(Draft) What I was trying to say, we shouldn't waste time arguing about whether D is awesome, but make it even more awesome ;-)
Aug 01 2016
parent Chris <wendlec tcd.ie> writes:
On Monday, 1 August 2016 at 16:09:58 UTC, Seb wrote:
 On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 [...]
Dear Emre, we have had such threads in the past and experience shows that there will be a huge non-productive debate about it. I think all the people here agree that "D deserves a bigger community", but everyone has a different view on how to achieve that. My personal opinion is that we all can do a tiny contribution to make D more popular. For example you should start actively promoting D at your university, workplace and among friends and maybe you can even start a local Meetup or developer group. Of course, the online pedant is actively complaining on a discussion, site, ... if D is not listed or mentioned in a bad light.
If D deserves criticism, don't complain (it's not a religion). But if the comparisons are unfair and / or half-truths are spread, then yes, one should complain and set the record straight. Apart from that, I agree with you. Just use it and, if possible, improve it. The more the merrier :)
 If you have more time, doing great projects or libraries in D 
 will help it's adaption too ;-)

 In any case I highly encourage you to have a look at Walter and 
 Andrei's Action List and contribute to it. You know, writing a 
 unittest for a non-covered line in Phobos takes around the time 
 to post here, but it's a helpful contribution!

 https://wiki.dlang.org/Wish_list
 https://wiki.dlang.org/Vision/2016H2_(Draft)

 What I was trying to say, we shouldn't waste time arguing about 
 whether D is awesome, but make it even more awesome ;-)
Aug 02 2016
prev sibling next sibling parent reply eugene <egordeev18 gmail.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

 I'm 24 years old, my first lang was PHP and VBasic then C,C++ 
 and i first heard about D after 2005 when i was 14-15 years old.

 I always ignored D, i prejudiced that D failed, because nobody 
 were talking about it. I decided to check it yesterday, it has 
 excellent documentation, i almost covered all aspects. I think 
 D is much better than the most of the other popular langs. It's 
 clear as JScript, Swift, Julia and PHP, also it's capable 
 enough as C,C++. I think D deserves a bigger community.

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?
i suppose it was simply because D v.1 failed and then authors created a new version of D (v.2) which is current, but the name "D" stayed the same, so, people remember some drawbacks of D v.1 and think that D v.2 has the same drawbacks, maybe without even trying D v.2
Aug 01 2016
parent reply yuioyyoi <yuioyyoi yuioyyoi.se> writes:
On Monday, 1 August 2016 at 16:16:03 UTC, eugene wrote:
 On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 i suppose it was simply because D v.1 failed and then authors 
 created a new version of D (v.2) which is current, but the name 
 "D" stayed the same, so, people remember some drawbacks of D 
 v.1 and think that D v.2 has the same drawbacks, maybe without 
 even trying D v.2
Also before it was closed source and the whole infrastructure (repository, testing , bug report) was shitty. Bright admited himself that going to GH and using bugzilla was salvatory. So even if it existed before, you can consider early 2010's as a second birth. (there's a non technical conference posted earlyer this year where he talked about this).
Aug 01 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 1 August 2016 at 16:25:52 UTC, yuioyyoi wrote:
 Also before it was closed source
D was never closed source. It used to be only the D parts were open, distributed under the artistic license in the very early days and you couldn't build the whole thing, but it has always been there.
Aug 01 2016
prev sibling parent eugene <egordeev18 gmail.com> writes:
On Monday, 1 August 2016 at 16:25:52 UTC, yuioyyoi wrote:
 On Monday, 1 August 2016 at 16:16:03 UTC, eugene wrote:
 On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran 
 wrote:
 i suppose it was simply because D v.1 failed and then authors 
 created a new version of D (v.2) which is current, but the 
 name "D" stayed the same, so, people remember some drawbacks 
 of D v.1 and think that D v.2 has the same drawbacks, maybe 
 without even trying D v.2
Also before it was closed source and the whole infrastructure (repository, testing , bug report) was shitty. Bright admited himself that going to GH and using bugzilla was salvatory. So even if it existed before, you can consider early 2010's as a second birth. (there's a non technical conference posted earlyer this year where he talked about this).
since that time (2010) even some student guys released exokernel O.S. written in D v.2 about 4 years ago (~2013): https://github.com/xomboverlord/xomb i don't know if it is practical, but still nice try
Aug 01 2016
prev sibling next sibling parent reply eugene <egordeev18 gmail.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

 I'm 24 years old, my first lang was PHP and VBasic then C,C++ 
 and i first heard about D after 2005 when i was 14-15 years old.

 I always ignored D, i prejudiced that D failed, because nobody 
 were talking about it. I decided to check it yesterday, it has 
 excellent documentation, i almost covered all aspects. I think 
 D is much better than the most of the other popular langs. It's 
 clear as JScript, Swift, Julia and PHP, also it's capable 
 enough as C,C++. I think D deserves a bigger community.

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?
maybe another reason is that people who tried to use D still think it is unstable
Aug 01 2016
parent reply Charles Hixson via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 08/01/2016 09:37 AM, eugene via Digitalmars-d wrote:
 On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 For years, i was travelling along Golang, Rust, Perl, Ruby, Python, 
 PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many more 
 that i can't remember.

 I'm 24 years old, my first lang was PHP and VBasic then C,C++ and i 
 first heard about D after 2005 when i was 14-15 years old.

 I always ignored D, i prejudiced that D failed, because nobody were 
 talking about it. I decided to check it yesterday, it has excellent 
 documentation, i almost covered all aspects. I think D is much better 
 than the most of the other popular langs. It's clear as JScript, 
 Swift, Julia and PHP, also it's capable enough as C,C++. I think D 
 deserves a bigger community.

 Why people need NodeJS, Typescript etc, when there is already better 
 looking lang?
 Everyone talking about how ugly is Golang. So why people are going on 
 it? Performance concerns? Why languages that are not backed up by 
 huge companies are looking like they failed?
maybe another reason is that people who tried to use D still think it is unstable
I have never experienced D as being unstable. I have, however, experienced problems using various libraries with D. Whenever you need to use a foreign library you invite problems, but D wrappers around libraries have a habit of showing up and then not being maintained. THAT has caused me problems...enough problems that if I don't need the performance I'll pick Python. As for D1 being a failure...that depends on what you wanted to do with it. Until it started being influenced by Tango I was quite pleased, and even Tango wasn't all bad. It had a few good unicode tools that haven't yet been incorporated into D2. D2 I'm less satisfied with, though that may just be a rosy-glasses memory of D1. Most of my needs aren't fancy compile time techniques but rather run-time techniques. (I did mention Python as the alternate rather than C++.) But what the best language is depends a lot on what you are doing. To talk in terms of other languages, Objective C is a better language for my needs than C++. It isn't really because of the commitment to 16-bit unicode, but outside of that... So in either version of D I have mixed uses of 8-bit unicode and 32-bit unicode. D seems to handle this better than any other language. And it's got lots of other nice features. I love garbage collection, as I hate memory management. I'm less attracted to ranges as implemented by D, though I like them in Ruby and Python. A lot of this has to do with what gets done at compile time and what gets done at run time, though, so for me that just means that I'd rather avoid needing to use ranges when I need speed. For my purposes the template language is overblown, and I'd be satisfied with a much simpler form with some run-time supplementation...but different people would like different simplifications even among those who want it to be simpler. Traits, e.g., I find indispensable (especially isPOD) and I need to be able to test THAT at compile time, but most people who talk about templates don't even mention traits. Many languages become significant when there is an popular application or library that depends on them. Others grow slowly. There *is*, however, a network effect, so that popular languages tend to become more popular, and this is often driven by a "niche" application (a place where there is no competition, so everyone who wants to work in that niche must use that language). An example of this, if you go back to before it was popular, is JavaScript.
Aug 01 2016
parent Chris <wendlec tcd.ie> writes:
On Monday, 1 August 2016 at 18:21:05 UTC, Charles Hixson wrote:

 [...]
I have never experienced D as being unstable. I have, however, experienced problems using various libraries with D. Whenever you need to use a foreign library you invite problems, but D wrappers around libraries have a habit of showing up and then not being maintained. THAT has caused me problems...enough problems that if I don't need the performance I'll pick Python. [...]
However, the good thing about D is that you don't need to use all the idioms, if you really don't want to. You can write simple C-like code with loops. You don't need to have hundreds of template constraints, if you don't want/need to. To get started with D you don't need to be able to master template constraints, CTFE and ranges from day one. This knowledge will come naturally as you go along, but it's not a conditio sine qua non. [snip]
Aug 02 2016
prev sibling next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

 I'm 24 years old, my first lang was PHP and VBasic then C,C++ 
 and i first heard about D after 2005 when i was 14-15 years old.

 I always ignored D, i prejudiced that D failed, because nobody 
 were talking about it. I decided to check it yesterday, it has 
 excellent documentation, i almost covered all aspects. I think 
 D is much better than the most of the other popular langs. It's 
 clear as JScript, Swift, Julia and PHP, also it's capable 
 enough as C,C++. I think D deserves a bigger community.

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?
I can't speak for everyone, but for my purposes, D isn't ready for use, because it lacks ios/android support. AFAIK, ios support is coming along nicely, but still isn't production ready, and isn't merged into LDC. I think D does a lot of things very well, but seems to be suffering from lack of manpower at the moment, which results in large holes like lack of mobile platform support, and unfinished features. The 'scope' keyword, for example, is legal in D syntax, but doesn't actually do anything. While this problem may be practically benign, its a huge red flag, which can be very off-putting to newcomers. I could only speculate as to why exactly D isn't more popular. When I look at things like D's CTFE, C++ interop, templates, and reflection, my honest reaction is..Holy shit, this is awesome...why isn't this language more popular ?_? Maybe it just needs more time.
Aug 01 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 1 August 2016 at 19:33:48 UTC, bitwise wrote:
 'scope' keyword, for example, is legal in D syntax, but doesn't 
 actually do anything.
sorry, but you are wrong here. of course, it does HAVE effect. `void foo (scope delegate () boo)` this means that compiler should not allocate a closure for delegate, as `foo` is promising that it will not store `boo` anywhere. `scope a = new A();` this does what you think it does, althru it is deprecated in favor of `scoped!` template.
Aug 02 2016
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Tuesday, 2 August 2016 at 07:50:29 UTC, ketmar wrote:
 On Monday, 1 August 2016 at 19:33:48 UTC, bitwise wrote:
 'scope' keyword, for example, is legal in D syntax, but 
 doesn't actually do anything.
sorry, but you are wrong here. of course, it does HAVE effect. `void foo (scope delegate () boo)` this means that compiler should not allocate a closure for delegate, as `foo` is promising that it will not store `boo` anywhere. `scope a = new A();` this does what you think it does, althru it is deprecated in favor of `scoped!` template.
I know about these cases, but didn't bother mentioning them, as they are outliers. Also, they do not make my point any less valid. The following code compiles without errors(outputs 1): class Foo{ int val; this(){ val = 1; } } Foo x; void bar(scope Foo foo) { x = foo; } void main() { bar(new Foo()); writeln(x.val); } 'scope' is clearly not functioning as advertised, as is the case for many aspects of D. Again, users shouldn't have to deal with this sort of thing. I doubt that anyone outside of would-be D contributors will continue to use the language beyond the point where they find a hole like this. Bit
Aug 03 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 3 August 2016 at 19:57:13 UTC, bitwise wrote:
 On Tuesday, 2 August 2016 at 07:50:29 UTC, ketmar wrote:
 On Monday, 1 August 2016 at 19:33:48 UTC, bitwise wrote:
 'scope' keyword, for example, is legal in D syntax, but 
 doesn't actually do anything.
sorry, but you are wrong here. of course, it does HAVE effect.
I know about these cases, but didn't bother mentioning them, as they are outliers. Also, they do not make my point any less valid.
it does. actually, it makes your point completely false.
Aug 03 2016
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Wednesday, 3 August 2016 at 21:19:21 UTC, ketmar wrote:
 On Wednesday, 3 August 2016 at 19:57:13 UTC, bitwise wrote:
 On Tuesday, 2 August 2016 at 07:50:29 UTC, ketmar wrote:
 On Monday, 1 August 2016 at 19:33:48 UTC, bitwise wrote:
 'scope' keyword, for example, is legal in D syntax, but 
 doesn't actually do anything.
sorry, but you are wrong here. of course, it does HAVE effect.
I know about these cases, but didn't bother mentioning them, as they are outliers. Also, they do not make my point any less valid.
it does. actually, it makes your point completely false.
Nice troll.
Aug 03 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 4 August 2016 at 00:57:13 UTC, bitwise wrote:
 On Wednesday, 3 August 2016 at 21:19:21 UTC, ketmar wrote:
 On Wednesday, 3 August 2016 at 19:57:13 UTC, bitwise wrote:
 On Tuesday, 2 August 2016 at 07:50:29 UTC, ketmar wrote:
 On Monday, 1 August 2016 at 19:33:48 UTC, bitwise wrote:
 'scope' keyword, for example, is legal in D syntax, but 
 doesn't actually do anything.
sorry, but you are wrong here. of course, it does HAVE effect.
I know about these cases, but didn't bother mentioning them, as they are outliers. Also, they do not make my point any less valid.
it does. actually, it makes your point completely false.
Nice troll.
not at all. "a is false." "but a is true!" "ah, nevermind, continue execution." one invalid point makes the whole technical argument false. it is natural to dismiss it completely: author may wanted to do a good thing, but he didn't bother to check his statements, so the whole thing becomes invalid. instead of trying to dissect the thing (and risking to hit author's response like "you took only part of my statement instead of taking the whole picture!"), the whole thing should be rejected. author can come with fixed patch^w statement later, of course.
Aug 04 2016
prev sibling next sibling parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
On 8/1/2016 11:31 AM, Emre Temelkuran wrote:
 For years, i was travelling along Golang, Rust, Perl, Ruby, Python, PHP,
 JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many more that
 i can't remember.

 I'm 24 years old, my first lang was PHP and VBasic then C,C++ and i
 first heard about D after 2005 when i was 14-15 years old.

 I always ignored D, i prejudiced that D failed, because nobody were
 talking about it. I decided to check it yesterday, it has excellent
 documentation, i almost covered all aspects. I think D is much better
 than the most of the other popular langs. It's clear as JScript, Swift,
 Julia and PHP, also it's capable enough as C,C++. I think D deserves a
 bigger community.

 Why people need NodeJS, Typescript etc, when there is already better
 looking lang?
 Everyone talking about how ugly is Golang. So why people are going on
 it? Performance concerns? Why languages that are not backed up by huge
 companies are looking like they failed?
I am a C++ expert who has looked at D in the past. Perhaps my reasons for not programming in D may be taken as some of the reasons why D "is not popular enough". My opinions are not meant to start a flame war, even if some of my insights may be harsh to those who do use D. They will hopefully give some idea of why and where D went wrong in trying to appeal to the general intelligent programmer as a programming language. 1) Until very recently the documentation for D has been very substandard. I do notice better documentation both on the web site now and a few more books on D as a programming language. For a very long time after D was created, even after version 2 was created, there was essentially no decent documentation at all. If you are trying to promote the use of a computer language to the general public you must create first-rate documentation and explanation of your computer language from the very beginning. Without this first-rate documentation your programming language, no matter how good it might be, is just a toy to those who want to play around with it and try it out. This is the case that D promoted for a very long time, so the expectation that D was going to become popular to the programming public with such poor documentation was just foolish. C took off as a programming language for the general programming when Kernigan and Ritchie wrote their classic book and C++ took off as a programming language for the general public when Stroustrop and subsequently Lippman wrote their classuc books. While I think that Alexandrescu's book is decent it is not written at the level of these others. 2) While I greatly respect the programming abilities of Mr. Bright and Mr. Alexandrescu and their hard work in creating and improving D, having followed both from the C++ world, the arrogance by which D was initially and repeatedly compared against C/C++ has been totally out of place since the beginning. C++ is a very good language and the effort made to denigrate it with specious and ridiculously false arguments about it vis-a-vis D as a programming language has almost irreparably hurt D as a serious programming language irrespective of its actual abilities or weaknesses. You are not going to appeal to the really intelligent programmers out there if you are not honest and rigorous in discussion of your own programming language in relation to others. All that you end up doing is to alienate anyone with real programming intelligence by the tactics that D has taken over the years with such comparisons. 3) D has suffered greatly because it has had too many moving targets as if constant change to something slightly better is going to endear programmers to using a computer language. Programmers need stability. The needed to know that if they are using a programming language they are getting a particular standard at a particular time with particular libraries that work. They also need backward compatibility when things change. D appears to have presented an almost constantly moving target to this programmer, where adding/changing some feature is much more important than fixing problems and providing stability. 4) As a C++ programmer largely interested in C++ template programming, C++ concepts etc., and potential compile-time/run-time introspection, I have never found a compelling reason to use D rather than C++. I do recognize that C++'s template syntax is difficult and abstruse but I do not and have never seen where D improves upon these matters in any serious and rigorous way. This may be because the documentation about these areas in D is either very light or almost completely lacking. Even in Mr. Alexandrescu's book the discussion of these areas was very light in my estimation. So whatever D has to offer in these areas, if there are really impovements, is either lacking in the D documentation or does not really exist for me. Edward Diener
Aug 11 2016
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote:
 the arrogance by which D was initially and repeatedly compared 
 against C/C++ has been totally out of place since the C++ is a 
 very good language and the effort made to denigrate it with 
 specious and ridiculously false arguments about it vis-a-vis D 
 as a programming language has almost irreparably hurt D as a 
 serious programming language irrespective of its actual 
 abilities or weaknesses. You are not going to appeal to the 
 really intelligent programmers out there if you are not honest 
 and rigorous in discussion of your own programming language in 
 relation to others. All that you end up doing is to alienate 
 anyone with real programming intelligence by the tactics that D 
 has taken over the years with such comparisons.
 4) As a C++ programmer largely interested in C++ template 
 programming, C++ concepts etc., and potential 
 compile-time/run-time introspection, I have never found a 
 compelling reason to use D rather than C++.
This is a good example of why C++ programmers will never move to D. They are quite happy with the language. They want a better C++, and that's C++14, C++17, etc., not D.
Aug 11 2016
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 11 August 2016 at 20:16:04 UTC, bachmeier wrote:
 On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener 
 wrote:
 the arrogance by which D was initially and repeatedly compared 
 against C/C++ has been totally out of place since the C++ is a 
 very good language and the effort made to denigrate it with 
 specious and ridiculously false arguments about it vis-a-vis D 
 as a programming language has almost irreparably hurt D as a 
 serious programming language irrespective of its actual 
 abilities or weaknesses. You are not going to appeal to the 
 really intelligent programmers out there if you are not honest 
 and rigorous in discussion of your own programming language in 
 relation to others. All that you end up doing is to alienate 
 anyone with real programming intelligence by the tactics that 
 D has taken over the years with such comparisons.
I never understood how people can get their feelings hurt when criticising the language they program in. Either the criticised point is true and one accepts it or not, in that case a factual refutation can be done. Feeling offended is ridiculous.
 4) As a C++ programmer largely interested in C++ template 
 programming, C++ concepts etc., and potential 
 compile-time/run-time introspection, I have never found a 
 compelling reason to use D rather than C++.
This is a good example of why C++ programmers will never move to D. They are quite happy with the language. They want a better C++, and that's C++14, C++17, etc., not D.
Yeah, it's also known as Stockholm Syndrome :-)
Aug 12 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/12/16 4:59 AM, Patrick Schluter wrote:
 On Thursday, 11 August 2016 at 20:16:04 UTC, bachmeier wrote:
 On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote:
 the arrogance by which D was initially and repeatedly compared
 against C/C++ has been totally out of place since the C++ is a very
 good language and the effort made to denigrate it with specious and
 ridiculously false arguments about it vis-a-vis D as a programming
 language has almost irreparably hurt D as a serious programming
 language irrespective of its actual abilities or weaknesses. You are
 not going to appeal to the really intelligent programmers out there
 if you are not honest and rigorous in discussion of your own
 programming language in relation to others. All that you end up doing
 is to alienate anyone with real programming intelligence by the
 tactics that D has taken over the years with such comparisons.
I never understood how people can get their feelings hurt when criticising the language they program in. Either the criticised point is true and one accepts it or not, in that case a factual refutation can be done. Feeling offended is ridiculous.
I recall I had a similar reaction as Edward back in the day. No hurt feelings or anything, but the arguments made were so specious I'd roll my eyes whenever I saw them in the C++ forums. -- Andrei
Aug 12 2016
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu 
wrote:
 I recall I had a similar reaction as Edward back in the day. No 
 hurt feelings or anything, but the arguments made were so 
 specious I'd roll my eyes whenever I saw them in the C++ 
 forums. -- Andrei
I already roll my eyes at these threads and I've only been using D for like a year or two. I'm amazed you still have eyes at this point.
Aug 12 2016
prev sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu 
wrote:
 I recall I had a similar reaction as Edward back in the day. No 
 hurt feelings or anything, but the arguments made were so 
 specious I'd roll my eyes whenever I saw them in the C++ 
 forums. -- Andrei
So what changed? What gave you the initial kick to start moving from sideline scoffer to benevolent diarch? -Wyatt
Aug 12 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 12:31 PM, Wyatt wrote:
 On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu wrote:
 I recall I had a similar reaction as Edward back in the day. No hurt
 feelings or anything, but the arguments made were so specious I'd roll
 my eyes whenever I saw them in the C++ forums. -- Andrei
So what changed? What gave you the initial kick to start moving from sideline scoffer to benevolent diarch?
Walter and I talked and he said he'd be interested in working together on the kind of things I was interested in: generic programming, static introspection, and such. -- Andrei
Aug 12 2016
prev sibling next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Fri, 12 Aug 2016 08:59:14 +0000, Patrick Schluter wrote:
 I never understood how people can get their feelings hurt when
 criticising the language they program in.
 
 Yeah, it's also known as Stockholm Syndrome :-)
Because you specifically are criticizing the person directly, not the language they use, now.
Aug 12 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 12 August 2016 at 08:59:14 UTC, Patrick Schluter wrote:
 I never understood how people can get their feelings hurt when 
 criticising the language they program in. Either the criticised 
 point is true and one accepts it or not, in that case a factual 
 refutation can be done. Feeling offended is ridiculous.
http://www.independent.co.uk/arts-entertainment/tv/news/millennials-outraged-over-tv-show-portraying-millennials-as-outraged-a7184771.html
Aug 13 2016
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote:
 4) As a C++ programmer largely interested in C++ template 
 programming, C++ concepts etc., and potential 
 compile-time/run-time introspection, I have never found a 
 compelling reason to use D rather than C++. I do recognize that 
 C++'s template syntax is difficult and abstruse but I do not 
 and have never seen where D improves upon these matters in any 
 serious and rigorous way. This may be because the documentation 
 about these areas in D is either very light or almost 
 completely lacking. Even in Mr. Alexandrescu's book the 
 discussion of these areas was very light in my estimation. So 
 whatever D has to offer in these areas, if there are really 
 impovements, is either lacking in the D documentation or does 
 not really exist for me.
From the best of my knowledge you cannot do these things in in C++: https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE https://p0nce.github.io/d-idioms/#Enumerate-fields-with-__traits(allMembers)-and-static-foreach https://p0nce.github.io/d-idioms/#Embed-a-dynamic-library-in-an-executable https://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching https://p0nce.github.io/d-idioms/#String-interpolation-as-a-library https://p0nce.github.io/d-idioms/#Using-std.typecons.Flag-like-a-pro https://p0nce.github.io/d-idioms/#Voldemort-types Another expose of what you can achieve with these feature is the "D Cookbook" book. - Chapter 6 Forwarding methods with opDispatch - Chapter 8 Getting a list of child classes - Chapter 8 Determining if a module is available - Chapter 8 Using user defined attributes - Chapter 9 Creating user-defined literals - Chapter 9 Generating data structure from text diagrams Finally what we label "DbI" is quite the game changer: https://p0nce.github.io/d-idioms/#Design-by-Introspection
Aug 12 2016
next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 12 August 2016 at 09:38:13 UTC, Guillaume Piolat wrote:
 From the best of my knowledge you cannot do these things in in 
 C++:
The most important thing is what you can't do in D: read a Scott Meyers book.
Aug 12 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/12/16 10:19 AM, bachmeier wrote:
 On Friday, 12 August 2016 at 09:38:13 UTC, Guillaume Piolat wrote:
 From the best of my knowledge you cannot do these things in in C++:
The most important thing is what you can't do in D: read a Scott Meyers book.
That's the last thing D needs. -Steve
Aug 12 2016
parent reply Kagamin <spam here.lot> writes:
On Friday, 12 August 2016 at 14:24:06 UTC, Steven Schveighoffer 
wrote:
 On 8/12/16 10:19 AM, bachmeier wrote:
 On Friday, 12 August 2016 at 09:38:13 UTC, Guillaume Piolat 
 wrote:
 From the best of my knowledge you cannot do these things in 
 in C++:
The most important thing is what you can't do in D: read a Scott Meyers book.
That's the last thing D needs. -Steve
Though people could enjoy an article explaining how shared works :)
Aug 12 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/12/16 11:28 AM, Kagamin wrote:
 Though people could enjoy an article explaining how shared works :)
First you have to find someone who knows how it works :) All kidding aside, shared is pretty broken currently. If you want to know how it was *supposed* to work, you can read TDPL, though I'm not sure that's still valid. -Steve
Aug 12 2016
parent reply Kagamin <spam here.lot> writes:
On Friday, 12 August 2016 at 15:43:54 UTC, Steven Schveighoffer 
wrote:
 All kidding aside, shared is pretty broken currently. If you 
 want to know how it was *supposed* to work, you can read TDPL, 
 though I'm not sure that's still valid.
Ah, was it Andrei, who tried to sell the idea that shared is a silver bullet for concurrency problems? That can explain why we have two different views on shared. Looks like a repetition of the story with autodecoding (with similar rationale).
Aug 12 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, August 12, 2016 16:38:23 Kagamin via Digitalmars-d wrote:
 On Friday, 12 August 2016 at 15:43:54 UTC, Steven Schveighoffer

 wrote:
 All kidding aside, shared is pretty broken currently. If you
 want to know how it was *supposed* to work, you can read TDPL,
 though I'm not sure that's still valid.
Ah, was it Andrei, who tried to sell the idea that shared is a silver bullet for concurrency problems? That can explain why we have two different views on shared. Looks like a repetition of the story with autodecoding (with similar rationale).
Honestly, I don't think that shared is broken. It's just that once you've locked the appropriate mutex, you have to cast a way shared and make sure that no thread-local references to that data are still around when you release the lock. shared is doing its job of indicating when a variable isn't thread-local as well as preventing a number of incorrect operations on data that's shared across threads without being protected by a lock. What we're missing is a way safely have shared cast away for us so that we don't have to do the work of verifying that we're not screwing it up. synchronized classes as described in TDPL partially solve the problem in that they provide a safe, automatic way to remove one layer of shared - but it's only one layer, and it's never been implemented. It's the equivalent of having a set of operations that we'd like to be safe but are stuck as system, and we're forced to use trusted to deal with it. But folks get annoyed with shared, because they have to cast it away at the appropriate time. They just want it to magically work in a safe manner, and we simply haven't figured out how to do that. Instead, we have a way to segregate shared stuff and thus minimize how much code has to deal with the problems that come with sharing data across threads but which requires that you handle it carefully rather than having a way to just handle it safely, automatically. shared isn't perfect, but having thread-local by default is dowright fantastic, and when you have to deal with shared, you mostly doing the same sorts of things that you're supposed to be doing in C++. It's just that you have to cast away shared to operate on the object while the mutex is locked. IMHO, the biggest problem with shared is that the related types in druntime (like the mutexes and condition variables) aren't marked with it properly rather than shared itself being fundamentally flawed. - Jonathan M Davis
Aug 12 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!) The thing that is NOT broken is unshared. There's literally not much you can do with shared, and what you can do isn't consistent or useful. It needs lots of attention. -Steve
Aug 12 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
Aug 12 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
?! Isn't it obvious that assigning to a shared int must require atomicOp or a cast? `x = x + 1;` clearly has a race condition otherwise. T -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen
Aug 12 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 02:01 PM, H. S. Teoh via Digitalmars-d wrote:
 On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
?! Isn't it obvious that assigning to a shared int must require atomicOp or a cast? `x = x + 1;` clearly has a race condition otherwise.
It is not to me, and it does not seem like a low-level race condition to me (whereas ++x is). Currently the compiler must ensure that an atomic read and an atomic write are generated for x. Other than that, it is the responsibility of the user. The use of "shared" does not automatically relieve the user from certain responsibilities. I agree that it would be nice to have stronger protection against higher-level bugs, but those are outside the charter of "shared". Consider: x = *p + 1; How would the compiler reject the right uses but not the case when p == &x? Andrei
Aug 12 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Aug 12, 2016 at 02:21:04PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 08/12/2016 02:01 PM, H. S. Teoh via Digitalmars-d wrote:
 On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
?! Isn't it obvious that assigning to a shared int must require atomicOp or a cast? `x = x + 1;` clearly has a race condition otherwise.
It is not to me, and it does not seem like a low-level race condition to me (whereas ++x is).
The problem is that the line between "low-level" and "high-level" is unclear and arbitrary. Doesn't ++x lower to x = x + 1 on some CPUs anyway (or vice versa, if the optimizer decides to translate it the other way)? Why should the user have to worry about such details? Wouldn't that make shared kinda useless to begin with?
 Currently the compiler must ensure that an atomic read and an atomic
 write are generated for x. Other than that, it is the responsibility
 of the user.  The use of "shared" does not automatically relieve the
 user from certain responsibilities.

 I agree that it would be nice to have stronger protection against
 higher-level bugs, but those are outside the charter of "shared".
 Consider:
 
 x = *p + 1;
 
 How would the compiler reject the right uses but not the case when p
 == &x?
[...] The compiler should reject it (without the appropriate casts) if p has a shared type, and the aliasing situation with x is unknown / unclear. The programmer ought to explicitly state the assumption that x isn't aliased by p by specifying a cast (or equivalent), rather than be able to write such code, possibly not being aware of the implications, and have it compile without any warning. T -- If lightning were to ever strike an orchestra, it'd always hit the conductor first.
Aug 12 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 02:29 PM, H. S. Teoh via Digitalmars-d wrote:
 On Fri, Aug 12, 2016 at 02:21:04PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 08/12/2016 02:01 PM, H. S. Teoh via Digitalmars-d wrote:
 On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
?! Isn't it obvious that assigning to a shared int must require atomicOp or a cast? `x = x + 1;` clearly has a race condition otherwise.
It is not to me, and it does not seem like a low-level race condition to me (whereas ++x is).
The problem is that the line between "low-level" and "high-level" is unclear and arbitrary.
I'd need to think a bit before agreeing or disagreeing, but it's a plausible take. In this case fortunately, the matters can be distinguished.
 Doesn't ++x lower to x = x + 1 on some CPUs
 anyway (or vice versa, if the optimizer decides to translate it the
 other way)?
This doesn't matter. The question is what is explicit and what is implicit in the computation. ++expr is a RMW ("read-modify-write") expression, equivalent to: ((ref x) => { return x = cast(typeof(x)) (x + 1); })(expr) In contrast, expr1 = expr2 + 1 is an expression consisting of distinct read and write, both under the control of the code written by the programmer. As I explained, distinguishing in the general case when expr1 and expr2 refer to the same memory location is not doable statically. So it stands to reason that the compiler generates the code for one read and one write because that is literally what it has been asked to do. It may actually be the case that one wants to do x = x + 1 and exercise a benign high-level race.
 Why should the user have to worry about such details?
What details are you referring to, and how would compiler technology help with those?
 Wouldn't that make shared kinda useless to begin with?
It doesn't seem that way.
 Currently the compiler must ensure that an atomic read and an atomic
 write are generated for x. Other than that, it is the responsibility
 of the user.  The use of "shared" does not automatically relieve the
 user from certain responsibilities.

 I agree that it would be nice to have stronger protection against
 higher-level bugs, but those are outside the charter of "shared".
 Consider:

 x = *p + 1;

 How would the compiler reject the right uses but not the case when p
 == &x?
[...] The compiler should reject it (without the appropriate casts) if p has a shared type, and the aliasing situation with x is unknown / unclear.
I think you are not right here. Andrei
Aug 12 2016
prev sibling parent ag0aep6g <anonymous example.com> writes:
On 08/12/2016 08:21 PM, Andrei Alexandrescu wrote:
 Currently the compiler must ensure that an atomic read and an atomic
 write are generated for x.
Would be nice if that could be added to the spec. It's awfully quiet about shared right now.
Aug 13 2016
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 08/12/2016 08:04 PM, Andrei Alexandrescu wrote:
 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
[...]
 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
I may be responsible for some confusion here, including my own. Disclaimer: I'm far from being an expert on thread-safety. I may have misunderstandings about fundamentals. Recently, I made a thread titled "implicit conversions to/from shared": http://forum.dlang.org/post/nlth0p$1l7g$1 digitalmars.com Before starting that thread, and before messing with atomicOp, I had assumed that D enforces atomic reads/writes on shared types. Then I noticed that I can read/write shared types that are too large for atomic ops. Example: ---- alias T = ubyte[1000]; enum T a = 1; enum T b = 2; shared T x = a; import core.thread: Thread; void write() { bool flip = false; foreach (i; 0 .. 1_000_000) { if (flip) x = a; else x = b; // non-atomic write flip = !flip; } } void main() { auto t = new Thread(&write); t.start(); foreach (i; 0 .. 1_000_000) { T r = x; // non-atomic read assert(r == a || r == b); // fails } t.join(); } ---- I tested a bunch of stuff, and I remember having a test case that failed with a primitive type like int, but I can't find or recreate it now, and a little googling suggests that reading/writing should be atomic for primitive types (on X86 with various restrictions). So I probably just had an error in that test. But the above test case stands, and it also fails with -m32 and ulong: ---- alias T = ulong; enum T a = 0x01_01_01_01__01_01_01_01; enum T b = 0x02_02_02_02__02_02_02_02; /* rest as above */ ---- So, `shared int x; x = x + 1;` is ok, as far as I see now. But with other types, unsafe reads/writes are generated.
Aug 12 2016
parent ag0aep6g <anonymous example.com> writes:
On 08/12/2016 09:41 PM, ag0aep6g wrote:
 So, `shared int x; x = x + 1;` is ok, as far as I see now. But with
 other types, unsafe reads/writes are generated.
Missing alignment can also throw the compiler off: ---- alias T = int; enum T a = 0x01_01_01_01; enum T b = 0x02_02_02_02; struct S { byte[13] padding; align(1) T x = a; } shared S s; import core.thread: Thread; void write() { bool flip = false; foreach (i; 0 .. 1_000_000) { if (flip) s.x = a; else s.x = b; flip = !flip; } } void main() { auto t = new Thread(&write); t.start(); foreach (i; 0 .. 1_000_000) { T r = s.x; assert(r == a || r == b); // fails } t.join(); } ----
Aug 12 2016
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/12/16 2:04 PM, Andrei Alexandrescu wrote:
 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
It's broken because it's inconsistent. If the compiler is going to complain about races in one case, but not in other equivalent cases, then the feature is useless. If all I have to do to avoid compiler complaints is rewrite my expression in an equivalent way, then what is the point of the complaint? At that point, it's just a style guide. What should it do? If I knew that, then I'd have proposed a DIP by now. It's not an easy problem to solve. I don't think you can "solve" races because the compiler can't see all interactions with data. At first glance, it seems that shared data shouldn't be usable without some kind of explicit usage syntax. x = x + 1 is too innocuous looking. It's not going to "solve" the issue, but it makes the code easier to pick out. -Steve
Aug 12 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/12/16 6:58 PM, Steven Schveighoffer wrote:
 On 8/12/16 2:04 PM, Andrei Alexandrescu wrote:
 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
It's broken because it's inconsistent. If the compiler is going to complain about races in one case, but not in other equivalent cases, then the feature is useless.
But ++expr and expr1 = expr1 + expr2 are fundamentally different.
 If all I have to do to avoid compiler complaints is rewrite my
 expression in an equivalent way, then what is the point of the
 complaint? At that point, it's just a style guide.
A bunch of rewrites to seemingly identical behavior to avoid type errors are de rigoeur in so many situations. This is no different.
 What should it do? If I knew that, then I'd have proposed a DIP by now.
 It's not an easy problem to solve. I don't think you can "solve" races
 because the compiler can't see all interactions with data.
++expr contains a low-level race that is worth removing. Extending that to a variety of sub-patterns of expr1 = expr2 + expr3 seems a terrible idea to me.
 At first glance, it seems that shared data shouldn't be usable without
 some kind of explicit usage syntax. x = x + 1 is too innocuous looking.
 It's not going to "solve" the issue, but it makes the code easier to
 pick out.
We discussed this at a point (some 10 years ago). It was: atomicReadRef(x) = atomicRead(x) + 1; But it's painfully obvious that yes the intent is to read the address and read the thing... so why need these anyway? So we left things as they are. I agree shared needs work, but this is not it. We're wasting our time here. Andrei
Aug 12 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/12/16 7:22 PM, Andrei Alexandrescu wrote:
 On 8/12/16 6:58 PM, Steven Schveighoffer wrote:
 On 8/12/16 2:04 PM, Andrei Alexandrescu wrote:
 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
It's broken because it's inconsistent. If the compiler is going to complain about races in one case, but not in other equivalent cases, then the feature is useless.
But ++expr and expr1 = expr1 + expr2 are fundamentally different.
It's not expr2, it's 1. And no they aren't fundamentally different. Don't think like a compiler.
 If all I have to do to avoid compiler complaints is rewrite my
 expression in an equivalent way, then what is the point of the
 complaint? At that point, it's just a style guide.
A bunch of rewrites to seemingly identical behavior to avoid type errors are de rigoeur in so many situations. This is no different.
It's not a type error. We have const, and pure, and safe, which require you to write code in a way that enforces a guarantee. shared does this in a half-assed way. It's not effective. It's like C++ const is not effective at guaranteeing anything stays constant.
 What should it do? If I knew that, then I'd have proposed a DIP by now.
 It's not an easy problem to solve. I don't think you can "solve" races
 because the compiler can't see all interactions with data.
++expr contains a low-level race that is worth removing. Extending that to a variety of sub-patterns of expr1 = expr2 + expr3 seems a terrible idea to me.
I agree that in general races cannot be detected and prevented. ++expr1 is an obvious race, and it is detected and prevented. But it gives the impression that the compiler isn't going to let you make races. It gives the impression that the language has some level of guarantee about avoiding multi-threaded mistakes. It doesn't. It doesn't guarantee anything. It's just a helpful trick in one specific case. I don't know what the right way to handle shared is. My opinion is simply that shared needs special handling from the user. The compiler isn't going to help you make thread-safe code, but at least allows you to mark where the unsafe code could be (by using shared type modifier).
 At first glance, it seems that shared data shouldn't be usable without
 some kind of explicit usage syntax. x = x + 1 is too innocuous looking.
 It's not going to "solve" the issue, but it makes the code easier to
 pick out.
We discussed this at a point (some 10 years ago). It was: atomicReadRef(x) = atomicRead(x) + 1; But it's painfully obvious that yes the intent is to read the address and read the thing... so why need these anyway? So we left things as they are. I agree shared needs work, but this is not it. We're wasting our time here.
Hey, that's fine. I'd rather work on other things too. Shared just seems like an unfulfilled promise, with half-implemented protections. I'd like to just see shared be unusable, and make people cast away shared to do anything. That at least is an attempt at preventing races without intention. The allowance of certain things that are obvious races, whereas other things that are obvious races are prevented makes one assume the worst. -Steve
Aug 13 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, August 13, 2016 16:45:16 Steven Schveighoffer via Digitalmars-d 
wrote:
 Hey, that's fine. I'd rather work on other things too. Shared just seems
 like an unfulfilled promise, with half-implemented protections.

 I'd like to just see shared be unusable, and make people cast away
 shared to do anything. That at least is an attempt at preventing races
 without intention. The allowance of certain things that are obvious
 races, whereas other things that are obvious races are prevented makes
 one assume the worst.
I'm also tempted to argue that making shared virtually unusable without casting it away would be a good idea - particularly when you consider that most code that uses shared is going to need to cast it away to do anything with it (even if we had synchronized classes, that would still be the case - it would just be that under some circumstances, the compiler would do it for you). Maybe we don't want to go quite to the point that you have to cast away shared to do anything other than pass it around (we probably have to have assignment still not involve casting even though that would normally need to be protected by a lock), but I do think that that's the direction that we shoudld be leaning in. However, it sounds like Walter wants to postpone discussing this seriously until after scope is sorted out. I think that it's clear that Walter and Andrei agree that some work needs to be done on formalizing shared, and maybe it should be pushed soon, but it sounds like we should wait until after this DIP is sorted out to really get into it. It _is_ one area that we need to make sure that we have done though. I think that the basics of how shared has been done are right, but we do need to make sure that the details are sorted out correctly and that it's clear how shared should be used, since as it is, way too many folks just slap __gshared on stuff if they want it to be shared (which is almost always the wrong thing to do). - Jonathan M Davis
Aug 13 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/13/2016 2:57 PM, Jonathan M Davis via Digitalmars-d wrote:
 I'm also tempted to argue that making shared virtually unusable without
 casting it away would be a good idea - particularly when you consider that
 most code that uses shared is going to need to cast it away to do anything
 with it (even if we had synchronized classes, that would still be the case -
 it would just be that under some circumstances, the compiler would do it for
 you).
I suspect that's what the end result will be with shared. Anything else just seems like an illusion of correctness.
 However, it sounds like Walter wants to postpone discussing this seriously
 until after scope is sorted out.
Yes.
 way too many folks just slap __gshared on stuff if they want
 it to be shared (which is almost always the wrong thing to do).
That's why it's not allowed in safe code.
Aug 13 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
 I'm also tempted to argue that making shared virtually unusable without
 casting it away would be a good idea
It's a bad idea, no two ways about it. The bummer here is that this is the only topic (and one where D gets it right) off of a whole list that Shachar gave, which I'll copy below. His slides are at http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improv ment-opportunities. Is the talk video anywhere?
 - No RAII support, despite the fact everybody here seems to think that D
supports RAII.
So that is slide 4. Could you please give a bit of detail?
 - Recursive const makes many cases where I can use const in C++ (and
 enjoy the protection it provides) simply mutable in D.
(It's transitive, not recursive.) Can't help much here but note that C++'s const being shallow is a source of confusion among beginning programmers. It's a matter in which reasonable people may disagree. I clearly see how someone used to C++'s const wold feel uncomfortable with D's.
 - This one I have not complained about yet. Operator overloads
 stepping on each other's toes. In my case, I have a container (with
 opIndex that accepts a custom type and opOpAssign!"~") and I place in
 it a struct with some operator overloads as well (have not reduced
 the cause yet, hence no previous complaint about this one). So, when
 I write

 Container[IndexType] ~= Type;

 And the compiler assumes that means:
 Container.opIndexOpAssign!"~"(IndexType, Type);

 but since nothing like that is defined, the code doesn't compile. I
 ended up writing (actual code from the Weka code base):

 blockIds[diskIdx].opOpAssign!"~"(makeBlockId(stripeIdx+i,
 placement.to!SlotIdx(diskIdx)));

 Took me almost ten minutes and consulting someone else to find this
 solution.
The opIndexOpAssign family is intentional and arguably a good thing. The semantics of std::map's operator[] are controversial and suboptimal; opIndexOpAssign is specially designed to allow efficient dictionaries and sparse arrays. If you get to reduce the code we'd definitely want to fix whatever bug is there.
 - GC. GC. GC. Some more GC.
You mean there's too much of it? We're on that.
 - Integral type operations promotion and the constant need for casts.
This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP has bugs that we need to fix.
 - No warning for signed/unsigned comparisons. An unfailing source for bugs.
This is actionable too.
 - No ref type.
This you need to live with. We'd love to make the life easier for Weka, but you need to be careful when mixing things of the D ethos you don't like but won't change (qualifiers, ref) with things that we can improve. Did you try the .d/.di compile-time table? Andrei
Aug 13 2016
next sibling parent Seb <seb wilzba.ch> writes:
On Sunday, 14 August 2016 at 00:26:31 UTC, Andrei Alexandrescu 
wrote:
 On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d 
 wrote:
 I'm also tempted to argue that making shared virtually 
 unusable without
 casting it away would be a good idea
It's a bad idea, no two ways about it. The bummer here is that this is the only topic (and one where D gets it right) off of a whole list that Shachar gave, which I'll copy below. His slides are at http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improv ment-opportunities. Is the talk video anywhere?
https://youtu.be/yIH_0ew-maI?t=21m34s
Aug 13 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 14/08/16 03:26, Andrei Alexandrescu wrote:
 On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
 I'm also tempted to argue that making shared virtually unusable without
 casting it away would be a good idea
It's a bad idea, no two ways about it. The bummer here is that this is the only topic (and one where D gets it right) off of a whole list that Shachar gave, which I'll copy below. His slides are at http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improvement-opportunities. Is the talk video anywhere?
 - No RAII support, despite the fact everybody here seems to think that
 D supports RAII.
So that is slide 4. Could you please give a bit of detail?
http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html
 - Recursive const makes many cases where I can use const in C++ (and
 enjoy the protection it provides) simply mutable in D.
(It's transitive, not recursive.) Can't help much here but note that C++'s const being shallow is a source of confusion among beginning programmers. It's a matter in which reasonable people may disagree. I clearly see how someone used to C++'s const wold feel uncomfortable with D's.
I'm quite fine with disagreeing on this point, but I do want to make sure we agree on what it is we disagree about. My view of the C++ const situation is consistent with C++'s philosophy about pretty much everything, which is this. "We give you very powerful tools to do many things. We do not, however, prevent you from misusing them. Caveat emptor". C++'s "logical constness" may lead to pretty twisted stuff if misused, but the flip side is that, when used correctly, it can be used quite extensively to give the compiler tools to protect you from mistakes. D's const, to me (please correct me if I'm wrong), aimed not at helping the compiler help the programmer, but at helping the compiler. It contains a much stronger guarantee, and accordingly, is applicable in much fewer cases. It is my understanding that we agree on the above. If we do, I can state my opinion, and you are most welcome to disagree with it, and we can call that matter resolved. In my experience, D's guarantee is too strong, in that it is too often inapplicable. This leads to two bad things happening. The first is that you can rarely put "const" on anything, meaning you lose the power that C++'s guarantee gave you, and not gain enough in return. The second is that, since it is so rarely applicable, people tend to forget implementing the const version of methods, even when those are easy. This leads to a situation where, even if const can be applied, it is just too much work to weed out the bugs all over the place this will cause, and people give up. Compound this with the total mess that is "inout", and I, personally, just gave up. I know I'm not the only one.
 The opIndexOpAssign family is intentional and arguably a good thing. The
 semantics of std::map's operator[] are controversial and suboptimal;
 opIndexOpAssign is specially designed to allow efficient dictionaries
 and sparse arrays. If you get to reduce the code we'd definitely want to
 fix whatever bug is there.
I will. I just don't know how long it will take me to get to it. I already tried to recreate it simply with two structs and just the relevant ops, without success (though, now that I think of it, it might have been with a different version than the one that compiles our code). If you want, since I know you have access, I can send you the line number from which this was taken. Either way, this is just one example out of many where the interaction between features creates complex situations that either result in not defined (as opposed to undefined) behavior, or result in behavior that may be well defined, but is surprising to the programmer.
 - GC. GC. GC. Some more GC.
You mean there's too much of it? We're on that.
Not exactly, but I have nothing to say here which you don't already know, so let's leave it at that.
 - Integral type operations promotion and the constant need for casts.
This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP has bugs that we need to fix.
Won't solve my problems unless VRP's scope is significantly enhanced. Your book said VRP is only defined to work on the same expression it is in. So long as that's the case, it's not a matter of fixing bugs. Also, I should point out, that I'm not suggesting D allow implicit narrowing conversions. Instead, I think D should drop the pretense that C expressions should maintain their semantics precisely, and stop widening expressions. I must confess that I have never heard of this rule in C before encountering it in D. Any time I needed some expression to take place with a width larger than the input arguments, I always casted them. Since this is still necessary for long, I think dropping this rule won't be too big of an issue.
 - No ref type.
This you need to live with.
Can you expand a little on the rational for that? Also, part of our problems with this is that introspection also does not see refs, which causes the following two functions to report the same signature: void func1(int arg); void func2(ref int arg);
 We'd love to make the life easier for Weka,
I'd like to make it clear here that I speak of my own experience. I do talk with people, and some of the engineers share some of my criticism. However, please don't think that just because I'm more vocal than others in Weka, it means that my opinions are shared by all. Please treat my posts here as my own. but you need to be careful
 when mixing things of the D ethos you don't like but won't change
 (qualifiers, ref) with things that we can improve.

 Did you try the .d/.di compile-time table?
Not my task, so what I'm writing here is second hand knowledge from one random water cooler talk. Please excuse me if I'm making gross misrepresentations of reality here. From what I understand, there is a problem with the way imports are put in the di files. In particular, take the following code: import some.struct: SomeStruct; import some.other.struct: SomeOtherStruct; SomeStruct func() { SomeOtherStruct a(3); return a.some; } The ideal di for it would be: import some.struct: SomeStruct; SomeStruct func(); Sadly, the actual di also contains the totally unnecessary: import some.other.struct: SomeOtherStruct; The result is that the di contains too many imports, and no gains are made vis compilation times. Shachar
Aug 13 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
 On 14/08/16 03:26, Andrei Alexandrescu wrote:
 On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
 I'm also tempted to argue that making shared virtually unusable without
 casting it away would be a good idea
It's a bad idea, no two ways about it. The bummer here is that this is the only topic (and one where D gets it right) off of a whole list that Shachar gave, which I'll copy below. His slides are at http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improvement-opportunities. Is the talk video anywhere?
 - No RAII support, despite the fact everybody here seems to think that
 D supports RAII.
So that is slide 4. Could you please give a bit of detail?
http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html
OK. One thing we can't stress enough is that everything - talks, slides, newsgroup posts - about a bug in the language definition or implementation must be in support of an issue. No issue no honey. I submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf and preapproved it. Please carry future considerations there.
 I'm quite fine with disagreeing on this point, but I do want to make
 sure we agree on what it is we disagree about.

 My view of the C++ const situation is consistent with C++'s philosophy
 about pretty much everything, which is this. "We give you very powerful
 tools to do many things. We do not, however, prevent you from misusing
 them. Caveat emptor".

 C++'s "logical constness" may lead to pretty twisted stuff if misused,
 but the flip side is that, when used correctly, it can be used quite
 extensively to give the compiler tools to protect you from mistakes.

 D's const, to me (please correct me if I'm wrong), aimed not at helping
 the compiler help the programmer, but at helping the compiler. It
 contains a much stronger guarantee, and accordingly, is applicable in
 much fewer cases.

 It is my understanding that we agree on the above. If we do, I can state
 my opinion, and you are most welcome to disagree with it, and we can
 call that matter resolved.

 In my experience, D's guarantee is too strong, in that it is too often
 inapplicable. This leads to two bad things happening.

 The first is that you can rarely put "const" on anything, meaning you
 lose the power that C++'s guarantee gave you, and not gain enough in
 return.

 The second is that, since it is so rarely applicable, people tend to
 forget implementing the const version of methods, even when those are
 easy. This leads to a situation where, even if const can be applied, it
 is just too much work to weed out the bugs all over the place this will
 cause, and people give up.

 Compound this with the total mess that is "inout", and I, personally,
 just gave up. I know I'm not the only one.
I understand. One thing we want to do to improve on that is to deduce const for template methods. See https://issues.dlang.org/show_bug.cgi?id=16389.
 The opIndexOpAssign family is intentional and arguably a good thing. The
 semantics of std::map's operator[] are controversial and suboptimal;
 opIndexOpAssign is specially designed to allow efficient dictionaries
 and sparse arrays. If you get to reduce the code we'd definitely want to
 fix whatever bug is there.
I will. I just don't know how long it will take me to get to it. I already tried to recreate it simply with two structs and just the relevant ops, without success (though, now that I think of it, it might have been with a different version than the one that compiles our code). If you want, since I know you have access, I can send you the line number from which this was taken. Either way, this is just one example out of many where the interaction between features creates complex situations that either result in not defined (as opposed to undefined) behavior, or result in behavior that may be well defined, but is surprising to the programmer.
This being a matter of perception, there's no disagreement here. To turn this into something actionable it would be great if you thought of ways to simplify said interaction without breaking code (e.g. by removing unnecessary constraints).
 - Integral type operations promotion and the constant need for casts.
This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP has bugs that we need to fix.
Won't solve my problems unless VRP's scope is significantly enhanced. Your book said VRP is only defined to work on the same expression it is in. So long as that's the case, it's not a matter of fixing bugs.
It's a matter of school of thought. C and C++ allow implicit casts that lose information. C# and Java do not. Each has pluses and minuses. D is on the C# and Java side, with VRP which reduces the number of explicit casts needed. Here again we're not talking about a bug in the language or the "right" or "wrong" language design, it's just a matter in which different languages do different things.
 Also, I should point out, that I'm not suggesting D allow implicit
 narrowing conversions. Instead, I think D should drop the pretense that
 C expressions should maintain their semantics precisely, and stop
 widening expressions.
This will not happen.
 I must confess that I have never heard of this rule in C before
 encountering it in D.
Which rule?
 Any time I needed some expression to take place
 with a width larger than the input arguments, I always casted them.
So then why do you complain D asks for "too many" casts?
 Since this is still necessary for long, I think dropping this rule won't
 be too big of an issue.
You kind of lost me there. So which rule?
 - No ref type.
This you need to live with.
Can you expand a little on the rational for that?
The "ref" attribute has been a fundamental part of the language for too long.
 Also, part of our
 problems with this is that introspection also does not see refs, which
 causes the following two functions to report the same signature:

 void func1(int arg);
 void func2(ref int arg);
I actually think you can do introspection on any argument to figure whether it has "ref".
 We'd love to make the life easier for Weka,
I'd like to make it clear here that I speak of my own experience. I do talk with people, and some of the engineers share some of my criticism. However, please don't think that just because I'm more vocal than others in Weka, it means that my opinions are shared by all. Please treat my posts here as my own.
There are some good points that we could easily agree need to be improved. At some point you must get in gear and submit some issues to move forward on things important to Weka.
 From what I understand, there is a problem with the way imports are put
 in the di files. In particular, take the following code:

 import some.struct: SomeStruct;
 import some.other.struct: SomeOtherStruct;

 SomeStruct func() {
    SomeOtherStruct a(3);
    return a.some;
 }

 The ideal di for it would be:

 import some.struct: SomeStruct;

 SomeStruct func();

 Sadly, the actual di also contains the totally unnecessary:

 import some.other.struct: SomeOtherStruct;

 The result is that the di contains too many imports, and no gains are
 made vis compilation times.
I think you forgot to mention the issue number :o). Andrei
Aug 14 2016
next sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 14/08/16 17:07, Andrei Alexandrescu wrote:
 On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
 So that is slide 4. Could you please give a bit of detail?
http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html
OK. One thing we can't stress enough is that everything - talks, slides, newsgroup posts - about a bug in the language definition or implementation must be in support of an issue. No issue no honey. I submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf and preapproved it. Please carry future considerations there.
Thank you. To be fair, though, you might want to close it as a duplicate of https://issues.dlang.org/show_bug.cgi?id=14246
 I understand. One thing we want to do to improve on that is to deduce
 const for template methods. See
 https://issues.dlang.org/show_bug.cgi?id=16389.
Personally, I also think that inout should stop acting like it is a fourth form of protection.
 Here again we're not talking about a bug in the language
 or the "right" or "wrong" language design, it's just a matter in which
 different languages do different things.
 
 Also, I should point out, that I'm not suggesting D allow implicit
 narrowing conversions. Instead, I think D should drop the pretense that
 C expressions should maintain their semantics precisely, and stop
 widening expressions.
This will not happen.
I had a whole list of places where D already isn't compatible with C for a statement that compiles in both. I cannot find it. I'll start a new thread when I do.
 
 I must confess that I have never heard of this rule in C before
 encountering it in D.
Which rule?
The rule that says "ubyte + ubyte = uint".
 Can you expand a little on the rational for that?
The "ref" attribute has been a fundamental part of the language for too long.
I'm sorry, I simply don't understand that answer. How is turning "ref" into a type modifier hinder you in any way? No old compiling code breaks as a result.
 
 Also, part of our
 problems with this is that introspection also does not see refs, which
 causes the following two functions to report the same signature:

 void func1(int arg);
 void func2(ref int arg);
I actually think you can do introspection on any argument to figure whether it has "ref".
 We'd love to make the life easier for Weka,
I'd like to make it clear here that I speak of my own experience. I do talk with people, and some of the engineers share some of my criticism. However, please don't think that just because I'm more vocal than others in Weka, it means that my opinions are shared by all. Please treat my posts here as my own.
There are some good points that we could easily agree need to be improved. At some point you must get in gear and submit some issues to move forward on things important to Weka.
The problem is that many of those points are contended (or, at least, used to be). If you read through the thread I pointed to regarding the destructor issue, for example, you will see that people actually argue that the way D currently does things is the correct way to do things. If I submit an issue to the forum, and get back the reply "that's a know thing, and that's on purpose", I don't see any point in submitting an issue.
 
 From what I understand, there is a problem with the way imports are put
 in the di files. In particular, take the following code:

 import some.struct: SomeStruct;
 import some.other.struct: SomeOtherStruct;

 SomeStruct func() {
    SomeOtherStruct a(3);
    return a.some;
 }

 The ideal di for it would be:

 import some.struct: SomeStruct;

 SomeStruct func();

 Sadly, the actual di also contains the totally unnecessary:

 import some.other.struct: SomeOtherStruct;

 The result is that the di contains too many imports, and no gains are
 made vis compilation times.
I think you forgot to mention the issue number :o).
Like I said, I'm just a relay on that front. I'll try to get the people actually working on it to submit an issue. Shachar
Aug 14 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/14/16 2:03 PM, Shachar Shemesh wrote:
 On 14/08/16 17:07, Andrei Alexandrescu wrote:
 On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
 So that is slide 4. Could you please give a bit of detail?
http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html
OK. One thing we can't stress enough is that everything - talks, slides, newsgroup posts - about a bug in the language definition or implementation must be in support of an issue. No issue no honey. I submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf and preapproved it. Please carry future considerations there.
Thank you. To be fair, though, you might want to close it as a duplicate of https://issues.dlang.org/show_bug.cgi?id=14246
Thanks. For now I raised both to critical.
 I understand. One thing we want to do to improve on that is to deduce
 const for template methods. See
 https://issues.dlang.org/show_bug.cgi?id=16389.
Personally, I also think that inout should stop acting like it is a fourth form of protection.
I'm not a fan of inout either. We need to think collectively of ways to move things forward from where we are to a better place.
 Also, I should point out, that I'm not suggesting D allow implicit
 narrowing conversions. Instead, I think D should drop the pretense that
 C expressions should maintain their semantics precisely, and stop
 widening expressions.
This will not happen.
I had a whole list of places where D already isn't compatible with C for a statement that compiles in both. I cannot find it. I'll start a new thread when I do.
That would be very helpful.
 I must confess that I have never heard of this rule in C before
 encountering it in D.
Which rule?
The rule that says "ubyte + ubyte = uint".
That will not happen. It would break tons of code in subtle ways. You are a competent engineer so you know better than asking for it.
 Can you expand a little on the rational for that?
The "ref" attribute has been a fundamental part of the language for too long.
I'm sorry, I simply don't understand that answer. How is turning "ref" into a type modifier hinder you in any way? No old compiling code breaks as a result.
Of course it breaks all code that introspects e.g. parameter types and finds "ref T" instead of "T". It is a fundamental change to the language that is also questionable on its own (C++ has and continues to have inordinate complications because of references being an almost-type). Pick your fights properly, and fight them well.
 Also, part of our
 problems with this is that introspection also does not see refs, which
 causes the following two functions to report the same signature:

 void func1(int arg);
 void func2(ref int arg);
I actually think you can do introspection on any argument to figure whether it has "ref".
Just making sure you read the above. Please give it a look.
 There are some good points that we could easily agree need to be
 improved. At some point you must get in gear and submit some issues to
 move forward on things important to Weka.
The problem is that many of those points are contended (or, at least, used to be). If you read through the thread I pointed to regarding the destructor issue, for example, you will see that people actually argue that the way D currently does things is the correct way to do things.
Did anyone in the leadership say so? If not, you're safe to ignore it; statistically anything suggested herein will find a strong opponent. I'm with you on this, and Walter is too (just confirmed via email). The issues are preapproved. I've also raised the issues to critical.
 If I submit an issue to the forum, and get back the reply "that's a know
 thing, and that's on purpose", I don't see any point in submitting an issue.
If you get it from Walter and myself, yes. Otherwise, again, ignore and press on. Again: choose your fights and fight them well. I know in your heart of hearts have an understanding of what you can change and what you cannot.
 The result is that the di contains too many imports, and no gains are
 made vis compilation times.
I think you forgot to mention the issue number :o).
Like I said, I'm just a relay on that front. I'll try to get the people actually working on it to submit an issue.
Thanks. I should add that as long as the .di does not import the .d, the slowdown due to the computed table will not occur. So the worry is not warranted. Andrei
Aug 14 2016
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, August 14, 2016 14:35:49 Andrei Alexandrescu via Digitalmars-d 
wrote:
 On 8/14/16 2:03 PM, Shachar Shemesh wrote:
 On 14/08/16 17:07, Andrei Alexandrescu wrote:
 On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
 I must confess that I have never heard of this rule in C before
 encountering it in D.
Which rule?
The rule that says "ubyte + ubyte = uint".
That will not happen. It would break tons of code in subtle ways. You are a competent engineer so you know better than asking for it.
No offense, but that comes across as pretty condescending. I agree that changing the integer promotion rules would be very risky, but that's the sort of response that seems more likely to offend than to educate or convince. - Jonathan M Davis
Aug 14 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/14/16 11:40 PM, Jonathan M Davis via Digitalmars-d wrote:
 On Sunday, August 14, 2016 14:35:49 Andrei Alexandrescu via Digitalmars-d
 wrote:
 On 8/14/16 2:03 PM, Shachar Shemesh wrote:
 On 14/08/16 17:07, Andrei Alexandrescu wrote:
 On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
 I must confess that I have never heard of this rule in C before
 encountering it in D.
Which rule?
The rule that says "ubyte + ubyte = uint".
That will not happen. It would break tons of code in subtle ways. You are a competent engineer so you know better than asking for it.
No offense, but that comes across as pretty condescending. I agree that changing the integer promotion rules would be very risky, but that's the sort of response that seems more likely to offend than to educate or convince.
Apologies for the possible offensive interpretation. My statement should be taken at face value - it is indeed not difficult for a programmer to project that changing a fundamental operator typing rule has wide ripples. My larger point is that there's a clear distinction among Shachar's list items: some are things we can work on, and some aren't. Putting them together dilutes the positive impact of the list. -- Andrei
Aug 14 2016
parent reply John Smith <gyroheli gmail.com> writes:
Well there are some things I feel could be improved, a lot of the 
things are really just minor but what is a deal breaker for me 
mostly is the compilers. The GCC and Clang implementations are 
really far behind in terms of the version, so they are missing a 
lot of features. A lot of the features that I'd want to use D 
for. In the download section it also says "good optimization" but 
it honestly isn't. I rewrote a small portion for one of my 
projects to test out D but looking at the assembly a lot of it 
was questionable. I'd say DMD probably produced the best assembly 
but then there's the problem that it doesn't support MMX 
instructions. Even on 64-bit it still uses the FPU, which I can't 
really use. The FPU isn't consistent enough for simulations that 
run on separate computers and different OSs that need to be 
synced through a network.

Anyways for some more minor things. I really don't like 
__gshared, why couldn't it just be named "gshared" instead. Don't 
like how that naming convention is used in C/C++ either but I 
feel here in D it is completely out of place. Nothing else uses a 
preceding "__" and from the documentation it looks like it's made 
to stand out cause it shouldn't be used. But it is used a lot, 
and it wouldn't be possible to do certain things without it. I 
forget but the dynamic library loader for D, derelict, is one 
such case.

There's no "const T&" equivalent in D. Basically constant 
variables need to be copied and non-constant variables can be 
passed with the use of "ref". So you need to write two different 
functions that in essence do the same thing. One way around the 
code duplication is using templates so that it auto generates 
these variants for you, but then there's code bloat cause each 
parameter could then be a copy or a "ref". This leads to a lot of 
extra copies, depending on the object and it's size it might not 
be desirable. It thus limits code where you could do a one line 
operation like: 
"someObject.process(otherObject.generateLargeConstantObject());". 
In this case there will be an extra copy made, and currently none 
of compilers are able to optimize it out. It seems like it is 
possible for the compiler to be able to optimize it so no copies 
are made but that's not the case currently which goes back my 
main argument I guess. I can see the value in not having a 
"const&" but the current implementation is flawed.

http://ideone.com/INGSsZ

Garbage collector is in a few libraries as well. I think the only 
problem I had with that is that the std.range library has 
severely reduced functionality when using static arrays.

I think there was more but it was a while since I used D and 
don't recall. There are significant improvements to D over C++ 
that I do love, really want to be able to use it. Whenever I run 
into an issue with C++ I just think about D and how I could have 
solved that problem easily.

On Sunday, 14 August 2016 at 18:45:06 UTC, Walter Bright wrote:
 This rule was retained for D to make it easier to translate 
 code from C/C++ to D. Changing the rule could result in subtle 
 and invisible bugs for such translations and for C/C++ 
 programmers who are so used to the integral promotion rules 
 that they aren't even really aware of reliance upon them.

 The reason C/C++ programmers, even experienced ones, are often 
 unaware of this rule is there is another rule, implicit 
 narrowing, so:

     byte = byte + byte;

 compiles without complaint. The trouble comes when byte has a 
 value, say, 255, and the sum is 510. The assignment silently 
 chops it to byte size, and 254 is stored in the result.

 For D, we decided that silently converting 510 to 254 would not 
 be acceptable. Hence an explicit cast would be required,

     byte = cast(byte)(byte + byte);
Well you could say the same for the same for int. Why isn't "int + int = long"? Right now it is following the rule "int + int = int". Maybe cause the values aren't as small but I could argue the same thing. If we add 2147483647 with 2147483647, the value stored is -2. Under the same sort of thought, you probably wouldn't find that acceptable either correct? At some point you are going to run out of types that have larger storage. What is "cent + cent" going to have as a larger type? At some point you just have to accept that you are working with a finite set of numbers. For D the compromise happens with the type int. C/C++ just accepts that and maintains consistency rather than flip floping at an arbitrary type.
Aug 18 2016
next sibling parent Seb <seb wilzba.ch> writes:
Hei John, I read over the first part of your message and it seems 
that same information you got is quite outdated:

On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:
 Well there are some things I feel could be improved, a lot of 
 the things are really just minor but what is a deal breaker for 
 me mostly is the compilers. The GCC and Clang implementations 
 are really far behind in terms of the version, so they are 
 missing a lot of features. A lot of the features that I'd want 
 to use D for.
That's not true for LDC - it's on par with the latest DMD version since a while now. It might be that the version shipped with your Linux distribution is a bit outdated. http://forum.dlang.org/post/uxupejapglpeokaiqqjg forum.dlang.org
 In the download section it also says "good optimization" but it 
 honestly isn't. I rewrote a small portion for one of my 
 projects to test out D but looking at the assembly a lot of it 
 was questionable. I'd say DMD probably produced the best 
 assembly but then there's the problem that it doesn't support 
 MMX instructions.
That's weird - LDC allows great optimization, see e.g. these two benchmarks: https://github.com/kostya/benchmarks http://forum.dlang.org/post/zxkkjezakirlfepndjxk forum.dlang.org
 Even on 64-bit it still uses the FPU, which I can't really use. 
 The FPU isn't consistent enough for simulations that run on 
 separate computers and different OSs that need to be synced 
 through a network.
Inconsistent FP math is a known issue, but most likely a fusedMath pragma will be added soon: http://forum.dlang.org/post/hjaiavlfkoamenidomsa forum.dlang.org https://github.com/ldc-developers/ldc/issues/1669
 Anyways for some more minor things. I really don't like 
 __gshared, why couldn't it just be named "gshared" instead. 
 Don't like how that naming convention is used in C/C++ either 
 but I feel here in D it is completely out of place. Nothing 
 else uses a preceding "__" and from the documentation it looks 
 like it's made to stand out cause it shouldn't be used. But it 
 is used a lot, and it wouldn't be possible to do certain things 
 without it. I forget but the dynamic library loader for D, 
 derelict, is one such case.
Yep you are correct about the motivation: __gshared got its ugly name to remind the programmer about the dangerous world he wades into. There are usually safer & more elegant ways, e.g.: http://tour.dlang.io/tour/en/multithreading/std-parallelism http://tour.dlang.io/tour/en/multithreading/synchronization-sharing http://tour.dlang.io/tour/en/multithreading/message-passing
Aug 18 2016
prev sibling next sibling parent ag0aep6g <anonymous example.com> writes:
On 08/19/2016 12:50 AM, John Smith wrote:
 Well there are some things I feel could be improved, a lot of the things
 are really just minor but what is a deal breaker for me mostly is the
 compilers. The GCC and Clang implementations are really far behind in
 terms of the version, so they are missing a lot of features. A lot of
 the features that I'd want to use D for.
LDC has been catching up quite nicely. LDC 1.0.0 (current release) is at front-end 2.070, and 1.1.0 (beta) is at 2.071 which matches the current DMD release. https://github.com/ldc-developers/ldc/releases
 In the download section it also
 says "good optimization" but it honestly isn't. I rewrote a small
 portion for one of my projects to test out D but looking at the assembly
 a lot of it was questionable. I'd say DMD probably produced the best
 assembly but then there's the problem that it doesn't support MMX
 instructions.
I'm not very knowledgeable on optimized machine code, but as far I know, LDC/GDC usually produce significantly faster binaries than DMD. So when DMD comes out ahead, that's not typical. Might be an outlier. [...]
 Anyways for some more minor things. I really don't like __gshared, why
 couldn't it just be named "gshared" instead. Don't like how that naming
 convention is used in C/C++ either but I feel here in D it is completely
 out of place. Nothing else uses a preceding "__" and from the
 documentation it looks like it's made to stand out cause it shouldn't be
 used.
That's exactly it. `__gshared` has a weird name because `shared` should generally be used instead. `__gshared` throws thread-safety out the window, while `shared` is supposed to at least make sure that the shared-ness is visible to the programmer.
 But it is used a lot, and it wouldn't be possible to do certain
 things without it. I forget but the dynamic library loader for D,
 derelict, is one such case.
Those certain things should be relatively rare low-level tasks. When `__gshared` is used more than `shared`, then `shared` may (currently) be failing its goals. Of course, a low-level project like Derelict may just have more use for `__gshared`.
 There's no "const T&" equivalent in D. Basically constant variables need
 to be copied and non-constant variables can be passed with the use of
 "ref". So you need to write two different functions that in essence do
 the same thing.
You can pass const variables per ref: void foo(ref const int bar) {} What you can't do is pass rvalues in such a parameter. That's what the other function/overload is needed for. That doesn't mean that everything is just fine as it is. [...]
 Garbage collector is in a few libraries as well. I think the only
 problem I had with that is that the std.range library has severely
 reduced functionality when using static arrays.
You may be aware of this, but you can slice a T[n] to get a T[] which is a range. [...]
 Well you could say the same for the same for int. Why isn't "int + int =
 long"? Right now it is following the rule "int + int = int". Maybe cause
 the values aren't as small but I could argue the same thing. If we add
 2147483647 with 2147483647, the value stored is -2. Under the same sort
 of thought, you probably wouldn't find that acceptable either correct?
 At some point you are going to run out of types that have larger
 storage. What is "cent + cent" going to have as a larger type? At some
 point you just have to accept that you are working with a finite set of
 numbers. For D the compromise happens with the type int. C/C++ just
 accepts that and maintains consistency rather than flip floping at an
 arbitrary type.
I don't think that C "just accepts that". It still promotes a sum of smaller types to int. Observe: ---- #include<stdio.h> int main() { unsigned char a = 255; printf("%d\n", (a + a) / 2); /* 255 */ printf("%d\n", (unsigned char)(a + a) / 2); /* 127 */ return 0; } ---- If `a + a` were an unsigned char, we'd expect the two outputs to be the same. The difference between D and C is that C has implicit narrowing. I.e., it lets you assign an int to a char just like that, throwing away the high bits. D requires a cast for it. So, why is int the go-to type? I can't answer with authority, but for D I think it's just because that's what C does.
Aug 18 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:
 Garbage collector is in a few libraries as well. I think the 
 only problem I had with that is that the std.range library has 
 severely reduced functionality when using static arrays.
std.range is one of the libraries that has never used the GC much. Only tiny parts of it ever have, Moreover, dynamic arrays do not necessarily have to be GC'd. Heck, you can even malloc them if you want to (`(cast(int*)malloc(int.sizeof))[0 .. 1]` gives an int[] of length 1). This has been a common misconception lately... :(
 Well you could say the same for the same for int. Why isn't 
 "int + int = long"?
Yeah, if I was designing things, I'd make it promote the smaller size to the larger size in the expression. So byte + byte = byte and byte + short goes to short, and so on. Moreover, I'd make it check both sides of the equation, so int = byte + byte would convert the bytes to ints first too. It'd be quite nice, and I think it would work in most cases... it might even work the same as C in most cases, though I'm not sure. (the one thing people might find weird is auto a = b + c; means a is a byte if b and c are bytes. In C, it would be an int. but who writes that in C anyway.) Alas, C insisted on making everything int all the time and D followed that :(
Aug 18 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:
 Alas, C insisted on making everything int all the time and D followed that :(
One would have to be *really* sure of their ground in coming up with allegedly better rules.
Aug 19 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 20/08/16 00:51, Walter Bright wrote:
 On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:
 Alas, C insisted on making everything int all the time and D followed
 that :(
Actually, Adam's suggestion on how things should work is precisely how C works (except it trails off at int). a = b + c; if b and c are both a byte, and a is a byte, the result is unpromoted. If a is a short, the result is promoted. I know the mechanism is completely different than what Adam was suggesting, but the end result is precisely the same.
 One would have to be *really* sure of their ground in coming up with
 allegedly better rules.
Would "no narrowing implicit casts" be considered such a better rule? :-) Again, I'm not saying it's a bad rule, just that does have consequences. What I'm saying is that we are, already, changing things. Shachar
Aug 20 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/20/2016 8:25 AM, Shachar Shemesh wrote:
 Actually, Adam's suggestion on how things should work is precisely how C works
No, it's subtly different. Which is my point that one must be very, very careful when proposing different behavior.
Aug 20 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 20/08/16 21:00, Walter Bright wrote:
 On 8/20/2016 8:25 AM, Shachar Shemesh wrote:
 Actually, Adam's suggestion on how things should work is precisely how
 C works
No, it's subtly different. Which is my point that one must be very, very careful when proposing different behavior.
Can you give an example of an expression that would yield different results in both modes? To frame the discussion in a constructive way, I'll suggest an algorithmic definition of (my interpretation of) Adam's proposal: During static analysis, keep both the "most expanded" and the "least expanded" type of the expression parsed so far. "Least expanded" is the largest type actually used in the expression. Upon use of the value, resolve which type to actually use for it. If the use type requests a type between least and most, use that type for evaluating the entire expression. If the use requests a type outside that range, use the one closest (and, if the use is below the range, complain about narrowing conversion). If more than one use is possible (i.e. - overloading), use the largest one applicable. I believe the above solves my problem, without losing compatibility with C (counter examples welcome, so we can continue the discussion in a productive way), and without foregoing erroring out on narrowing conversions. Shachar
Aug 20 2016
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 08/21/2016 07:12 AM, Shachar Shemesh wrote:
 During static analysis, keep both the "most expanded" and the "least
 expanded" type of the expression parsed so far. "Least expanded" is the
 largest type actually used in the expression.
What's "most expanded"?
 Upon use of the value, resolve which type to actually use for it. If the
 use type requests a type between least and most, use that type for
 evaluating the entire expression. If the use requests a type outside
 that range, use the one closest (and, if the use is below the range,
 complain about narrowing conversion).
So when only ubytes are involved, all calculations would be done on ubytes, no promotions, right? There are cases where that would give different results than doing promotions. Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands are promoted to a larger type, you get 255 as the result. If they are not, you have the equivalent of `ubyte x = 255; x *= 2; x /= 2;` which gives you 127.
Aug 21 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/21/2016 2:47 AM, ag0aep6g wrote:
 Upon use of the value, resolve which type to actually use for it. If the
 use type requests a type between least and most, use that type for
 evaluating the entire expression. If the use requests a type outside
 that range, use the one closest (and, if the use is below the range,
 complain about narrowing conversion).
So when only ubytes are involved, all calculations would be done on ubytes, no promotions, right? There are cases where that would give different results than doing promotions. Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands are promoted to a larger type, you get 255 as the result. If they are not, you have the equivalent of `ubyte x = 255; x *= 2; x /= 2;` which gives you 127.
That's right. The thing is, programmers are so used to C integral promotion rules they often are completely unaware of them and how they work, despite relying on them. This is what makes changing the rules so pernicious and dangerous. I've had to explain the promotion rules to professionals with 10 years of experience in C/C++, and finally stopped being surprised at that. D does change the rules, but only in a way that adds compile time errors to them. So no surprises. (Nobody knows how function overloading works in C++ either, but that's forgivable :-) )
Aug 21 2016
parent reply Solomon E <default avatar.org> writes:
On Sunday, 21 August 2016 at 17:26:24 UTC, Walter Bright wrote:
 On 8/21/2016 2:47 AM, ag0aep6g wrote:
 Upon use of the value, resolve which type to actually use for 
 it. If the
 use type requests a type between least and most, use that 
 type for
 evaluating the entire expression. If the use requests a type 
 outside
 that range, use the one closest (and, if the use is below the 
 range,
 complain about narrowing conversion).
So when only ubytes are involved, all calculations would be done on ubytes, no promotions, right? There are cases where that would give different results than doing promotions. Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands are promoted to a larger type, you get 255 as the result. If they are not, you have the equivalent of `ubyte x = 255; x *= 2; x /= 2;` which gives you 127.
That's right. The thing is, programmers are so used to C integral promotion rules they often are completely unaware of them and how they work, despite relying on them. This is what makes changing the rules so pernicious and dangerous. I've had to explain the promotion rules to professionals with 10 years of experience in C/C++, and finally stopped being surprised at that. D does change the rules, but only in a way that adds compile time errors to them. So no surprises. (Nobody knows how function overloading works in C++ either, but that's forgivable :-) )
I have a speculative answer to the topic of this thread, which I was wanting to write a comment here about, before I saw the last two comments in this thread. Look in the D Language Reference, the spec. Look for the word "error" there. It occurs many times, in code that is erroneous in the spec. Also, notice the number of question marks in the code sample near the end of the page on Declarations. Notice that the questions raised are not answered there. The D spec is full of errors, literally, or teasers sometimes. It seems improbable to me that D will become popular unless that is first fixed, and the attitude that it represents. It's a sign of unsoundness, at least unsoundness about how to teach a language or how to standardize it, that comes through clearly at a surface level, even if someone doesn't have specific disagreements with the design of D. Erroneous code should be omitted from a spec, or at least clearly marked such as by a red background. Mixing lines commented as errors together with later lines commented as "ok" in the same code quote blocks makes it even more confusing. (Someone who doesn't know any D yet might even think that D gives you the results of whatever lines are correct, skipping the errors as if they were empty lines. Programming languages differ enough that that's a possible feature, the sort of feature that might result in a language being described as "exciting" even.) Anyone feel free to correct me or say I'm all wrong about this. I'm not an expert on teaching programming languages. I'm just a learner, and just as a hobby.
Aug 21 2016
parent Solomon E <default avatar.org> writes:
On Sunday, 21 August 2016 at 23:07:43 UTC, Solomon E wrote:
 The D spec is full of errors, literally, or teasers sometimes.
....
 Erroneous code should be omitted from a spec, or at least 
 clearly marked such as by a red background.
I'd like to respond critically to my own silly comment. It's a great achievement that D has so many features, more versatility than C++, and yet the same few pages can serve as both the language specification and as the language reference for experienced D programmers, and also as an introduction to D features for programmers new to D, and include sufficient examples of what should cause errors as well as what should be valid code. It helps make the language lighter to pick up and better maintained than if it had separate long books of official information for each of those 5 purposes. So the complaint that errors should have a "red background" is classic bikeshedding about what color to paint the bikeshed. Most people don't have any difficulty seeing "// error" at or near the end of a line as a clear marker that the whole line is an error before they start reading the line as if it might be valid, shifting their intuition of what the text is trying to say, then have the ending surprise them. Most people don't turn around and then think "// ok" is a surprise ending either. Most people don't have any difficulty scanning for sets of valid formulas or sentences to use, or scanning for sets of errors or mistakes to avoid, when incorrect and correct lines are interspersed randomly in a reference or textbook. Most programmers can handle languages that reverse the order of "if" statements or the order of declaration and use just as well. So putting the indicators of whether a line is an error or correct at the end of a line is an arbitrary, harmless choice. If a significant number of people did have any problem with that, it would have been cleaned up already. So obviously it isn't a problem and it's just a ridiculous, whiny complaint.
Aug 22 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 21/08/16 12:47, ag0aep6g wrote:
 On 08/21/2016 07:12 AM, Shachar Shemesh wrote:
 During static analysis, keep both the "most expanded" and the "least
 expanded" type of the expression parsed so far. "Least expanded" is the
 largest type actually used in the expression.
What's "most expanded"?
As expanded as we plan on making it. In our current semantics, "int" or "uint".
 Upon use of the value, resolve which type to actually use for it. If the
 use type requests a type between least and most, use that type for
 evaluating the entire expression. If the use requests a type outside
 that range, use the one closest (and, if the use is below the range,
 complain about narrowing conversion).
So when only ubytes are involved, all calculations would be done on ubytes, no promotions, right? There are cases where that would give different results than doing promotions. Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands are promoted to a larger type, you get 255 as the result. If they are not, you have the equivalent of `ubyte x = 255; x *= 2; x /= 2;` which gives you 127.
You are right. This is a hole in this suggestion. Let me think if it is plugable. Shachar
Aug 21 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 22 August 2016 at 05:54:17 UTC, Shachar Shemesh wrote:
 On 21/08/16 12:47, ag0aep6g wrote:
 Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands 
 are
 promoted to a larger type, you get 255 as the result. If they 
 are not,
 you have the equivalent of `ubyte x = 255; x *= 2; x /= 2;` 
 which gives
 you 127.
You are right. This is a hole in this suggestion. Let me think if it is plugable.
I actually consider that no different than `float a = int(1) / int(2);` and see it as a feature. But, of course, it does fall under the category of silent breaking change (well, we could warn, but still).
Aug 22 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/21/2016 01:12 AM, Shachar Shemesh wrote:
 I'll suggest an algorithmic definition of (my interpretation of) Adam's
 proposal:

 During static analysis, keep both the "most expanded" and the "least
 expanded" type of the expression parsed so far. "Least expanded" is the
 largest type actually used in the expression.

 Upon use of the value, resolve which type to actually use for it. If the
 use type requests a type between least and most, use that type for
 evaluating the entire expression. If the use requests a type outside
 that range, use the one closest (and, if the use is below the range,
 complain about narrowing conversion).

 If more than one use is possible (i.e. - overloading), use the largest
 one applicable.
How is this different than VRP? -- Andrei
Aug 21 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/20/2016 11:25 AM, Shachar Shemesh wrote:
 On 20/08/16 00:51, Walter Bright wrote:
 On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:
 Alas, C insisted on making everything int all the time and D followed
 that :(
Actually, Adam's suggestion on how things should work is precisely how C works (except it trails off at int). a = b + c; if b and c are both a byte, and a is a byte, the result is unpromoted. If a is a short, the result is promoted. I know the mechanism is completely different than what Adam was suggesting, but the end result is precisely the same.
Consider: void fun(byte); void fun(int); fun(b + c); Under the new rule, this code (and much more) would silently change behavior. How would that get fixed?
 One would have to be *really* sure of their ground in coming up with
 allegedly better rules.
Would "no narrowing implicit casts" be considered such a better rule? :-) Again, I'm not saying it's a bad rule, just that does have consequences. What I'm saying is that we are, already, changing things.
Again: choose your fights/points and fight/make them well. This is not one worth having. Andrei
Aug 21 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 21 August 2016 at 16:31:41 UTC, Andrei Alexandrescu 
wrote:
 Consider:

 void fun(byte);
 void fun(int);
 fun(b + c);
Does anybody actually do that in the real world? Given the int promotion rule, such an overload is something i'd flag as always bug prone and confusing anyway. With D's current rules, I am more likely to make just the int version and cast stuff down inside to get user code to compile more easily. My color.d, for example, has this: /// Construct a color with the given values. They should be in range 0 <= x <= 255, where 255 is maximum intensity and 0 is minimum intensity. nothrow pure nogc this(int red, int green, int blue, int alpha = 255) { // workaround dmd bug 10937 if(__ctfe) this.components[0] = cast(ubyte) red; else this.r = cast(ubyte) red; this.g = cast(ubyte) green; this.b = cast(ubyte) blue; this.a = cast(ubyte) alpha; } Just because I got sick of constantly doing the casts on the user side. VRP is brilliant in little cases, but the fact that it doesn't work across statements really hurts it in real world use. These casts are arguably wrong, defeating the point of the no implicit narrowing rule, but when a rule is so annoying that you hack around it, it has already failed.
Aug 22 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 21/08/16 19:31, Andrei Alexandrescu wrote:
 On 08/20/2016 11:25 AM, Shachar Shemesh wrote:
 On 20/08/16 00:51, Walter Bright wrote:
 On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:
 Alas, C insisted on making everything int all the time and D followed
 that :(
Actually, Adam's suggestion on how things should work is precisely how C works (except it trails off at int). a = b + c; if b and c are both a byte, and a is a byte, the result is unpromoted. If a is a short, the result is promoted. I know the mechanism is completely different than what Adam was suggesting, but the end result is precisely the same.
Consider: void fun(byte); void fun(int); fun(b + c); Under the new rule, this code (and much more) would silently change behavior. How would that get fixed?
Not under my suggested implementation:
 If more than one use is possible (i.e. - overloading), use the largest one
applicable.
Shahcar
Aug 22 2016
parent reply Markus <markus orm.ich> writes:
Take a look on this discussion thread and you know WHY D IS NOT 
SO POPULAR.

The community discusses technical details and compares D to C++, 
but there is no clear mission statement, there is no vision 
statement and no marketing.

Often you merchandise D as a "system programming language", but 
the market for  "system programming language" is tiny.

D offers so much more, it is the most mature "modern" compiler 
language with thread-local first principle, which makes it to the 
best choice for modern server programming projects. It's meta 
programing facilities gives you a rich base for high level large 
scale business application projects. Its embedded testing, the 
module concept ... are great for large scale projects.

I want to use D in an in-house project for a while, but D's 
marketing is so bad, that it is nearly impossible to convince the 
management. They feel, that D is instable (much to high version 
frequency), D is only "a kind of C++" and has no own ecosystem, 
and there is no (commercial) support.

 From my point of view you need to get out of "systems programming 
language" niche and have to avoid the never ending public detail 
discussion. Try to position D as THE all purpose programming 
language for bigger teams. Do better documentation, update 
Andrei's book so that it is THE BOOK OF D. Maybe you have to 
split dlang.org into one site facing your customers (as me) and 
one (more internal) site for discussions and further developement.
Change your release-concept in that way, that you have 
LTS-releases for your customers (as me) and more experimental 
releases for your compiler/lib-developer community.

And do marketing, marketing, marketing. Give talks, write (enrty 
level) articles for popular magazines ..

Regards

Markus
Aug 29 2016
parent reply eugene <egordeev18 gmail.com> writes:
On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:
 Take a look on this discussion thread and you know WHY D IS NOT 
 SO POPULAR.

 The community discusses technical details and compares D to 
 C++, but there is no clear mission statement, there is no 
 vision statement...
Hello, the url https://dlang.org/overview.html states that "It's a practical language for practical programmers", i think this is the vision statement)))
Aug 29 2016
parent reply Markus <markus orm.ich> writes:
On Monday, 29 August 2016 at 14:31:50 UTC, eugene wrote:
 On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:
 Take a look on this discussion thread and you know WHY D IS 
 NOT SO POPULAR.

 The community discusses technical details and compares D to 
 C++, but there is no clear mission statement, there is no 
 vision statement...
Hello, the url https://dlang.org/overview.html states that "It's a practical language for practical programmers", i think this is the vision statement)))
Take a look on https://dlang.org/ : "D is a systems programming language with C-like syntax..." The overview-page http://dlang.org/overview.html has two main sections which compares D with C++. The tour https://tour.dlang.org/ is nearly empty, but on the first page it states that D is an "evolution of C++ (without the mistakes)" (the real content is hidden in the menu-sections). Most of the (very good) articles in https://dlang.org/articles.html compare D-features with C++. If I want to learn how D templates work, I do not need to know what is bad in C++-Templates. From my point of view this misleading for people comming to D first time. D is a mature full featured language by its own. D has its roots in C++ (and C) but is full fledged now and should represent its features and strength with continuously referencing C++ and without this repetitive "without mistakes". Many young people are looking for alternatives to the boring Java Ecosystem. If you position D in the, from there perspective, grandparents-language C++ edge, you will miss them. Regards Markus
Aug 30 2016
next sibling parent reply Markus <markus orm.ich> writes:
On Tuesday, 30 August 2016 at 07:56:06 UTC, Markus wrote:
 On Monday, 29 August 2016 at 14:31:50 UTC, eugene wrote:
 On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:
[...]
Hello, the url https://dlang.org/overview.html states that "It's a practical language for practical programmers", i think this is the vision statement)))
Take a look on https://dlang.org/ : "D is a systems programming language with C-like syntax..." The overview-page http://dlang.org/overview.html has two main sections which compares D with C++. The tour https://tour.dlang.org/ is nearly empty, but on the first page it states that D is an "evolution of C++ (without the mistakes)" (the real content is hidden in the menu-sections). Most of the (very good) articles in https://dlang.org/articles.html compare D-features with C++. If I want to learn how D templates work, I do not need to know what is bad in C++-Templates. From my point of view this misleading for people comming to D first time. D is a mature full featured language by its own. D has its roots in C++ (and C) but is full fledged now and should represent its features and strength with continuously referencing C++ and without this repetitive "without mistakes". Many young people are looking for alternatives to the boring Java Ecosystem. If you position D in the, from there perspective, grandparents-language C++ edge, you will miss them. Regards Markus
Sorry, two typos, should be read as: ... D has its roots in C++ (and C) but is full fledged now and should represent its features and strength WITHOUT continuously referencing C++ and without this repetitive "without mistakes". ... From my point of view this is misleading for people coming to D first time.
Aug 30 2016
parent reply eugene <egordeev18 gmail.com> writes:
On Tuesday, 30 August 2016 at 08:00:35 UTC, Markus wrote:
 D has its roots in C++ (and C) but is full fledged now and 
 should
 represent its features and strength WITHOUT continuously
 referencing C++ and without this repetitive "without mistakes".
 ...
 From my point of view this is misleading for people coming to D
 first time.
i think it is to invite C\C++ developers to use D instead of what they now use. I dont think D currently can supersede neither C\C++ nor java, since both sides have a huge amount of libs, frameworks as it's a key why they are still highly used, though java lacks in speed of evolution and C++ is becoming more complex and C lacks abstractions like OOP
Aug 30 2016
parent reply John Burrton <john.burton jbmail.com> writes:
On Tuesday, 30 August 2016 at 08:34:23 UTC, eugene wrote:
 On Tuesday, 30 August 2016 at 08:00:35 UTC, Markus wrote:
 D has its roots in C++ (and C) but is full fledged now and 
 should
 represent its features and strength WITHOUT continuously
 referencing C++ and without this repetitive "without mistakes".
 ...
 From my point of view this is misleading for people coming to D
 first time.
i think it is to invite C\C++ developers to use D instead of what they now use. I dont think D currently can supersede neither C\C++ nor java, since both sides have a huge amount of libs, frameworks as it's a key why they are still highly used, though java lacks in speed of evolution and C++ is becoming more complex and C lacks abstractions like OOP
One thing that put me off looking a D again for a long time was the code example on the front page. Perhaps like many people, I like C, I liked early C++ as being a much better C, but I look at "Modern" C++ with dismay. I liked C and early C++ because they were systems programming languages, where you could always see and understand the mapping from the language to the underlying machine, both for instructions and memory usage. Modern C++ has lost this. It's no longer considered "best practice" to write code that maps directly to simple machine constructs and use libraries when you want something "bigger". I look at C++ with dismay now. Everything they added works by "magic" or template "tricks" where you have little or no idea how the underlying code works or how memory is used without going into real depth. This is why I've looked for a new language and I think D fits that quite well. It's not lost the plot like C++ seems to have done. it's simple to write and understand, but it has higher level constructs when you want them. This is why the example on the front page put me off for a long time :- stdin .byLineCopy .array .sort!((a, b) => a > b) // descending order .each!writeln; It makes the language look like some weird high level functional language where you don't ask how it works and you shouldn't care how it maps to the machine instructions and memory. I realize that the same is actually fairly simple using ranges etc. and have no complaints about the code or having it as a sample. But it reminded me of haskel and functional programming, and memory management where it all just works "by magic" and you're patted on the head and told not to worry about it. I feel this is a good example for later on, and I'm in no way complaining about the code but a very bad thing for the first thing you see on the front page. I'm willing to admit I might be the only one :P But I'd much rather see the "better C" side as my first view of typical D code than this.
Aug 30 2016
next sibling parent John Burton <john.burton jbmail.com> writes:
On Tuesday, 30 August 2016 at 10:50:17 UTC, John Burton wrote:
 I'm willing to admit I might be the only one :P But I'd much 
 rather see the "better C" side as my first view of typical D 
 code than this.
And I want to be clear... None of this is a complaint. I just wanted to post what personally put me off looking at D again for a while as a data point :)
Aug 30 2016
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 30 August 2016 at 10:50:17 UTC, John Burrton wrote:

 This is why the example on the front page put me off for a long 
 time :-

     stdin
         .byLineCopy
         .array
         .sort!((a, b) => a > b) // descending order
         .each!writeln;

 It makes the language look like some weird high level 
 functional language where you don't ask how it works and you 
 shouldn't care how it maps to the machine instructions and 
 memory.
I bet you if you had a C-style example on the front page, people would complain that it's old fashioned and not really different from C, and they'd ask "Why can't I do things like `stdin.byLineCopy.array.sort!((a, b) => ...` in D?".
Aug 30 2016
parent reply John Burton <john.burton jbmail.com> writes:
On Tuesday, 30 August 2016 at 11:17:33 UTC, Chris wrote:
 On Tuesday, 30 August 2016 at 10:50:17 UTC, John Burrton wrote:

 This is why the example on the front page put me off for a 
 long time :-

     stdin
         .byLineCopy
         .array
         .sort!((a, b) => a > b) // descending order
         .each!writeln;

 It makes the language look like some weird high level 
 functional language where you don't ask how it works and you 
 shouldn't care how it maps to the machine instructions and 
 memory.
I bet you if you had a C-style example on the front page, people would complain that it's old fashioned and not really different from C, and they'd ask "Why can't I do things like `stdin.byLineCopy.array.sort!((a, b) => ...` in D?".
Yeah I know... As I said not really a complaint ... But it d make me think d was too high level a language with too much 'magic' . Other people will have different opinions
Aug 30 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 30 August 2016 at 11:29:45 UTC, John Burton wrote:
 As I said not really a complaint ... But it d make me think d 
 was too high level a language with too much 'magic' . Other 
 people will have different opinions
Indeed, I'm not a fan of that example either... but we could turn this weakness into a strength: have two side-by-side implementations and emphasize that the same language handles both styles.
Aug 30 2016
next sibling parent reply eugene <egordeev18 gmail.com> writes:
On Tuesday, 30 August 2016 at 13:34:05 UTC, Adam D. Ruppe wrote:
 On Tuesday, 30 August 2016 at 11:29:45 UTC, John Burton wrote:
 As I said not really a complaint ... But it d make me think d 
 was too high level a language with too much 'magic' . Other 
 people will have different opinions
Indeed, I'm not a fan of that example either... but we could turn this weakness into a strength: have two side-by-side implementations and emphasize that the same language handles both styles.
i think it will lead to something like: "Why do they have different examples for the same thing?" or "Why there are only few different examples to do the same thing? I thought D could give me more abilities" and so on)))
Aug 30 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 30 August 2016 at 13:42:21 UTC, eugene wrote:
 i think it will lead to something like: "Why do they have 
 different examples for the same thing?"
<h1>D is multi paradigm:</h1> <code> C style example </code> <code> functional style example </code> <p>With D, your existing expertise carries over from C while opening doors to new stuff.</p> <hr> <h1>D is whatever</h1> <code> example reinforces header </code> <p>Explanation here. <a href="federalnetwork">Would you like to know more?</a></p> that's how I'd do it, the code and surrounding text reinforce each other.
Aug 30 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/30/2016 10:04 AM, Adam D. Ruppe wrote:
 <code> C style example </code>
 <code> functional style example </code>
That doesn't sounds like a good idea. -- Andrei
Aug 30 2016
prev sibling parent eugene <egordeev18 gmail.com> writes:
On Tuesday, 30 August 2016 at 13:34:05 UTC, Adam D. Ruppe wrote:
 On Tuesday, 30 August 2016 at 11:29:45 UTC, John Burton wrote:
 As I said not really a complaint ... But it d make me think d 
 was too high level a language with too much 'magic' . Other 
 people will have different opinions
Indeed, I'm not a fan of that example either... but we could turn this weakness into a strength: have two side-by-side implementations and emphasize that the same language handles both styles.
another way is to fulfill the FAQ page with questions and answers from the forum so newbies could first read the page before thinking and asking what others thought and asked before))) but then the FAQ page must reside as a link in the header, e.g. between "Learn" and "Documentation" and forum must state: "first look at FAQ then ask question" like the way on StackOverflow.com
Aug 30 2016
prev sibling next sibling parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D
Subject: Re: Why D is not popular enough?
References: <fovgxbqlwnpantfwqhlf forum.dlang.org>
 <noqbpd$1121$1 digitalmars.com> <noqdi0$13ob$1 digitalmars.com>
 <mailman.968.1471232459.3131.digitalmars-d puremagic.com>
 <norf57$2mu7$1 digitalmars.com> <gotwqwrklefthzsmzzaa forum.dlang.org>
 <dgaoyxmwzmozqvhkazft forum.dlang.org> <np7v0p$2qgd$1 digitalmars.com>
 <np9soo$295v$1 digitalmars.com> <npcl1d$2vgl$1 digitalmars.com>
 <npet31$2vnh$1 digitalmars.com> <wohfqgwucwtpawzspofc forum.dlang.org>
 <cmkdeeernialawyvunul forum.dlang.org> <rsocrlywlrqwpshweoml forum.dlang.org>
 <lgrsbvxozczvwzhknfnj forum.dlang.org> <tybmypxbzeujhfmbvihl forum.dlang.org>
 <pauycpiwvpnmzguguwhj forum.dlang.org>
In-Reply-To: <pauycpiwvpnmzguguwhj forum.dlang.org>

--SC4mD97WGt8lDvNtqNOU48V8ogQtmCccB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 08/30/2016 01:50 PM, John Burrton wrote:
 This is why the example on the front page put me off for a long time :-=
=20
     stdin
         .byLineCopy
         .array
         .sort!((a, b) =3D> a > b) // descending order
         .each!writeln;
=20
 It makes the language look like some weird high level functional
 language where you don't ask how it works and you shouldn't care how it=
 maps to the machine instructions and memory.
On a related point I think it is important to emphasize that such pipelines are cool not because they look high-level but also because with decent inlinining compiler (LDC/GDC) they generate as efficient code as for hand written C style implementation based on loop. There are plenty of languages that allow similar kind of high level programming but it usually comes with considerable overhead, contrary to = D. Though this specific is not very good as it requires lot of allocation by the algorithm used. My favorite short snippet I commonly use when evangelizing D is splitting stdin by whitespaces: void main ( ) { import std.stdio, std.algorithm, std.uni; stdin .byLine // note that no byLineCopy is needed here .map!(line =3D> line.splitter!isWhite) .joiner .each!writeln; } It is 100% Unicode correct, does not allocate any memory garbage and does exactly what told to do while being orders of magnitude more readable than any C style loop version one can come up with. --SC4mD97WGt8lDvNtqNOU48V8ogQtmCccB--
Aug 30 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/30/2016 06:50 AM, John Burrton wrote:
 This is why the example on the front page put me off for a long time :-

     stdin
         .byLineCopy
         .array
         .sort!((a, b) => a > b) // descending order
         .each!writeln;
Sadly if this doesn't float your boat you're unlikely to enjoy most of what D has to offer. -- Andrei
Aug 30 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu 
wrote:
 Sadly if this doesn't float your boat you're unlikely to enjoy 
 most of what D has to offer. -- Andrei
This might be the most wrong statement you have ever said on this forum. D's biggest appeal to me is that it *doesn't* force me to use whatever bizarre style is popular this month. It is multiparadigm out of the box, and flexible enough to adapt to new paradigms as they happen.
Aug 30 2016
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/30/2016 10:19 AM, Adam D. Ruppe wrote:
 On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu wrote:
 Sadly if this doesn't float your boat you're unlikely to enjoy most of
 what D has to offer. -- Andrei
This might be the most wrong statement you have ever said on this forum.
I'm sure I said much worse! :o) -- Andrei
Aug 30 2016
prev sibling parent reply CRAIG DILLABAUGH <craig.dillabaugh gmail.com> writes:
On Tuesday, 30 August 2016 at 14:19:02 UTC, Adam D. Ruppe wrote:
 On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu 
 wrote:
 Sadly if this doesn't float your boat you're unlikely to enjoy 
 most of what D has to offer. -- Andrei
This might be the most wrong statement you have ever said on this forum. D's biggest appeal to me is that it *doesn't* force me to use whatever bizarre style is popular this month. It is multiparadigm out of the box, and flexible enough to adapt to new paradigms as they happen.
I am going to vote with Adam here. If memory serves me correctly what initially drew me in to the D language was a statement on the main page that "D is not a religion". I think at the time I had been doing some work with Java, where everything had to be an object. Man, I hate Java for that. Also, I think saying if you don't like functional programming you will miss 'most' of what D has to offer is really selling the language short. After all you can write C or C++ style code in D if you want, which may be very attractive to some folks.
Aug 30 2016
parent reply Bienlein <jeti789 web.de> writes:
On Tuesday, 30 August 2016 at 18:36:19 UTC, CRAIG DILLABAUGH 
wrote:
 I am going to vote with Adam here.  If memory serves me 
 correctly what initially drew me in to the D language was a 
 statement on the main page that "D is not a religion".  I think 
 at the time I had been doing some work with Java, where 
 everything had to be an object. Man, I hate Java for that.
Many of the inconsitencies and problems in Java come from basic types not being objects. Everything being objects is a great way to keep things easy to understand, consistent and clean. It has some impact on performance, but a lot can be done here which is more than sufficient for application programming. Hot Spot runtime code optimization in Java is very effective.
 Also, I think saying if you don't like functional programming 
 you will miss 'most' of what D has to offer is really selling 
 the language short.  After all you can write C or C++ style 
 code in D if you want, which may be very attractive to some 
 folks.
D has a lot to offer with regard to functional programming. It has pure functions and true immutable classes (true = also sub objects become immutable), which Scala all doesn't have (because of restrictions of the JVM). Does D have tail call recursion optimization? I don't know, actually. If D had that and pattern matching, it would beat Scala with all it's hype by a big leap.
Sep 01 2016
parent reply qznc <qznc web.de> writes:
On Thursday, 1 September 2016 at 08:04:00 UTC, Bienlein wrote:
 D has a lot to offer with regard to functional programming. It 
 has pure functions and true immutable classes (true = also sub 
 objects become immutable), which Scala all doesn't have 
 (because of restrictions of the JVM). Does D have tail call 
 recursion optimization? I don't know, actually. If D had that 
 and pattern matching, it would beat Scala with all it's hype by 
 a big leap.
D does not guarantee tail calls, but the compiler might sometimes decide to do it. Functional programmer usually want to guarantee, so they don't have to write a loop. The downside of TCO is that the stack trace is missing frames, which can be very confusing. D has no syntax for pattern matching, but some library support: https://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching
Sep 01 2016
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 1 September 2016 at 12:04:51 UTC, qznc wrote:
 On Thursday, 1 September 2016 at 08:04:00 UTC, Bienlein wrote:
 D has a lot to offer with regard to functional programming. It 
 has pure functions and true immutable classes (true = also sub 
 objects become immutable), which Scala all doesn't have 
 (because of restrictions of the JVM). Does D have tail call 
 recursion optimization? I don't know, actually. If D had that 
 and pattern matching, it would beat Scala with all it's hype 
 by a big leap.
D does not guarantee tail calls, but the compiler might sometimes decide to do it. Functional programmer usually want to guarantee, so they don't have to write a loop. The downside of TCO is that the stack trace is missing frames, which can be very confusing.
There's a DIP about adding a TCO attribute/pragma: https://github.com/dlang/DIPs/pull/6 FYI: There's some discussion about it's benefit in comparison to functional language D does have loops and it's a lot easier to write and read them. If you want to chime in, please do so at the PR discussion.
 D has no syntax for pattern matching, but some library support:
 https://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching
Yep it's pretty easy to do within library code, if you use an object chain you might also want to have a look at castSwitch. https://dlang.org/phobos/std_algorithm_comparison.html#.castSwitch
Sep 01 2016
parent bachmeier <no spam.net> writes:
On Thursday, 1 September 2016 at 17:10:00 UTC, Seb wrote:

 FYI: There's some discussion about it's benefit in comparison 
 to functional language D does have loops and it's a lot easier 
 to write and read them.
Some are of that opinion. However, this is D, not Python or Go, so claims about the one true preference is not a valid argument against a particular feature.
Sep 01 2016
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu 
wrote:
 On 08/30/2016 06:50 AM, John Burrton wrote:
 This is why the example on the front page put me off for a 
 long time :-

     stdin
         .byLineCopy
         .array
         .sort!((a, b) => a > b) // descending order
         .each!writeln;
Sadly if this doesn't float your boat you're unlikely to enjoy most of what D has to offer. -- Andrei
That particular bit of code doesn't really ring "pragmatic", just "clever". Honestly the front page examples are just scary. // Round floating point numbers import std.algorithm, std.conv, std.functional, std.math, std.regex, std.stdio; alias round = pipe!(to!real, std.math.round, to!string); static reFloatingPoint = ctRegex!`[0-9]+\.[0-9]+`; void main() { // Replace anything that looks like a real // number with the rounded equivalent. stdin .byLine .map!(l => l.replaceAll!(c => c.hit.round) (reFloatingPoint)) .each!writeln; } A clever and impractical piece of program that is hard to read for most programmers.
Aug 30 2016
prev sibling parent John Burton <john.burton jbmail.com> writes:
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu 
wrote:
 On 08/30/2016 06:50 AM, John Burrton wrote:
 This is why the example on the front page put me off for a 
 long time :-

     stdin
         .byLineCopy
         .array
         .sort!((a, b) => a > b) // descending order
         .each!writeln;
Sadly if this doesn't float your boat you're unlikely to enjoy most of what D has to offer. -- Andrei
I tried hard not to be misunderstood. My problem isn't with this *code*. I think the fact that you can do this in D and it's still in general likely to be close or equal to the efficiency of a handwritten loop is awesome and a great reason to use the language. I WANT to write code like this. This is a problem with my perception. That such code was necessarily going to be slow and bloated compared with C loops. Which of course isn't true in D but I've seen that promise so many times before that I took a look and thought, nice... but not the language I want. I wonder how many other people did the same. Anyway I'll shut up now, I don't want any of this to sound like a criticism. If anything it was my mistake, but one that the example lead me to, wrongly :)
Aug 30 2016
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 30 August 2016 at 07:56:06 UTC, Markus wrote:

 Most of the (very good) articles in 
 https://dlang.org/articles.html compare D-features with C++. If 
 I want to learn how D templates work, I do not need to know 
 what is bad in C++-Templates.
True. Any C++ programmer interested in this topic will see the differences anyway (or refer them to the section "D for C++ programmers").
 From my point of view this misleading for people comming to D 
 first time. D is a mature full featured language by its own. D 
 has its roots in C++ (and C) but is full fledged now and should 
 represent its features and strength with continuously 
 referencing C++ and without this repetitive "without mistakes".
The D community always links D to C++, which makes D look like the eternal "wanna be" or "runner-up". D has developed its own "style" and should no longer be compared to C++ feature by feature. It's useless because it's no longer applicable.
 Many young people are looking for alternatives to the boring 
 Java Ecosystem. If you position D in the, from there 
 perspective, grandparents-language C++ edge, you will miss them.
You have a point there. It's been said time and again that trying to win over the C++ crowd (that has put years of work into mastering the language) will not generate many new D users (the odd one, alright). But D can attract users from Python and Java etc. It's time D became a bit more self-confident about its own achievements. It'd make more sense to compare D, in terms of outlook, features and solutions, to other newer languages like Nim, Go or Swift, because those new languages are the real competition, that's where people go when they look for new languages once they're unhappy with Java or Python or whatever. The constant references to C++ are understandable, though, if you consider that both Walter and Andrei come from a C++ background, so the whole issue of C++ may loom larger in their minds than in yours or mine.
Aug 30 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 3:42 AM, Chris wrote:
 [...]
I agree it's time to remove comparisons with C++, although there is room for a "D for C++ Programmers" section and, of course, "Interfacing D to C++".
Aug 30 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 11:22 AM, Walter Bright wrote:
 On 8/30/2016 3:42 AM, Chris wrote:
 [...]
I agree it's time to remove comparisons with C++, although there is room for a "D for C++ Programmers" section and, of course, "Interfacing D to C++".
https://github.com/dlang/dlang.org/pull/1459
Aug 30 2016
prev sibling parent Chris <wendlec tcd.ie> writes:
On Tuesday, 30 August 2016 at 18:22:59 UTC, Walter Bright wrote:
 On 8/30/2016 3:42 AM, Chris wrote:
 [...]
I agree it's time to remove comparisons with C++, although there is room for a "D for C++ Programmers" section and, of course, "Interfacing D to C++".
I think this will do D good in the long run.
Aug 31 2016
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/30/2016 03:56 AM, Markus wrote:
 On Monday, 29 August 2016 at 14:31:50 UTC, eugene wrote:
 On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:
 Take a look on this discussion thread and you know WHY D IS NOT SO
 POPULAR.

 The community discusses technical details and compares D to C++, but
 there is no clear mission statement, there is no vision statement...
Hello, the url https://dlang.org/overview.html states that "It's a practical language for practical programmers", i think this is the vision statement)))
Take a look on https://dlang.org/ : "D is a systems programming language with C-like syntax..." The overview-page http://dlang.org/overview.html has two main sections which compares D with C++.
I think we'd do good to avoid explicit comparison with specific languages, within reason. Focusing on what makes D unique and interesting across _all_ languages on the landscape is a much more fertile approach. Andrei
Aug 30 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 12:56 AM, Markus wrote:
 The tour https://tour.dlang.org/ is nearly empty, but on the first page it
 states that D is an "evolution of C++ (without the mistakes)" (the real content
 is hidden in the menu-sections).
I was going to fix that, but can't find where it is on github. The "Open Source" links to https://github.com/stonemaster/dlang-tour, but it isn't there.
Aug 30 2016
parent reply mate <aiueo aiueo.aiueo> writes:
On Tuesday, 30 August 2016 at 20:25:42 UTC, Walter Bright wrote:
 On 8/30/2016 12:56 AM, Markus wrote:
 The tour https://tour.dlang.org/ is nearly empty, but on the 
 first page it
 states that D is an "evolution of C++ (without the mistakes)" 
 (the real content
 is hidden in the menu-sections).
I was going to fix that, but can't find where it is on github. The "Open Source" links to https://github.com/stonemaster/dlang-tour, but it isn't there.
Found it here: https://github.com/dlang-tour/english/blob/master/welcome/welcome-to-d.md But it has many offspring to be updated as well: https://github.com/dlang-tour/japanese/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/german/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/chinese/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/italian/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/spanish/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/turkish/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/romanian/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/french/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/swedish/blob/master/welcome/welcome-to-d.md
Aug 30 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 2:41 PM, mate wrote:
 On Tuesday, 30 August 2016 at 20:25:42 UTC, Walter Bright wrote:
 On 8/30/2016 12:56 AM, Markus wrote:
 The tour https://tour.dlang.org/ is nearly empty, but on the first page it
 states that D is an "evolution of C++ (without the mistakes)" (the real content
 is hidden in the menu-sections).
I was going to fix that, but can't find where it is on github. The "Open Source" links to https://github.com/stonemaster/dlang-tour, but it isn't there.
Found it here: https://github.com/dlang-tour/english/blob/master/welcome/welcome-to-d.md
Oh, I see the problem. I was looking at: https://github.com/stonemaster/dlang-tour when I should have looked at: https://github.com/dlang-tour Looks like the link at https://tour.dlang.org/ needs fixing?
Aug 30 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 2:41 PM, mate wrote:
 On Tuesday, 30 August 2016 at 20:25:42 UTC, Walter Bright wrote:
 On 8/30/2016 12:56 AM, Markus wrote:
 The tour https://tour.dlang.org/ is nearly empty, but on the first page it
 states that D is an "evolution of C++ (without the mistakes)" (the real content
 is hidden in the menu-sections).
I was going to fix that, but can't find where it is on github. The "Open Source" links to https://github.com/stonemaster/dlang-tour, but it isn't there.
Found it here: https://github.com/dlang-tour/english/blob/master/welcome/welcome-to-d.md But it has many offspring to be updated as well: https://github.com/dlang-tour/japanese/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/german/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/chinese/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/italian/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/spanish/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/turkish/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/romanian/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/french/blob/master/welcome/welcome-to-d.md https://github.com/dlang-tour/swedish/blob/master/welcome/welcome-to-d.md
Thanks for your help! https://github.com/dlang-tour/english/pull/91
Aug 30 2016
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Wednesday, 31 August 2016 at 01:12:10 UTC, Walter Bright wrote:
 On 8/30/2016 2:41 PM, mate wrote:
[...]
Thanks for your help! https://github.com/dlang-tour/english/pull/91
Your change just went live http://tour.dlang.org ;)
Aug 30 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 6:30 PM, ZombineDev wrote:
 Your change just went live
 http://tour.dlang.org ;)
Thanks! Note that the other languages need updating, too.
Aug 30 2016
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 31 August 2016 at 04:03:32 UTC, Walter Bright wrote:
 On 8/30/2016 6:30 PM, ZombineDev wrote:
 Your change just went live
 http://tour.dlang.org ;)
Thanks! Note that the other languages need updating, too.
Done (FYI the translations aren't officially published yet) ;-)
Aug 31 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2016 2:17 AM, Seb wrote:
 Done (FYI the translations aren't officially published yet) ;-)
Danke schoen!
Aug 31 2016
prev sibling parent John Smith <gyroheli gmail.com> writes:
On Friday, 19 August 2016 at 02:59:40 UTC, Adam D. Ruppe wrote:
 On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:
 Garbage collector is in a few libraries as well. I think the 
 only problem I had with that is that the std.range library has 
 severely reduced functionality when using static arrays.
std.range is one of the libraries that has never used the GC much. Only tiny parts of it ever have, Moreover, dynamic arrays do not necessarily have to be GC'd. Heck, you can even malloc them if you want to (`(cast(int*)malloc(int.sizeof))[0 .. 1]` gives an int[] of length 1). This has been a common misconception lately... :(
Never really said that was the case. The restriction was caused for the need to be able to change the length of the array. Which you can't do: (cast(int*)malloc(int.sizeof))[0 .. 1].length = 0. If that wasn't std.range then it was something else, it's been a while since I used it.
Aug 21 2016
prev sibling next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 18 Aug 2016 22:50:27 +0000
schrieb John Smith <gyroheli gmail.com>:

 Well you could say the same for the same for int. Why isn't "int 
 + int = long"? Right now it is following the rule "int + int = 
 int".
I believe in C, int reflects the native machine word that the CPU always uses to perform arithmetics. Together with undefined overflow behavior (due to allowing different HW implementations) of signed types I suppose it was the best bet to at least widen smaller types to that type. Even on today's amd64 CPUs int/uint remain the most efficient integral type for multiplication and division. If we hypothetically switched to a ubyte+ubyte=ubyte semantic, then code like this breaks silently: ubyte a = 210; ubyte b = 244; float f = 1.1 * (a + b); Or otherwise instead of casting uints to ubytes you now start casting ubytes to uints all over the place. What we have is the guarantee that the result will reliably be at least 32-bit in D. -- Marco
Aug 19 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote:
 If we hypothetically switched to a ubyte+ubyte=ubyte semantic, 
 then code like this breaks silently:
However, if it took the entire statement into account, it could handle that... by my rule, it would see there's a float in there and thus automatically cast a and b to float before doing anything. The compiler would parse Assign(float, Multiply(float, Parenthetical(Add(a, b)))) In a semantic transformation step, it would see that since the lhs is float, the rhs is now casted to float, then it does that recursively through it all and a and b get promoted to float so the bits are never lost. I really do think that would work. Alas, I don't see D ever changing anyway, this is too deep in its C bones.
Aug 19 2016
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 19 Aug 2016 13:36:05 +0000
schrieb Adam D. Ruppe <destructionator gmail.com>:

 On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote:
 If we hypothetically switched to a ubyte+ubyte=ubyte semantic, 
 then code like this breaks silently:  
However, if it took the entire statement into account, it could handle that... by my rule, it would see there's a float in there and thus automatically cast a and b to float before doing anything.
Float math is slow compared to integer math and precision loss occurs when this rule is also applied to (u)int and (u)long with only the deprecated (as per amd64 spec) real type being large enough for 64-bit integers. -- Marco
Aug 19 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 19 August 2016 at 15:01:58 UTC, Marco Leise wrote:
 Float math is slow compared to integer math and precision loss
 occurs when this rule is also applied to (u)int and (u)long
 with only the deprecated (as per amd64 spec) real type being
 large enough for 64-bit integers.
You're working with float anyway, so I believe the price is paid even by today's C rules. The intermediates might be different though, I'm not sure.
Aug 19 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/19/2016 8:19 AM, Adam D. Ruppe wrote:
 You're working with float anyway, so I believe the price is paid even by
today's
 C rules.
Nope, the operands of integral sub-expressions are not promoted to float.
 The intermediates might be different though, I'm not sure.
Aug 19 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 19 August 2016 at 15:01:58 UTC, Marco Leise wrote:
 Am Fri, 19 Aug 2016 13:36:05 +0000
 schrieb Adam D. Ruppe <destructionator gmail.com>:

 On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote:
 If we hypothetically switched to a ubyte+ubyte=ubyte 
 semantic, then code like this breaks silently:
However, if it took the entire statement into account, it could handle that... by my rule, it would see there's a float in there and thus automatically cast a and b to float before doing anything.
Float math is slow compared to integer math and precision loss occurs when this rule is also applied to (u)int and (u)long with only the deprecated (as per amd64 spec) real type being large enough for 64-bit integers.
Try multiplications and divisions.
Sep 01 2016
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 August 2016 at 00:50, John Smith via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Well there are some things I feel could be improved, a lot of the things are
 really just minor but what is a deal breaker for me mostly is the compilers.
 The GCC and Clang implementations are really far behind in terms of the
 version, so they are missing a lot of features. A lot of the features that
 I'd want to use D for.
This is a constant vicious cycle. Sometimes I wonder of how better it would be for all if D was instead defined by a spec, not an implementation that adds small feature changes in an ad hoc manner as it sees fit.
Aug 20 2016
prev sibling parent Shachar Shemesh <shachar weka.io> writes:
On 14/08/16 21:35, Andrei Alexandrescu wrote:
 I should add that as long as the .di does not import the .d, the
 slowdown due to the computed table will not occur. So the worry is not
 warranted.
I'm not sure the above is true in cases of imports that are not circular for the optimal dis, but are circular when flattened. Then again, but I'm not close enough to the issue to say for sure. Shachar
Aug 14 2016
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/14/2016 11:03 AM, Shachar Shemesh wrote:
 Which rule?
The rule that says "ubyte + ubyte = uint".
Many people are surprised by this rule, but it is deeply embedded in C and C++. In C99, ------------------------------- 6.3.1.8 Usual Arithmetic Conversions Then the following rules are applied to the promoted operands: If both operands have the same type, then no further conversion is needed. Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank. Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type. Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type. Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type. -------------------------------------------- This rule was retained for D to make it easier to translate code from C/C++ to D. Changing the rule could result in subtle and invisible bugs for such translations and for C/C++ programmers who are so used to the integral promotion rules that they aren't even really aware of reliance upon them. The reason C/C++ programmers, even experienced ones, are often unaware of this rule is there is another rule, implicit narrowing, so: byte = byte + byte; compiles without complaint. The trouble comes when byte has a value, say, 255, and the sum is 510. The assignment silently chops it to byte size, and 254 is stored in the result. For D, we decided that silently converting 510 to 254 would not be acceptable. Hence an explicit cast would be required, byte = cast(byte)(byte + byte); where the user presumably knows what he's doing.
Aug 14 2016
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 14 August 2016 at 18:03:24 UTC, Shachar Shemesh wrote:
 
 I must confess that I have never heard of this rule in C 
 before encountering it in D.
Which rule?
The rule that says "ubyte + ubyte = uint".
https://www.google.fr/search?q=C+int+promotion+rules&ie=utf-8&oe=utf-8&client=firefox-b&gfe_rd=cr&ei=xaOxV5vuMpGx8weWtIawAw#q=c+int+promotion+rules+standard This is so central to understanding the C language that I'm surprized here. There's no forum, FAQ that doesn't mention it.
Aug 15 2016
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 08/14/2016 07:07 AM, Andrei Alexandrescu wrote:
 On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
 Also, part of our
 problems with this is that introspection also does not see refs, which
 causes the following two functions to report the same signature:

 void func1(int arg);
 void func2(ref int arg);
I actually think you can do introspection on any argument to figure whether it has "ref".
Yes, it exists. However, I tried std.traits.Parameters but that wasn't it. A colleague reminded us that it's std.traits.ParameterStorageClassTuple: http://dlang.org/phobos/std_traits.html#ParameterStorageClassTuple Ali
Aug 15 2016
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 15 Aug 2016 10:54:11 -0700
schrieb Ali =C3=87ehreli <acehreli yahoo.com>:

 On 08/14/2016 07:07 AM, Andrei Alexandrescu wrote:
  > On 08/14/2016 01:18 AM, Shachar Shemesh wrote: =20
=20
  >> Also, part of our
  >> problems with this is that introspection also does not see refs, which
  >> causes the following two functions to report the same signature:
  >>
  >> void func1(int arg);
  >> void func2(ref int arg); =20
  >
  > I actually think you can do introspection on any argument to figure
  > whether it has "ref". =20
=20
 Yes, it exists. However, I tried std.traits.Parameters but that wasn't=20
 it. A colleague reminded us that it's std.traits.ParameterStorageClassTup=
le:
=20
    http://dlang.org/phobos/std_traits.html#ParameterStorageClassTuple
=20
 Ali
=20
In fact, std.traits.Parameters _retains_ ref as long as you don't unpack the tuple: void foo(ref int); void bar(Parameters!foo args);=20 'bar' is now "void function(ref int)" You can then access 'args.length' and 'args[n]' to get at each argument or pass 'args' on as is to the next function. You can also create a ref argument for 'T' out of thin air by writing: alias RefArg =3D Parameters!((ref T) {}); Just remember that 'RefArg' is again a tuple and you always need to access args[0] to use it. --=20 Marco
Aug 19 2016
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
On Sun, 14 Aug 2016 08:18:08 +0300, Shachar Shemesh wrote:
 The first is that you can rarely put "const" on anything, meaning you
 lose the power that C++'s guarantee gave you, and not gain enough in
 return.
I can often put const on things. However, it's an added step, the compiler doesn't prompt me, and I can't add it everywhere. The result is that I make things const-correct about 2% of the time. If function parameters were const by default, that would prompt me to try to make my code const-correct. If there were a module-level annotation I could use to turn on const-by-default, I would use it.
Aug 14 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 12 August 2016 at 22:58:45 UTC, Steven Schveighoffer 
wrote:
 It's broken because it's inconsistent. If the compiler is going 
 to complain about races in one case, but not in other 
 equivalent cases, then the feature is useless.
If anything, it guarantee you that this kind of things will NEVER happen if not shared, which is in itself a huge benefit.
 If all I have to do to avoid compiler complaints is rewrite my 
 expression in an equivalent way, then what is the point of the 
 complaint? At that point, it's just a style guide.
The ways are equivalent only in the absence of race condition on a. This is not guaranteed for shared.
Aug 13 2016
prev sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 12 August 2016 at 18:04:53 UTC, Andrei Alexandrescu 
wrote:
 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
The problem is no one knows if it's broken or not because there is no official documentation saying what shared is supposed to do. This is all we get "The shared attribute modifies the type from T to shared(T), the same way as const does." https://dlang.org/spec/attribute.html
Aug 14 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, August 12, 2016 13:21:10 Steven Schveighoffer via Digitalmars-d 
wrote:
 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
 Honestly, I don't think that shared is broken.
Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!) The thing that is NOT broken is unshared. There's literally not much you can do with shared, and what you can do isn't consistent or useful. It needs lots of attention.
It does not surprise me in the least if there are bugs related to shared in the compiler, and we definitely don't deal with it properly in druntime with regards to stuff like Mutex and Condition. But I don't agree with the idea that shared is fundamentally broken. - Jonathan M Davis
Aug 12 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2016 11:34 AM, Jonathan M Davis via Digitalmars-d wrote:
 It does not surprise me in the least if there are bugs related to shared in
 the compiler, and we definitely don't deal with it properly in druntime with
 regards to stuff like Mutex and Condition. But I don't agree with the idea
 that shared is fundamentally broken.
I'd put it more as being largely unimplemented. However, it still works as separating by type data that is shared vs data that is local, and that is still immensely valuable. Also, one thing at a time. Scope has been largely unimplemented forever, and this DIP intends to fix that.
Aug 12 2016
prev sibling next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Fri, 12 Aug 2016 09:38:13 +0000, Guillaume Piolat wrote:
  From the best of my knowledge you cannot do these things in in
 C++:

 https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-
through-CTFE You can use an external tool at build time to do this, but it's awkward. (DMD, when it was C++-based, used that technique to generate a few things.)
 https://p0nce.github.io/d-idioms/#Embed-a-dynamic-library-in-an-
executable You need a resources script for it with MSVC++. If you're building an ELF executable, you can use `objcopy(1)` to convert a data file into an object file containing static data. Which is, I feel, the story of life using D vs C++. You can get it done in C++, but it might take some external tools, it's going to be awkward, and it's going to be different on every platform.
Aug 12 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 12/08/16 12:38, Guillaume Piolat wrote:
 From the best of my knowledge you cannot do these things in in C++:

 https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE
I maintain an open source program called fakeroot-ng. It is written in C++. Just today, while doing some cleanups, I ran across this point when trying to convert a table to const. So, yes, having a CTFE to compute the table would have been great, and had fakeroot-ng been written in D, I would have. Then again, the ultimate cost of not doing this is so low, that I didn't really feel cheated out of it. That table was not expensive to compute, and its constantness wasn't crucial enough even for me to put a wrapper pointer and only access it through it. Had that not been the case, and had that table been more expensive to computer, I'd probably compute at compile time with an external tool. The point is that while I missed have D's CTFE to compute that table, I didn't miss it much, and I don't miss D features often. Sadly, I cannot say the same thing about the things in C++ I miss when I write D. They are both everyday and, to me, without reasonable substitutes. Shachar
Aug 12 2016
next sibling parent reply =?UTF-8?B?bcO5c2Rs?= <mdsdl msdl.fr> writes:
On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:
 I cannot say the same thing about the things in C++ I miss when 
 I write D.
Be constructive and enumerate them.
Aug 12 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 12/08/16 17:50, mùsdl wrote:
 On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:
 I cannot say the same thing about the things in C++ I miss when I
 write D.
Be constructive and enumerate them.
I'll give some highlights, but those are, mostly, things that I've already listed in this forum and in my lightening talk. - No RAII support, despite the fact everybody here seems to think that D supports RAII. - Recursive const makes many cases where I can use const in C++ (and enjoy the protection it provides) simply mutable in D. - This one I have not complained about yet. Operator overloads stepping on each other's toes. In my case, I have a container (with opIndex that accepts a custom type and opOpAssign!"~") and I place in it a struct with some operator overloads as well (have not reduced the cause yet, hence no previous complaint about this one). So, when I write Container[IndexType] ~= Type; And the compiler assumes that means: Container.opIndexOpAssign!"~"(IndexType, Type); but since nothing like that is defined, the code doesn't compile. I ended up writing (actual code from the Weka code base): blockIds[diskIdx].opOpAssign!"~"(makeBlockId(stripeIdx+i, placement.to!SlotIdx(diskIdx))); Took me almost ten minutes and consulting someone else to find this solution. - GC. GC. GC. Some more GC. - Integral type operations promotion and the constant need for casts. - No warning for signed/unsigned comparisons. An unfailing source for bugs. - No ref type. These are just off the top of my head. There are more. Like I said, my frustrations with D are daily. Shachar
Aug 12 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2016 12:29 PM, Shachar Shemesh wrote:
 - No RAII support, despite the fact everybody here seems to think that D
 supports RAII.
Please explain.
 - Recursive const makes many cases where I can use const in C++ (and enjoy the
 protection it provides) simply mutable in D.
Right, in C++ you can have a const pointer to mutable. On the other hand, in C++ you cannot have 'const T' apply to what is accessible through T.
 - This one I have not complained about yet. Operator overloads stepping on each
 other's toes. In my case, I have a container (with opIndex that accepts a
custom
 type and opOpAssign!"~") and I place in it a struct with some operator
overloads
 as well (have not reduced the cause yet, hence no previous complaint about this
 one). So, when I write

 Container[IndexType] ~= Type;

 And the compiler assumes that means:
 Container.opIndexOpAssign!"~"(IndexType, Type);

 but since nothing like that is defined, the code doesn't compile. I ended up
 writing (actual code from the Weka code base):

 blockIds[diskIdx].opOpAssign!"~"(makeBlockId(stripeIdx+i,
 placement.to!SlotIdx(diskIdx)));

 Took me almost ten minutes and consulting someone else to find this solution.

 - GC. GC. GC. Some more GC.
 - Integral type operations promotion and the constant need for casts.
I don't understand this. Integral type promotions are the same as in C++. The casts are needed for integral type demotions (i.e. narrowing conversions). Having implicit narrowing conversions in C++ is a significant source of bugs, as the most significant bits are silently discarded.
 - No warning for signed/unsigned comparisons. An unfailing source for bugs.
Understood, but to be pedantic, such warnings are extensions to C++ compilers, not part of the language.
 - No ref type.
D has the ref storage class. What difference are you seeing?
Aug 12 2016
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote:
 - Recursive const makes many cases where I can use const in C++ 
 (and enjoy the protection it provides) simply mutable in D.
FWIW HeadConst can be easily done in a library and will hopefully soon be in Phobos. https://github.com/dlang/phobos/pull/3862 Note that the reverse of having a easy to use recursive const in library code of C++ is not true.
Aug 12 2016
prev sibling parent reply Vadim Lopatin <coolreader.org gmail.com> writes:
On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote:
 I'll give some highlights, but those are, mostly, things that 
 I've already listed in this forum and in my lightening talk.

 - No RAII support, despite the fact everybody here seems to 
 think that D supports RAII.
 Shachar
There IS RAII in D. I'm using it in DlangUI extensively for managing resources.
Aug 21 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 22/08/16 09:31, Vadim Lopatin wrote:
 On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote:
 I'll give some highlights, but those are, mostly, things that I've
 already listed in this forum and in my lightening talk.

 - No RAII support, despite the fact everybody here seems to think that
 D supports RAII.
 Shachar
There IS RAII in D. I'm using it in DlangUI extensively for managing resources.
Then, depending on your precise use, you might have leaks. Shachar
Aug 22 2016
parent Vadim Lopatin <coolreader.org gmail.com> writes:
On Monday, 22 August 2016 at 07:05:01 UTC, Shachar Shemesh wrote:
 On 22/08/16 09:31, Vadim Lopatin wrote:
 On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh
 - No RAII support, despite the fact everybody here seems to 
 think that
 D supports RAII.
 Shachar
There IS RAII in D. I'm using it in DlangUI extensively for managing resources.
Then, depending on your precise use, you might have leaks.
To avoid leaks, it's necessary to prevent destructor calling from GC for objects which hold resources - they have to be called manually via destroy() or by some RAII technique. I'm using Reference Counting.
Aug 22 2016
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:
 So, yes, having a CTFE to compute the table would have been 
 great, and had fakeroot-ng been written in D, I would have. 
 Then again, the ultimate cost of not doing this is so low, that 
 I didn't really feel cheated out of it.
I was just giving examples of things that aren't possible in C++, or are possible but less easy, require external programs, require incredible macros... If it's not easy it's as if it doesn't exist.
Aug 12 2016
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:
 That table was not expensive to compute, and its constantness 
 wasn't crucial enough even for me to put a wrapper pointer and 
 only access it through it. Had that not been the case, and had 
 that table been more expensive to computer, I'd probably 
 compute at compile time with an external tool.

 Shachar
And you are forgetting about composability. If I can compute a table at compile-time this means I can go higher on the abstraction ladder. void interpFast(string expr)(float x) { // here a look-up computed at compile-time static immutable table = makeTable!exp(0, 100, 0.1f); int ipart = cast(int)x; int fpart = x - ipart; return linInterp(table[ipart], table[ipart+1], fpart); } void main() { // automatically tabulated float x = interpFast!"pow(cos(x) + 4, x)"(0.5f); } Not only is this impossible in C++, but being cumbersome it means that people won't do it and loose optimization opportunities.
Aug 12 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2016 7:41 AM, Shachar Shemesh wrote:
 That table was not expensive to compute, and its constantness wasn't crucial
 enough even for me to put a wrapper pointer and only access it through it. Had
 that not been the case, and had that table been more expensive to computer, I'd
 probably compute at compile time with an external tool.
What I do (and is done in building DMD) is write a program (optabgen.c) to generate the tables and write a C++ source file, then compile the generated file into DMD.
Aug 12 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 12/08/16 22:07, Walter Bright wrote:
 On 8/12/2016 7:41 AM, Shachar Shemesh wrote:
 That table was not expensive to compute, and its constantness wasn't
 crucial
 enough even for me to put a wrapper pointer and only access it through
 it. Had
 that not been the case, and had that table been more expensive to
 computer, I'd
 probably compute at compile time with an external tool.
What I do (and is done in building DMD) is write a program (optabgen.c) to generate the tables and write a C++ source file, then compile the generated file into DMD.
Yes, I'm sorry. I meant to say "build time" instead of "compile time". That is precisely what I meant. Shachar
Aug 12 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2016 12:14 PM, Shachar Shemesh wrote:
 On 12/08/16 22:07, Walter Bright wrote:
 On 8/12/2016 7:41 AM, Shachar Shemesh wrote:
 That table was not expensive to compute, and its constantness wasn't
 crucial
 enough even for me to put a wrapper pointer and only access it through
 it. Had
 that not been the case, and had that table been more expensive to
 computer, I'd
 probably compute at compile time with an external tool.
What I do (and is done in building DMD) is write a program (optabgen.c) to generate the tables and write a C++ source file, then compile the generated file into DMD.
Yes, I'm sorry. I meant to say "build time" instead of "compile time". That is precisely what I meant.
I'm surprised that I've never seen anyone else use such a technique. It's so unusual I've seen it be unrepresentable in some 'make' replacements. I suppose it's like unittest and ddoc. Sure, you can do it with some contortions and/or some external tooling, but having it conveniently built in to the language changes everything.
Aug 12 2016
next sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 12/08/16 22:55, Walter Bright wrote:
 
 I'm surprised that I've never seen anyone else use such a technique.
 It's so unusual I've seen it be unrepresentable in some 'make'
 replacements.
 
 I suppose it's like unittest and ddoc. Sure, you can do it with some
 contortions and/or some external tooling, but having it conveniently
 built in to the language changes everything.
 
Actually, even with it being easilly accessible in the compiler, there are sometimes reasons to still do it with an external tool. My next task at work requires precomputing a table. This might prove to be a quite intensive task, and the result will change quite rarely. Under those circumstances, I believe I will not wish to compute it each time the system is compiled, but to compute it when it changes and use a cached version. This means I still need a build rule for it, which means that if the build system does not support it, sucks to be me. Shachar
Aug 12 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 04:06 PM, Shachar Shemesh wrote:
 On 12/08/16 22:55, Walter Bright wrote:
 I'm surprised that I've never seen anyone else use such a technique.
 It's so unusual I've seen it be unrepresentable in some 'make'
 replacements.

 I suppose it's like unittest and ddoc. Sure, you can do it with some
 contortions and/or some external tooling, but having it conveniently
 built in to the language changes everything.
Actually, even with it being easilly accessible in the compiler, there are sometimes reasons to still do it with an external tool. My next task at work requires precomputing a table. This might prove to be a quite intensive task, and the result will change quite rarely. Under those circumstances, I believe I will not wish to compute it each time the system is compiled, but to compute it when it changes and use a cached version.
I wonder if you can arrange things such that a compile-time table is computed only upon a change in the source file. I mean: // table.di extern double[] table; // table.d double[] table = makeComplicatedTable(); double[1024] makeComplicatedTable() { ... compile-time computation ... } People use the interface file table.di. The complicated computation goes in table.o which is generated only when table.d is changed. Andrei
Aug 12 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 03:55 PM, Walter Bright wrote:
 On 8/12/2016 12:14 PM, Shachar Shemesh wrote:
 On 12/08/16 22:07, Walter Bright wrote:
 On 8/12/2016 7:41 AM, Shachar Shemesh wrote:
 That table was not expensive to compute, and its constantness wasn't
 crucial
 enough even for me to put a wrapper pointer and only access it through
 it. Had
 that not been the case, and had that table been more expensive to
 computer, I'd
 probably compute at compile time with an external tool.
What I do (and is done in building DMD) is write a program (optabgen.c) to generate the tables and write a C++ source file, then compile the generated file into DMD.
Yes, I'm sorry. I meant to say "build time" instead of "compile time". That is precisely what I meant.
I'm surprised that I've never seen anyone else use such a technique.
It's a matter of frequenting the appropriate circles. The technique is in wide use. Andrei
Aug 12 2016
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote:
 I am a C++ expert who has looked at D in the past. Perhaps my 
 reasons for not programming in D may be taken as some of the 
 reasons why D "is not popular enough". My opinions are not 
 meant to start a flame war, even if some of my insights may be 
 harsh to those who do use D. They will hopefully give some idea 
 of why and where D went wrong in trying to appeal to the 
 general intelligent programmer as a programming language.

 1) Until very recently the documentation for D has been very 
 substandard. I do notice better documentation both on the web 
 site now and a few more books on D as a programming language. 
 For a very long time after D was created, even after version 2 
 was created, there was essentially no decent documentation at 
 all. If you are trying to promote the use of a computer 
 language to the general public you must create first-rate 
 documentation and explanation of your computer language from 
 the very beginning. Without this first-rate documentation your 
 programming language, no matter how good it might be, is just a 
 toy to those who want to play around with it and try it out. 
 This is the case that D promoted for a very long time, so the 
 expectation that D was going to become popular to the 
 programming public with such poor documentation was just 
 foolish. C took off as a programming language for the general 
 programming when Kernigan and Ritchie wrote their classic book 
 and C++ took off as a programming language for the general 
 public when Stroustrop and subsequently Lippman wrote their 
 classuc books. While I think that Alexandrescu's book is decent 
 it is not written at the level of these others.
I never got that point, really. When I started to program in D around 2010, documentation for D was almost non existent, but I quickly learned how to use it by just, well, using it. Programming languages have a lot of things in common, once you know one (or two) others are not so hard to learn/understand/use. If you come from a C++ background, understanding D should be a piece of cake.
 2) While I greatly respect the programming abilities of Mr. 
 Bright and Mr. Alexandrescu and their hard work in creating and 
 improving D, having followed both from the C++ world, the 
 arrogance by which D was initially and repeatedly compared 
 against C/C++ has been totally out of place since the 
 beginning. C++ is a very good language and the effort made to 
 denigrate it with specious and ridiculously false arguments 
 about it vis-a-vis D as a programming language has almost 
 irreparably hurt D as a serious programming language 
 irrespective of its actual abilities or weaknesses. You are not 
 going to appeal to the really intelligent programmers out there 
 if you are not honest and rigorous in discussion of your own 
 programming language in relation to others. All that you end up 
 doing is to alienate anyone with real programming intelligence 
 by the tactics that D has taken over the years with such 
 comparisons.
Cf. Patrick's comment. Let me add this: by constantly mentioning `intelligent programmers` you insinuate that people who use D are idiots who religiously worship the language. Anything but. The thing is that in D things are moving (and people in the community perceive it as something positive), which brings me to your next point.
 3) D has suffered greatly because it has had too many moving 
 targets as if constant change to something slightly better is 
 going to endear programmers to using a computer language. 
 Programmers need stability. The needed to know that if they are 
 using a programming language they are getting a particular 
 standard at a particular time with particular libraries that 
 work. They also need backward compatibility when things change. 
 D appears to have presented an almost constantly moving target 
 to this programmer, where adding/changing some feature is much 
 more important than fixing problems and providing stability.
True. I admit that I "fear" every new release in the sense that something will break and I'll have to fix it. More often than not, however, the fixes are trivial, and if they make sense and improve the language, I'm willing to pay the price. But your argument shows the fix D developers are in: to provide a better language without changing it (paradox). The trivial truth is that you can only improve a language by changing it and you need a community that is willing to go along with the changes. For this reason D hasn't taken off, because most people are not willing to risk (or cannot afford) frequent changes. Personally, I don't know which is worse, frequent (educated) changes or years of suboptimal coding until changes are made at long last (cf. Java). Mind you, well established languages like Java and C++ are now adopting things that have been around in D (and other languages) for a while, because those concepts have proven to be useful. This said, D has become a lot better in terms of deprecating things. You get a warning well in advance and you can prepare for the (breaking) changes. My perception (which might be biased) is that people look at D, bash it and trash it, but nevertheless take things on board when developing the next version of C++ or whatever - without giving credit later. The Led Zeppelin syndrome[1]. [1] https://www.youtube.com/watch?v=tiiY4ciKFQA
 4) As a C++ programmer largely interested in C++ template 
 programming, C++ concepts etc., and potential 
 compile-time/run-time introspection, I have never found a 
 compelling reason to use D rather than C++. I do recognize that 
 C++'s template syntax is difficult and abstruse but I do not 
 and have never seen where D improves upon these matters in any 
 serious and rigorous way. This may be because the documentation 
 about these areas in D is either very light or almost 
 completely lacking. Even in Mr. Alexandrescu's book the 
 discussion of these areas was very light in my estimation. So 
 whatever D has to offer in these areas, if there are really 
 impovements, is either lacking in the D documentation or does 
 not really exist for me.
I cannot comment on this, because I don't know what you've read, know or want to know about D.
 Edward Diener
Aug 12 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 11/08/16 18:41, Edward Diener wrote:
 2) While I greatly respect the programming abilities of Mr. Bright and
 Mr. Alexandrescu and their hard work in creating and improving D, having
 followed both from the C++ world, the arrogance by which D was initially
 and repeatedly compared against C/C++ has been totally out of place
 since the beginning. C++ is a very good language and the effort made to
 denigrate it with specious and ridiculously false arguments about it
 vis-a-vis D as a programming language has almost irreparably hurt D as a
 serious programming language irrespective of its actual abilities or
 weaknesses. You are not going to appeal to the really intelligent
 programmers out there if you are not honest and rigorous in discussion
 of your own programming language in relation to others. All that you end
 up doing is to alienate anyone with real programming intelligence by the
 tactics that D has taken over the years with such comparisons.
To me, this is not so much the question of alienating C++ programmers, as it is that this arrogance is actively hindering D from becoming better. Any time I raise an issue I have with D, the discussion with both AA and WB seems more like an argument designed to prove to me that I am wrong than like a discussion aimed to make D better. Once they decide that something is best a certain way, it is very very difficult to make them see the downsides of that decision, much less act on it. And, to me, this is an actual threat to D's future as a wide spread programming language. This attitude, if unchanged, will doom D to become a niche language, only suited for those who do not need it for anything that WB and AA have not thought of.
 4) As a C++ programmer largely interested in C++ template programming,
 C++ concepts etc., and potential compile-time/run-time introspection, I
 have never found a compelling reason to use D rather than C++. I do
 recognize that C++'s template syntax is difficult and abstruse but I do
 not and have never seen where D improves upon these matters in any
 serious and rigorous way. This may be because the documentation about
 these areas in D is either very light or almost completely lacking. Even
 in Mr. Alexandrescu's book the discussion of these areas was very light
 in my estimation. So whatever D has to offer in these areas, if there
 are really impovements, is either lacking in the D documentation or does
 not really exist for me.
Here I'm not sure I follow you. I love C++, but its compile time execution is just horrible. Yes, if you are fluent with functional programming you will probably get by sufficiently, but since C++ isn't itself a functional language, this means doing C++ meta-programming requires a different programming paradigm than programming C++. It is a very very very high barrier to pass. Personally, I'm not a fan of doing too much during compile time. I think it introduces a level of complexity into your program, where the program as seen by the CPU is considerably different than the one you see in your source editor, that is hard to track and debug. As such, the weakness of C++'s meta programming has not been a major setback for me. If you do like compile time programming, however, I don't see how you can claim that C++'s is good enough, when compared to D's. Shachar
Aug 12 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 10:51 AM, Shachar Shemesh wrote:
 To me, this is not so much the question of alienating C++ programmers,
 as it is that this arrogance is actively hindering D from becoming better.
I agree it would behoove us to be more humble. -- Andrei
Aug 12 2016
prev sibling next sibling parent Karabuta <karabutaworld gmail.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

 I'm 24 years old, my first lang was PHP and VBasic then C,C++ 
 and i first heard about D after 2005 when i was 14-15 years old.

 I always ignored D, i prejudiced that D failed, because nobody 
 were talking about it. I decided to check it yesterday, it has 
 excellent documentation, i almost covered all aspects. I think 
 D is much better than the most of the other popular langs. It's 
 clear as JScript, Swift, Julia and PHP, also it's capable 
 enough as C,C++. I think D deserves a bigger community.

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?
That guy who was very popular in your high school, you remember? How did he become so popular? D doesn't have much of what it takes to become popular that is why it is not :) Just ask yourself, why is JavaScript so popular? How about PHP?
Aug 14 2016
prev sibling next sibling parent reply Emre Temelkuran <etemelkuran gmail.com> writes:
It's easy to understand conservative programmers, you can even 
use C++ for web programming but it's waste of time and it won't 
give you the performance of Dropoid toolkit for Java. Also it's 
reliability is depends on your skills. Everyone leaving lower 
level languages other than the internet of things and game 
development industry. I noticed that, there was no significant 
progress on software industry for tens of years until higher 
level languages came out.
Aug 15 2016
parent Chris <wendlec tcd.ie> writes:
On Monday, 15 August 2016 at 13:10:01 UTC, Emre Temelkuran wrote:
 It's easy to understand conservative programmers, you can even 
 use C++ for web programming but it's waste of time and it won't 
 give you the performance of Dropoid toolkit for Java. Also it's 
 reliability is depends on your skills. Everyone leaving lower 
 level languages other than the internet of things and game 
 development industry. I noticed that, there was no significant 
 progress on software industry for tens of years until higher 
 level languages came out.
Do you know vibe.d? http://vibed.org/
Aug 15 2016
prev sibling parent reply Daniel <nobody nowhere.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 I always ignored D, i prejudiced that D failed, because nobody 
 were talking about it. I decided to check it yesterday, it has 
 excellent documentation, i almost covered all aspects. I think 
 D is much better than the most of the other popular langs. It's 
 clear as JScript, Swift, Julia and PHP, also it's capable 
 enough as C,C++. I think D deserves a bigger community.

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?
I lurk this forum every so often, since the time when there was this funny guy who ranted like a rude drunkard. At work I developed in dBase, Turbo Pascal, Delphi, Visual Basic, ASP, Java, C# and PHP, roughly in that temporal order, but most of my few hobby project and freelance work have been in Delphi, then Lazarus. D seems to have enhanced a lot, and I have even downloaded dlangide source once to try compiling and running it. I ran into some dub dependency problem and forgot about it. I guess, bundling the tools, ide and a couple good demos into an easily downloadable installation package (or package repo as in Debian) could be of some help. See for example: https://sourceforge.net/projects/lazarus/files/ http://www.oracle.com/technetwork/java/javase/downloads/jdk-netbeans-jsp-142931.html?ssSourceSiteId=otnes Hope this helps, Daniel
Aug 19 2016
parent Daniel <imnot thisguy.com> writes:
On Saturday, 20 August 2016 at 00:19:30 UTC, Daniel wrote:
 On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 Hope this helps,

 Daniel
BTW, I'm not the guy in that Gravatar image... ;-) Daniel
Aug 19 2016