Why D is not popular enough?
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?
Re: Why D is not popular enough?
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/tvrngtghzogqoeqvk...@forum.dlang.org https://forum.dlang.org/thread/erfyeseptuxjkpihq...@forum.dlang.org https://forum.dlang.org/thread/qaufzyhrngrjfkhob...@forum.dlang.org TL;DR There is no simple answer to your questions.
Re: Why D is not popular enough?
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 ;-)
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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).
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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 ;-)
Re: Why D is not popular enough?
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]
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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 :-)
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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 th
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
On Fri, 12 Aug 2016 08:59:14 +, 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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
On Fri, 12 Aug 2016 09:38:13 +, 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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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 :)
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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).
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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?
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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();
}
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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? - 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
Re: Why D is not popular enough?
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-improvement-opportunities. Is the talk video anywhere? https://youtu.be/yIH_0ew-maI?t=21m34s
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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?
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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/
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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/uxupejapglpeokaiq...@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/zxkkjezakirlfepnd...@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/hjaiavlfkoamenido...@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
Re: Why D is not popular enough?
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
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.
Re: Why D is not popular enough?
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 :(
Re: Why D is not popular enough?
Am Thu, 18 Aug 2016 22:50:27 + schrieb John Smith : > 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
Re: Why D is not popular enough?
Am Mon, 15 Aug 2016 10:54:11 -0700
schrieb Ali Çehreli :
> 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
>
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);
'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 = Parameters!((ref T) {});
Just remember that 'RefArg' is again a tuple and you
always need to access args[0] to use it.
--
Marco
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
Am Fri, 19 Aug 2016 13:36:05 + schrieb Adam D. Ruppe : > 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
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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.
Re: Why D is not popular enough?
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
Re: Why D is not popular enough?
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
