www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why D is not popular enough?

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

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

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

Why people need NodeJS, Typescript etc, when there is already 
better looking lang?
Everyone talking about how ugly is Golang. So why people are 
going on it? Performance concerns? Why languages that are not 
backed up by huge companies are looking like they failed?
Aug 01 2016
next sibling parent reply ciechowoj <keepitsimplesirius gmail.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:

 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

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

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

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?


There were similar threads recently.
https://forum.dlang.org/thread/tvrngtghzogqoeqvkovo forum.dlang.org
https://forum.dlang.org/thread/erfyeseptuxjkpihqcsg forum.dlang.org
https://forum.dlang.org/thread/qaufzyhrngrjfkhobcnk forum.dlang.org

TL;DR There is no simple answer to your questions.
Aug 01 2016
parent reply eugene <egordeev18 gmail.com> writes:
it would be ok if someone in the community would try to make 
things clear about old problems of D1 and the current state of 
D2, so to remove old(and maybe new) hype about the language
Aug 01 2016
parent reply Emre Temelkuran <etemelkuran gmail.com> writes:
On Monday, 1 August 2016 at 16:43:40 UTC, eugene wrote:

 it would be ok if someone in the community would try to make 
 things clear about old problems of D1 and the current state of 
 D2, so to remove old(and maybe new) hype about the language


All of you are right.

I just saw that on stats, Apple Swift 3 is fastest growing 
language ever and if you check what's behind, it's D.
Aug 01 2016
parent Guillaume Piolat <first.last gmail.com> writes:
On Monday, 1 August 2016 at 18:54:08 UTC, Emre Temelkuran wrote:

 I just saw that on stats, Apple Swift 3 is fastest growing 
 language ever and if you check what's behind, it's D.


Swift is the outlier here in the language landscape.

- pushed and marketed by Apple as an important lockin into their 
ecosystem  (why invest so much effort else?)
- replaces Objective-C which is not the most pleasant or sensical 
language
- explicitely targets newcomers to programming, in XCode a new 
Swift program is a "Playground"
- consultants don't want to be left behind and now sell Swift to 
clients

Swift could succeed whatever it does.
Aug 02 2016
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:

 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

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

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

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?



Dear Emre,

we have had such threads in the past and experience shows that 
there will be a huge non-productive debate about it. I think all 
the people here agree that "D deserves a bigger community", but 
everyone has a different view on how to achieve that.

My personal opinion is that we all can do a tiny contribution to 
make D more popular.
For example you should start actively promoting D at your 
university, workplace and among friends and maybe you can even 
start a local Meetup or developer group.
Of course, the online pedant is actively complaining on a 
discussion, site, ... if D is not listed or mentioned in a bad 
light.

If you have more time, doing great projects or libraries in D 
will help it's adaption too ;-)

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

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

What I was trying to say, we shouldn't waste time arguing about 
whether D is awesome, but make it even more awesome ;-)
Aug 01 2016
parent Chris <wendlec tcd.ie> writes:
On Monday, 1 August 2016 at 16:09:58 UTC, Seb wrote:

 On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:

 [...]



 Dear Emre,

 we have had such threads in the past and experience shows that 
 there will be a huge non-productive debate about it. I think 
 all the people here agree that "D deserves a bigger community", 
 but everyone has a different view on how to achieve that.

 My personal opinion is that we all can do a tiny contribution 
 to make D more popular.
 For example you should start actively promoting D at your 
 university, workplace and among friends and maybe you can even 
 start a local Meetup or developer group.
 Of course, the online pedant is actively complaining on a 
 discussion, site, ... if D is not listed or mentioned in a bad 
 light.


If D deserves criticism, don't complain (it's not a religion). 
But if the comparisons are unfair and / or half-truths are 
spread, then yes, one should complain and set the record straight.

Apart from that, I agree with you. Just use it and, if possible, 
improve it. The more the merrier :)


 If you have more time, doing great projects or libraries in D 
 will help it's adaption too ;-)

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

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

 What I was trying to say, we shouldn't waste time arguing about 
 whether D is awesome, but make it even more awesome ;-)
Aug 02 2016
prev sibling next sibling parent reply eugene <egordeev18 gmail.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:

 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

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

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

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?


i suppose it was simply because D v.1 failed and then authors 
created a new version of D (v.2) which is current, but the name 
"D" stayed the same, so, people remember some drawbacks of D v.1 
and think that D v.2 has the same drawbacks, maybe without even 
trying D v.2
Aug 01 2016
parent reply yuioyyoi <yuioyyoi yuioyyoi.se> writes:
On Monday, 1 August 2016 at 16:16:03 UTC, eugene wrote:

 On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 i suppose it was simply because D v.1 failed and then authors 
 created a new version of D (v.2) which is current, but the name 
 "D" stayed the same, so, people remember some drawbacks of D 
 v.1 and think that D v.2 has the same drawbacks, maybe without 
 even trying D v.2


Also before it was closed source and the whole infrastructure 
(repository, testing , bug report) was shitty. Bright admited 
himself that going to GH and using bugzilla was salvatory. So 
even if it existed before, you can consider early 2010's as a 
second birth. (there's a non technical conference posted earlyer 
this year where he talked about this).
Aug 01 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 1 August 2016 at 16:25:52 UTC, yuioyyoi wrote:

 Also before it was closed source


D was never closed source. It used to be only the D parts were 
open, distributed under the artistic license in the very early 
days and you couldn't build the whole thing, but it has always 
been there.
Aug 01 2016
prev sibling parent eugene <egordeev18 gmail.com> writes:
On Monday, 1 August 2016 at 16:25:52 UTC, yuioyyoi wrote:

 On Monday, 1 August 2016 at 16:16:03 UTC, eugene wrote:

 On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran 
 wrote:
 i suppose it was simply because D v.1 failed and then authors 
 created a new version of D (v.2) which is current, but the 
 name "D" stayed the same, so, people remember some drawbacks 
 of D v.1 and think that D v.2 has the same drawbacks, maybe 
 without even trying D v.2


 Also before it was closed source and the whole infrastructure 
 (repository, testing , bug report) was shitty. Bright admited 
 himself that going to GH and using bugzilla was salvatory. So 
 even if it existed before, you can consider early 2010's as a 
 second birth. (there's a non technical conference posted 
 earlyer this year where he talked about this).


since that time (2010) even some student guys released exokernel 
O.S. written in D v.2 about 4 years ago (~2013): 
https://github.com/xomboverlord/xomb
i don't know if it is practical, but still nice try
Aug 01 2016
prev sibling next sibling parent reply eugene <egordeev18 gmail.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:

 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

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

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

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?


maybe another reason is that people who tried to use D still 
think it is unstable
Aug 01 2016
parent reply Charles Hixson via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 08/01/2016 09:37 AM, eugene via Digitalmars-d wrote:

 On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:

 For years, i was travelling along Golang, Rust, Perl, Ruby, Python, 
 PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many more 
 that i can't remember.

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

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

 Why people need NodeJS, Typescript etc, when there is already better 
 looking lang?
 Everyone talking about how ugly is Golang. So why people are going on 
 it? Performance concerns? Why languages that are not backed up by 
 huge companies are looking like they failed?


 maybe another reason is that people who tried to use D still think it 
 is unstable


I have never experienced D as being unstable.  I have, however, 
experienced problems using various libraries with D.  Whenever you need 
to use a foreign library you invite problems, but D wrappers around 
libraries have a habit of showing up and then not being maintained.  
THAT has caused me problems...enough problems that if I don't need the 
performance I'll pick Python.

As for D1 being a failure...that depends on what you wanted to do with 
it.  Until it started being influenced by Tango I was quite pleased, and 
even Tango wasn't all bad.  It had a few good unicode tools that haven't 
yet been incorporated into D2.  D2 I'm less satisfied with, though that 
may just be a rosy-glasses memory of D1.  Most of my needs aren't fancy 
compile time techniques but rather run-time techniques.  (I did mention 
Python as the alternate rather than C++.)  But what the best language is 
depends a lot on what you are doing.  To talk in terms of other 
languages, Objective C is a better language for my needs than C++.  It 
isn't really because of the commitment to 16-bit unicode, but outside of 
that... So in either version of D I have mixed uses of 8-bit unicode and 
32-bit unicode.  D seems to handle this better than any other language.  
And it's got lots of other nice features.  I love garbage collection, as 
I hate memory management.  I'm less attracted to ranges as implemented 
by D, though I like them in Ruby and Python. A lot of this has to do 
with what gets done at compile time and what gets done at run time, 
though, so for me that just means that I'd rather avoid needing to use 
ranges when I need speed.  For my purposes the template language is 
overblown, and I'd be satisfied with a much simpler form with some 
run-time supplementation...but different people would like different 
simplifications even among those who want it to be simpler.  Traits, 
e.g., I find indispensable (especially isPOD) and I need to be able to 
test THAT at compile time, but most people who talk about templates 
don't even mention traits.

Many languages become significant when there is an popular application 
or library that depends on them.  Others grow slowly. There *is*, 
however, a network effect, so that popular languages tend to become more 
popular, and this is often driven by a "niche" application (a place 
where there is no competition, so everyone who wants to work in that 
niche must use that language).  An example of this, if you go back to 
before it was popular, is JavaScript.
Aug 01 2016
parent Chris <wendlec tcd.ie> writes:
On Monday, 1 August 2016 at 18:21:05 UTC, Charles Hixson wrote:


 [...]


 I have never experienced D as being unstable.  I have, however, 
 experienced problems using various libraries with D.  Whenever 
 you need to use a foreign library you invite problems, but D 
 wrappers around libraries have a habit of showing up and then 
 not being maintained.  THAT has caused me problems...enough 
 problems that if I don't need the performance I'll pick Python.

 [...]


However, the good thing about D is that you don't need to use all 
the idioms, if you really don't want to. You can write simple 
C-like code with loops. You don't need to have hundreds of 
template constraints, if you don't want/need to. To get started 
with D you don't need to be able to master template constraints, 
CTFE and ranges from day one. This knowledge will come naturally 
as you go along, but it's not a conditio sine qua non.

[snip]
Aug 02 2016
prev sibling next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:

 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

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

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

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?


I can't speak for everyone, but for my purposes, D isn't ready 
for use, because it lacks ios/android support. AFAIK, ios support 
is coming along nicely, but still isn't production ready, and 
isn't merged into LDC. I think D does a lot of things very well, 
but seems to be suffering from lack of manpower at the moment, 
which results in large holes like lack of mobile platform 
support, and unfinished features. The 'scope' keyword, for 
example, is legal in D syntax, but doesn't actually do anything. 
While this problem may be practically benign, its a huge red 
flag, which can be very off-putting to newcomers. I could only 
speculate as to why exactly D isn't more popular. When I look at 
things like D's CTFE, C++ interop, templates, and reflection, my 
honest reaction is..Holy shit, this is awesome...why isn't this 
language more popular ?_?

Maybe it just needs more time.
Aug 01 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 1 August 2016 at 19:33:48 UTC, bitwise wrote:

 'scope' keyword, for example, is legal in D syntax, but doesn't 
 actually do anything.


sorry, but you are wrong here. of course, it does HAVE effect.

   `void foo (scope delegate () boo)`

this means that compiler should not allocate a closure for 
delegate, as `foo` is promising that it will not store `boo` 
anywhere.

   `scope a = new A();`

this does what you think it does, althru it is deprecated in 
favor of `scoped!` template.
Aug 02 2016
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Tuesday, 2 August 2016 at 07:50:29 UTC, ketmar wrote:

 On Monday, 1 August 2016 at 19:33:48 UTC, bitwise wrote:

 'scope' keyword, for example, is legal in D syntax, but 
 doesn't actually do anything.


 sorry, but you are wrong here. of course, it does HAVE effect.

   `void foo (scope delegate () boo)`

 this means that compiler should not allocate a closure for 
 delegate, as `foo` is promising that it will not store `boo` 
 anywhere.

   `scope a = new A();`

 this does what you think it does, althru it is deprecated in 
 favor of `scoped!` template.


I know about these cases, but didn't bother mentioning them, as 
they are outliers. Also, they do not make my point any less valid.

The following code compiles without errors(outputs 1):

class Foo{
	int val;
	this(){ val = 1; }
}
Foo x;
void bar(scope Foo foo) {
	x = foo;
}
void main() {
     bar(new Foo());
     writeln(x.val);
}


'scope' is clearly not functioning as advertised, as is the case 
for many aspects of D. Again, users shouldn't have to deal with 
this sort of thing. I doubt that anyone outside of would-be D 
contributors will continue to use the language beyond the point 
where they find a hole like this.

     Bit
Aug 03 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 3 August 2016 at 19:57:13 UTC, bitwise wrote:

 On Tuesday, 2 August 2016 at 07:50:29 UTC, ketmar wrote:

 On Monday, 1 August 2016 at 19:33:48 UTC, bitwise wrote:

 'scope' keyword, for example, is legal in D syntax, but 
 doesn't actually do anything.


 sorry, but you are wrong here. of course, it does HAVE effect.


 I know about these cases, but didn't bother mentioning them, as 
 they are outliers. Also, they do not make my point any less 
 valid.


it does. actually, it makes your point completely false.
Aug 03 2016
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Wednesday, 3 August 2016 at 21:19:21 UTC, ketmar wrote:

 On Wednesday, 3 August 2016 at 19:57:13 UTC, bitwise wrote:

 On Tuesday, 2 August 2016 at 07:50:29 UTC, ketmar wrote:

 On Monday, 1 August 2016 at 19:33:48 UTC, bitwise wrote:

 'scope' keyword, for example, is legal in D syntax, but 
 doesn't actually do anything.


 sorry, but you are wrong here. of course, it does HAVE effect.


 I know about these cases, but didn't bother mentioning them, 
 as they are outliers. Also, they do not make my point any less 
 valid.


 it does. actually, it makes your point completely false.


Nice troll.
Aug 03 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 4 August 2016 at 00:57:13 UTC, bitwise wrote:

 On Wednesday, 3 August 2016 at 21:19:21 UTC, ketmar wrote:

 On Wednesday, 3 August 2016 at 19:57:13 UTC, bitwise wrote:

 On Tuesday, 2 August 2016 at 07:50:29 UTC, ketmar wrote:

 On Monday, 1 August 2016 at 19:33:48 UTC, bitwise wrote:

 'scope' keyword, for example, is legal in D syntax, but 
 doesn't actually do anything.


 sorry, but you are wrong here. of course, it does HAVE 
 effect.


 I know about these cases, but didn't bother mentioning them, 
 as they are outliers. Also, they do not make my point any 
 less valid.


 it does. actually, it makes your point completely false.


 Nice troll.


not at all.
"a is false."
"but a is true!"
"ah, nevermind, continue execution."

one invalid point makes the whole technical argument false. it is 
natural to dismiss it completely: author may wanted to do a good 
thing, but he didn't bother to check his statements, so the whole 
thing becomes invalid. instead of trying to dissect the thing 
(and risking to hit author's response like "you took only part of 
my statement instead of taking the whole picture!"), the whole 
thing should be rejected. author can come with fixed patch^w 
statement later, of course.
Aug 04 2016
prev sibling next sibling parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
On 8/1/2016 11:31 AM, Emre Temelkuran wrote:

 For years, i was travelling along Golang, Rust, Perl, Ruby, Python, PHP,
 JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many more that
 i can't remember.

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

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

 Why people need NodeJS, Typescript etc, when there is already better
 looking lang?
 Everyone talking about how ugly is Golang. So why people are going on
 it? Performance concerns? Why languages that are not backed up by huge
 companies are looking like they failed?


I am a C++ expert who has looked at D in the past. Perhaps my reasons 
for not programming in D may be taken as some of the reasons why D "is 
not popular enough". My opinions are not meant to start a flame war, 
even if some of my insights may be harsh to those who do use D. They 
will hopefully give some idea of why and where D went wrong in trying to 
appeal to the general intelligent programmer as a programming language.

1) Until very recently the documentation for D has been very 
substandard. I do notice better documentation both on the web site now 
and a few more books on D as a programming language. For a very long 
time after D was created, even after version 2 was created, there was 
essentially no decent documentation at all. If you are trying to promote 
the use of a computer language to the general public you must create 
first-rate documentation and explanation of your computer language from 
the very beginning. Without this first-rate documentation your 
programming language, no matter how good it might be, is just a toy to 
those who want to play around with it and try it out. This is the case 
that D promoted for a very long time, so the expectation that D was 
going to become popular to the programming public with such poor 
documentation was just foolish. C took off as a programming language for 
the general programming when Kernigan and Ritchie wrote their classic 
book and C++ took off as a programming language for the general public 
when Stroustrop and subsequently Lippman wrote their classuc books. 
While I think that Alexandrescu's book is decent it is not written at 
the level of these others.

2) While I greatly respect the programming abilities of Mr. Bright and 
Mr. Alexandrescu and their hard work in creating and improving D, having 
followed both from the C++ world, the arrogance by which D was initially 
and repeatedly compared against C/C++ has been totally out of place 
since the beginning. C++ is a very good language and the effort made to 
denigrate it with specious and ridiculously false arguments about it 
vis-a-vis D as a programming language has almost irreparably hurt D as a 
serious programming language irrespective of its actual abilities or 
weaknesses. You are not going to appeal to the really intelligent 
programmers out there if you are not honest and rigorous in discussion 
of your own programming language in relation to others. All that you end 
up doing is to alienate anyone with real programming intelligence by the 
tactics that D has taken over the years with such comparisons.

3) D has suffered greatly because it has had too many moving targets as 
if constant change to something slightly better is going to endear 
programmers to using a computer language. Programmers need stability. 
The needed to know that if they are using a programming language they 
are getting a particular standard at a particular time with particular 
libraries that work. They also need backward compatibility when things 
change. D appears to have presented an almost constantly moving target 
to this programmer, where adding/changing some feature is much more 
important than fixing problems and providing stability.

4) As a C++ programmer largely interested in C++ template programming, 
C++ concepts etc., and potential compile-time/run-time introspection, I 
have never found a compelling reason to use D rather than C++. I do 
recognize that C++'s template syntax is difficult and abstruse but I do 
not and have never seen where D improves upon these matters in any 
serious and rigorous way. This may be because the documentation about 
these areas in D is either very light or almost completely lacking. Even 
in Mr. Alexandrescu's book the discussion of these areas was very light 
in my estimation. So whatever D has to offer in these areas, if there 
are really impovements, is either lacking in the D documentation or does 
not really exist for me.

Edward Diener
Aug 11 2016
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote:

 the arrogance by which D was initially and repeatedly compared 
 against C/C++ has been totally out of place since the C++ is a 
 very good language and the effort made to denigrate it with 
 specious and ridiculously false arguments about it vis-a-vis D 
 as a programming language has almost irreparably hurt D as a 
 serious programming language irrespective of its actual 
 abilities or weaknesses. You are not going to appeal to the 
 really intelligent programmers out there if you are not honest 
 and rigorous in discussion of your own programming language in 
 relation to others. All that you end up doing is to alienate 
 anyone with real programming intelligence by the tactics that D 
 has taken over the years with such comparisons.



 4) As a C++ programmer largely interested in C++ template 
 programming, C++ concepts etc., and potential 
 compile-time/run-time introspection, I have never found a 
 compelling reason to use D rather than C++.


This is a good example of why C++ programmers will never move to 
D. They are quite happy with the language. They want a better 
C++, and that's C++14, C++17, etc., not D.
Aug 11 2016
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 11 August 2016 at 20:16:04 UTC, bachmeier wrote:

 On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener 
 wrote:

 the arrogance by which D was initially and repeatedly compared 
 against C/C++ has been totally out of place since the C++ is a 
 very good language and the effort made to denigrate it with 
 specious and ridiculously false arguments about it vis-a-vis D 
 as a programming language has almost irreparably hurt D as a 
 serious programming language irrespective of its actual 
 abilities or weaknesses. You are not going to appeal to the 
 really intelligent programmers out there if you are not honest 
 and rigorous in discussion of your own programming language in 
 relation to others. All that you end up doing is to alienate 
 anyone with real programming intelligence by the tactics that 
 D has taken over the years with such comparisons.




I never understood how people can get their feelings hurt when 
criticising the language they program in. Either the criticised 
point is true and one accepts it or not, in that case a factual 
refutation can be done. Feeling offended is ridiculous.


 4) As a C++ programmer largely interested in C++ template 
 programming, C++ concepts etc., and potential 
 compile-time/run-time introspection, I have never found a 
 compelling reason to use D rather than C++.


 This is a good example of why C++ programmers will never move 
 to D. They are quite happy with the language. They want a 
 better C++, and that's C++14, C++17, etc., not D.


Yeah, it's also known as Stockholm Syndrome :-)
Aug 12 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/12/16 4:59 AM, Patrick Schluter wrote:

 On Thursday, 11 August 2016 at 20:16:04 UTC, bachmeier wrote:

 On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote:

 the arrogance by which D was initially and repeatedly compared
 against C/C++ has been totally out of place since the C++ is a very
 good language and the effort made to denigrate it with specious and
 ridiculously false arguments about it vis-a-vis D as a programming
 language has almost irreparably hurt D as a serious programming
 language irrespective of its actual abilities or weaknesses. You are
 not going to appeal to the really intelligent programmers out there
 if you are not honest and rigorous in discussion of your own
 programming language in relation to others. All that you end up doing
 is to alienate anyone with real programming intelligence by the
 tactics that D has taken over the years with such comparisons.




 I never understood how people can get their feelings hurt when
 criticising the language they program in. Either the criticised point is
 true and one accepts it or not, in that case a factual refutation can be
 done. Feeling offended is ridiculous.


I recall I had a similar reaction as Edward back in the day. No hurt 
feelings or anything, but the arguments made were so specious I'd roll 
my eyes whenever I saw them in the C++ forums. -- Andrei
Aug 12 2016
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu 
wrote:

 I recall I had a similar reaction as Edward back in the day. No 
 hurt feelings or anything, but the arguments made were so 
 specious I'd roll my eyes whenever I saw them in the C++ 
 forums. -- Andrei


I already roll my eyes at these threads and I've only been using 
D for like a year or two. I'm amazed you still have eyes at this 
point.
Aug 12 2016
prev sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu 
wrote:

 I recall I had a similar reaction as Edward back in the day. No 
 hurt feelings or anything, but the arguments made were so 
 specious I'd roll my eyes whenever I saw them in the C++ 
 forums. -- Andrei


So what changed?  What gave you the initial kick to start moving 
from sideline scoffer to benevolent diarch?

-Wyatt
Aug 12 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 12:31 PM, Wyatt wrote:

 On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu wrote:

 I recall I had a similar reaction as Edward back in the day. No hurt
 feelings or anything, but the arguments made were so specious I'd roll
 my eyes whenever I saw them in the C++ forums. -- Andrei


 So what changed?  What gave you the initial kick to start moving from
 sideline scoffer to benevolent diarch?


Walter and I talked and he said he'd be interested in working together 
on the kind of things I was interested in: generic programming, static 
introspection, and such. -- Andrei
Aug 12 2016
prev sibling next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Fri, 12 Aug 2016 08:59:14 +0000, Patrick Schluter wrote:

 I never understood how people can get their feelings hurt when
 criticising the language they program in.
 
 Yeah, it's also known as Stockholm Syndrome :-)


Because you specifically are criticizing the person directly, not the 
language they use, now.
Aug 12 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 12 August 2016 at 08:59:14 UTC, Patrick Schluter wrote:

 I never understood how people can get their feelings hurt when 
 criticising the language they program in. Either the criticised 
 point is true and one accepts it or not, in that case a factual 
 refutation can be done. Feeling offended is ridiculous.


http://www.independent.co.uk/arts-entertainment/tv/news/millennials-outraged-over-tv-show-portraying-millennials-as-outraged-a7184771.html
Aug 13 2016
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote:

 4) As a C++ programmer largely interested in C++ template 
 programming, C++ concepts etc., and potential 
 compile-time/run-time introspection, I have never found a 
 compelling reason to use D rather than C++. I do recognize that 
 C++'s template syntax is difficult and abstruse but I do not 
 and have never seen where D improves upon these matters in any 
 serious and rigorous way. This may be because the documentation 
 about these areas in D is either very light or almost 
 completely lacking. Even in Mr. Alexandrescu's book the 
 discussion of these areas was very light in my estimation. So 
 whatever D has to offer in these areas, if there are really 
 impovements, is either lacking in the D documentation or does 
 not really exist for me.


 From the best of my knowledge you cannot do these things in in 
C++:

https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE
https://p0nce.github.io/d-idioms/#Enumerate-fields-with-__traits(allMembers)-and-static-foreach
https://p0nce.github.io/d-idioms/#Embed-a-dynamic-library-in-an-executable
https://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching
https://p0nce.github.io/d-idioms/#String-interpolation-as-a-library
https://p0nce.github.io/d-idioms/#Using-std.typecons.Flag-like-a-pro
https://p0nce.github.io/d-idioms/#Voldemort-types

Another expose of what you can achieve with these feature is the 
"D Cookbook" book.

- Chapter 6 Forwarding methods with opDispatch
- Chapter 8 Getting a list of child classes
- Chapter 8 Determining if a module is available
- Chapter 8 Using user defined attributes
- Chapter 9 Creating user-defined literals
- Chapter 9 Generating data structure from text diagrams


Finally what we label "DbI" is quite the game changer: 
https://p0nce.github.io/d-idioms/#Design-by-Introspection
Aug 12 2016
next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 12 August 2016 at 09:38:13 UTC, Guillaume Piolat wrote:

 From the best of my knowledge you cannot do these things in in 
 C++:


The most important thing is what you can't do in D: read a Scott 
Meyers book.
Aug 12 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/12/16 10:19 AM, bachmeier wrote:

 On Friday, 12 August 2016 at 09:38:13 UTC, Guillaume Piolat wrote:

 From the best of my knowledge you cannot do these things in in C++:


 The most important thing is what you can't do in D: read a Scott Meyers
 book.


That's the last thing D needs.

-Steve
Aug 12 2016
parent reply Kagamin <spam here.lot> writes:
On Friday, 12 August 2016 at 14:24:06 UTC, Steven Schveighoffer 
wrote:

 On 8/12/16 10:19 AM, bachmeier wrote:

 On Friday, 12 August 2016 at 09:38:13 UTC, Guillaume Piolat 
 wrote:

 From the best of my knowledge you cannot do these things in 
 in C++:


 The most important thing is what you can't do in D: read a 
 Scott Meyers
 book.


 That's the last thing D needs.

 -Steve


Though people could enjoy an article explaining how shared works 
:)
Aug 12 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/12/16 11:28 AM, Kagamin wrote:

 Though people could enjoy an article explaining how shared works :)


First you have to find someone who knows how it works :)

All kidding aside, shared is pretty broken currently. If you want to 
know how it was *supposed* to work, you can read TDPL, though I'm not 
sure that's still valid.

-Steve
Aug 12 2016
parent reply Kagamin <spam here.lot> writes:
On Friday, 12 August 2016 at 15:43:54 UTC, Steven Schveighoffer 
wrote:

 All kidding aside, shared is pretty broken currently. If you 
 want to know how it was *supposed* to work, you can read TDPL, 
 though I'm not sure that's still valid.


Ah, was it Andrei, who tried to sell the idea that shared is a 
silver bullet for concurrency problems? That can explain why we 
have two different views on shared. Looks like a repetition of 
the story with autodecoding (with similar rationale).
Aug 12 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, August 12, 2016 16:38:23 Kagamin via Digitalmars-d wrote:

 On Friday, 12 August 2016 at 15:43:54 UTC, Steven Schveighoffer

 wrote:

 All kidding aside, shared is pretty broken currently. If you
 want to know how it was *supposed* to work, you can read TDPL,
 though I'm not sure that's still valid.


 Ah, was it Andrei, who tried to sell the idea that shared is a
 silver bullet for concurrency problems? That can explain why we
 have two different views on shared. Looks like a repetition of
 the story with autodecoding (with similar rationale).


Honestly, I don't think that shared is broken. It's just that once you've
locked the appropriate mutex, you have to cast a way shared and make sure
that no thread-local references to that data are still around when you
release the lock. shared is doing its job of indicating when a variable
isn't thread-local as well as preventing a number of incorrect operations on
data that's shared across threads without being protected by a lock. What
we're missing is a way safely have shared cast away for us so that we don't
have to do the work of verifying that we're not screwing it up. synchronized
classes as described in TDPL partially solve the problem in that they
provide a safe, automatic way to remove one layer of shared - but it's only
one layer, and it's never been implemented. It's the equivalent of having a
set of operations that we'd like to be  safe but are stuck as  system, and
we're forced to use  trusted to deal with it.

But folks get annoyed with shared, because they have to cast it away at the
appropriate time. They just want it to magically work in a safe manner, and
we simply haven't figured out how to do that. Instead, we have a way to
segregate shared stuff and thus minimize how much code has to deal with the
problems that come with sharing data across threads but which requires that
you handle it carefully rather than having a way to just handle it safely,
automatically.

shared isn't perfect, but having thread-local by default is dowright
fantastic, and when you have to deal with shared, you mostly doing the same
sorts of things that you're supposed to be doing in C++. It's just that you
have to cast away shared to operate on the object while the mutex is locked.

IMHO, the biggest problem with shared is that the related types in druntime
(like the mutexes and condition variables) aren't marked with it properly
rather than shared itself being fundamentally flawed.

- Jonathan M Davis
Aug 12 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 Honestly, I don't think that shared is broken.


Yes. It is broken.

shared int x;
++x; // error, must use atomicOp.
x = x + 1; // OK(!)

The thing that is NOT broken is unshared.

There's literally not much you can do with shared, and what you can do 
isn't consistent or useful.

It needs lots of attention.

-Steve
Aug 12 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:

 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 Honestly, I don't think that shared is broken.


 Yes. It is broken.

 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)


How is this broken and how should it behave? -- Andrei
Aug 12 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:

 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 
 Honestly, I don't think that shared is broken.


 
 Yes. It is broken.
 
 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)


 
 How is this broken and how should it behave? -- Andrei


?!

Isn't it obvious that assigning to a shared int must require atomicOp or
a cast? `x = x + 1;` clearly has a race condition otherwise.


T

-- 
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not yet
been conceived. -- Michael B. Allen
Aug 12 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 02:01 PM, H. S. Teoh via Digitalmars-d wrote:

 On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:

 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:

 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 Honestly, I don't think that shared is broken.


 Yes. It is broken.

 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)


 How is this broken and how should it behave? -- Andrei


 ?!

 Isn't it obvious that assigning to a shared int must require atomicOp or
 a cast? `x = x + 1;` clearly has a race condition otherwise.


It is not to me, and it does not seem like a low-level race condition to 
me (whereas ++x is).

Currently the compiler must ensure that an atomic read and an atomic 
write are generated for x. Other than that, it is the responsibility of 
the user. The use of "shared" does not automatically relieve the user 
from certain responsibilities.

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

x = *p + 1;

How would the compiler reject the right uses but not the case when p == &x?


Andrei
Aug 12 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Aug 12, 2016 at 02:21:04PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 08/12/2016 02:01 PM, H. S. Teoh via Digitalmars-d wrote:

 On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:

 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:

 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 
 Honestly, I don't think that shared is broken.


 
 Yes. It is broken.
 
 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)


 
 How is this broken and how should it behave? -- Andrei


 
 ?!
 
 Isn't it obvious that assigning to a shared int must require
 atomicOp or a cast? `x = x + 1;` clearly has a race condition
 otherwise.


 
 It is not to me, and it does not seem like a low-level race condition
 to me (whereas ++x is).


The problem is that the line between "low-level" and "high-level" is
unclear and arbitrary. Doesn't ++x lower to x = x + 1 on some CPUs
anyway (or vice versa, if the optimizer decides to translate it the
other way)? Why should the user have to worry about such details?
Wouldn't that make shared kinda useless to begin with?



 Currently the compiler must ensure that an atomic read and an atomic
 write are generated for x. Other than that, it is the responsibility
 of the user.  The use of "shared" does not automatically relieve the
 user from certain responsibilities.

 I agree that it would be nice to have stronger protection against
 higher-level bugs, but those are outside the charter of "shared".
 Consider:
 
 x = *p + 1;
 
 How would the compiler reject the right uses but not the case when p
 == &x?


[...]

The compiler should reject it (without the appropriate casts) if p has a
shared type, and the aliasing situation with x is unknown / unclear. The
programmer ought to explicitly state the assumption that x isn't aliased
by p by specifying a cast (or equivalent), rather than be able to write
such code, possibly not being aware of the implications, and have it
compile without any warning.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor
first.
Aug 12 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 02:29 PM, H. S. Teoh via Digitalmars-d wrote:

 On Fri, Aug 12, 2016 at 02:21:04PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:

 On 08/12/2016 02:01 PM, H. S. Teoh via Digitalmars-d wrote:

 On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:

 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:

 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 Honestly, I don't think that shared is broken.


 Yes. It is broken.

 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)


 How is this broken and how should it behave? -- Andrei


 ?!

 Isn't it obvious that assigning to a shared int must require
 atomicOp or a cast? `x = x + 1;` clearly has a race condition
 otherwise.


 It is not to me, and it does not seem like a low-level race condition
 to me (whereas ++x is).


 The problem is that the line between "low-level" and "high-level" is
 unclear and arbitrary.


I'd need to think a bit before agreeing or disagreeing, but it's a 
plausible take. In this case fortunately, the matters can be distinguished.


 Doesn't ++x lower to x = x + 1 on some CPUs
 anyway (or vice versa, if the optimizer decides to translate it the
 other way)?


This doesn't matter. The question is what is explicit and what is 
implicit in the computation.

++expr

is a RMW ("read-modify-write") expression, equivalent to:

((ref x) => { return x = cast(typeof(x)) (x + 1); })(expr)

In contrast,

expr1 = expr2 + 1

is an expression consisting of distinct read and write, both under the 
control of the code written by the programmer. As I explained, 
distinguishing in the general case when expr1 and expr2 refer to the 
same memory location is not doable statically. So it stands to reason 
that the compiler generates the code for one read and one write because 
that is literally what it has been asked to do.

It may actually be the case that one wants to do x = x + 1 and exercise 
a benign high-level race.


 Why should the user have to worry about such details?


What details are you referring to, and how would compiler technology 
help with those?


 Wouldn't that make shared kinda useless to begin with?


It doesn't seem that way.


 Currently the compiler must ensure that an atomic read and an atomic
 write are generated for x. Other than that, it is the responsibility
 of the user.  The use of "shared" does not automatically relieve the
 user from certain responsibilities.

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

 x = *p + 1;

 How would the compiler reject the right uses but not the case when p
 == &x?


 [...]

 The compiler should reject it (without the appropriate casts) if p has a
 shared type, and the aliasing situation with x is unknown / unclear.


I think you are not right here.



Andrei
Aug 12 2016
prev sibling parent ag0aep6g <anonymous example.com> writes:
On 08/12/2016 08:21 PM, Andrei Alexandrescu wrote:

 Currently the compiler must ensure that an atomic read and an atomic
 write are generated for x.


Would be nice if that could be added to the spec. It's awfully quiet 
about shared right now.
Aug 13 2016
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 08/12/2016 08:04 PM, Andrei Alexandrescu wrote:

 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:


[...]

 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)


 How is this broken and how should it behave? -- Andrei


I may be responsible for some confusion here, including my own.

Disclaimer: I'm far from being an expert on thread-safety. I may have 
misunderstandings about fundamentals.

Recently, I made a thread titled "implicit conversions to/from shared":
http://forum.dlang.org/post/nlth0p$1l7g$1 digitalmars.com

Before starting that thread, and before messing with atomicOp, I had 
assumed that D enforces atomic reads/writes on shared types. Then I 
noticed that I can read/write shared types that are too large for atomic 
ops.

Example:

----
alias T = ubyte[1000];

enum T a = 1;
enum T b = 2;

shared T x = a;

import core.thread: Thread;

void write()
{
     bool flip = false;
     foreach (i; 0 .. 1_000_000)
     {
         if (flip) x = a; else x = b; // non-atomic write
         flip = !flip;
     }
}

void main()
{
     auto t = new Thread(&write);
     t.start();
     foreach (i; 0 .. 1_000_000)
     {
         T r = x; // non-atomic read
         assert(r == a || r == b); // fails
     }
     t.join();
}
----

I tested a bunch of stuff, and I remember having a test case that failed 
with a primitive type like int, but I can't find or recreate it now, and 
a little googling suggests that reading/writing should be atomic for 
primitive types (on X86 with various restrictions). So I probably just 
had an error in that test.

But the above test case stands, and it also fails with -m32 and ulong:

----
alias T = ulong;

enum T a = 0x01_01_01_01__01_01_01_01;
enum T b = 0x02_02_02_02__02_02_02_02;

/* rest as above */
----

So, `shared int x; x = x + 1;` is ok, as far as I see now. But with 
other types, unsafe reads/writes are generated.
Aug 12 2016
parent ag0aep6g <anonymous example.com> writes:
On 08/12/2016 09:41 PM, ag0aep6g wrote:

 So, `shared int x; x = x + 1;` is ok, as far as I see now. But with
 other types, unsafe reads/writes are generated.


Missing alignment can also throw the compiler off:

----
alias T = int;

enum T a = 0x01_01_01_01;
enum T b = 0x02_02_02_02;

struct S
{
     byte[13] padding;
     align(1) T x = a;
}

shared S s;

import core.thread: Thread;

void write()
{
     bool flip = false;
     foreach (i; 0 .. 1_000_000)
     {
         if (flip) s.x = a; else s.x = b;
         flip = !flip;
     }
}

void main()
{
     auto t = new Thread(&write);
     t.start();
     foreach (i; 0 .. 1_000_000)
     {
         T r = s.x;
         assert(r == a || r == b); // fails
     }
     t.join();
}
----
Aug 12 2016
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/12/16 2:04 PM, Andrei Alexandrescu wrote:

 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:

 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 Honestly, I don't think that shared is broken.


 Yes. It is broken.

 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)


 How is this broken and how should it behave? -- Andrei


It's broken because it's inconsistent. If the compiler is going to 
complain about races in one case, but not in other equivalent cases, 
then the feature is useless.

If all I have to do to avoid compiler complaints is rewrite my 
expression in an equivalent way, then what is the point of the 
complaint? At that point, it's just a style guide.

What should it do? If I knew that, then I'd have proposed a DIP by now. 
It's not an easy problem to solve. I don't think you can "solve" races 
because the compiler can't see all interactions with data.

At first glance, it seems that shared data shouldn't be usable without 
some kind of explicit usage syntax. x = x + 1 is too innocuous looking. 
It's not going to "solve" the issue, but it makes the code easier to 
pick out.

-Steve
Aug 12 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/12/16 6:58 PM, Steven Schveighoffer wrote:

 On 8/12/16 2:04 PM, Andrei Alexandrescu wrote:

 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:

 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 Honestly, I don't think that shared is broken.


 Yes. It is broken.

 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)


 How is this broken and how should it behave? -- Andrei


 It's broken because it's inconsistent. If the compiler is going to
 complain about races in one case, but not in other equivalent cases,
 then the feature is useless.


But ++expr and expr1 = expr1 + expr2 are fundamentally different.


 If all I have to do to avoid compiler complaints is rewrite my
 expression in an equivalent way, then what is the point of the
 complaint? At that point, it's just a style guide.


A bunch of rewrites to seemingly identical behavior to avoid type errors 
are de rigoeur in so many situations. This is no different.


 What should it do? If I knew that, then I'd have proposed a DIP by now.
 It's not an easy problem to solve. I don't think you can "solve" races
 because the compiler can't see all interactions with data.


++expr contains a low-level race that is worth removing. Extending that 
to a variety of sub-patterns of expr1 = expr2 + expr3 seems a terrible 
idea to me.


 At first glance, it seems that shared data shouldn't be usable without
 some kind of explicit usage syntax. x = x + 1 is too innocuous looking.
 It's not going to "solve" the issue, but it makes the code easier to
 pick out.


We discussed this at a point (some 10 years ago). It was:

atomicReadRef(x) = atomicRead(x) + 1;

But it's painfully obvious that yes the intent is to read the address 
and read the thing... so why need these anyway? So we left things as 
they are.

I agree shared needs work, but this is not it. We're wasting our time here.


Andrei
Aug 12 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/12/16 7:22 PM, Andrei Alexandrescu wrote:

 On 8/12/16 6:58 PM, Steven Schveighoffer wrote:

 On 8/12/16 2:04 PM, Andrei Alexandrescu wrote:

 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:

 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 Honestly, I don't think that shared is broken.


 Yes. It is broken.

 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)


 How is this broken and how should it behave? -- Andrei


 It's broken because it's inconsistent. If the compiler is going to
 complain about races in one case, but not in other equivalent cases,
 then the feature is useless.


 But ++expr and expr1 = expr1 + expr2 are fundamentally different.


It's not expr2, it's 1.

And no they aren't fundamentally different. Don't think like a compiler.


 If all I have to do to avoid compiler complaints is rewrite my
 expression in an equivalent way, then what is the point of the
 complaint? At that point, it's just a style guide.


 A bunch of rewrites to seemingly identical behavior to avoid type errors
 are de rigoeur in so many situations. This is no different.


It's not a type error. We have const, and pure, and  safe, which require 
you to write code in a way that enforces a guarantee.

shared does this in a half-assed way. It's not effective. It's like C++ 
const is not effective at guaranteeing anything stays constant.


 What should it do? If I knew that, then I'd have proposed a DIP by now.
 It's not an easy problem to solve. I don't think you can "solve" races
 because the compiler can't see all interactions with data.


 ++expr contains a low-level race that is worth removing. Extending that
 to a variety of sub-patterns of expr1 = expr2 + expr3 seems a terrible
 idea to me.


I agree that in general races cannot be detected and prevented. ++expr1 
is an obvious race, and it is detected and prevented. But it gives the 
impression that the compiler isn't going to let you make races. It gives 
the impression that the language has some level of guarantee about 
avoiding multi-threaded mistakes. It doesn't. It doesn't guarantee 
anything. It's just a helpful trick in one specific case.

I don't know what the right way to handle shared is. My opinion is 
simply that shared needs special handling from the user. The compiler 
isn't going to help you make thread-safe code, but at least allows you 
to mark where the unsafe code could be (by using shared type modifier).


 At first glance, it seems that shared data shouldn't be usable without
 some kind of explicit usage syntax. x = x + 1 is too innocuous looking.
 It's not going to "solve" the issue, but it makes the code easier to
 pick out.


 We discussed this at a point (some 10 years ago). It was:

 atomicReadRef(x) = atomicRead(x) + 1;

 But it's painfully obvious that yes the intent is to read the address
 and read the thing... so why need these anyway? So we left things as
 they are.

 I agree shared needs work, but this is not it. We're wasting our time here.


Hey, that's fine. I'd rather work on other things too. Shared just seems 
like an unfulfilled promise, with half-implemented protections.

I'd like to just see shared be unusable, and make people cast away 
shared to do anything. That at least is an attempt at preventing races 
without intention. The allowance of certain things that are obvious 
races, whereas other things that are obvious races are prevented makes 
one assume the worst.

-Steve
Aug 13 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, August 13, 2016 16:45:16 Steven Schveighoffer via Digitalmars-d 
wrote:

 Hey, that's fine. I'd rather work on other things too. Shared just seems
 like an unfulfilled promise, with half-implemented protections.

 I'd like to just see shared be unusable, and make people cast away
 shared to do anything. That at least is an attempt at preventing races
 without intention. The allowance of certain things that are obvious
 races, whereas other things that are obvious races are prevented makes
 one assume the worst.


I'm also tempted to argue that making shared virtually unusable without
casting it away would be a good idea - particularly when you consider that
most code that uses shared is going to need to cast it away to do anything
with it (even if we had synchronized classes, that would still be the case -
it would just be that under some circumstances, the compiler would do it for
you). Maybe we don't want to go quite to the point that you have to cast
away shared to do anything other than pass it around (we probably have to
have assignment still not involve casting even though that would normally
need to be protected by a lock), but I do think that that's the direction
that we shoudld be leaning in.

However, it sounds like Walter wants to postpone discussing this seriously
until after scope is sorted out. I think that it's clear that Walter and
Andrei agree that some work needs to be done on formalizing shared, and
maybe it should be pushed soon, but it sounds like we should wait until
after this DIP is sorted out to really get into it. It _is_ one area that we
need to make sure that we have done though. I think that the basics of how
shared has been done are right, but we do need to make sure that the details
are sorted out correctly and that it's clear how shared should be used,
since as it is, way too many folks just slap __gshared on stuff if they want
it to be shared (which is almost always the wrong thing to do).

- Jonathan M Davis
Aug 13 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/13/2016 2:57 PM, Jonathan M Davis via Digitalmars-d wrote:

 I'm also tempted to argue that making shared virtually unusable without
 casting it away would be a good idea - particularly when you consider that
 most code that uses shared is going to need to cast it away to do anything
 with it (even if we had synchronized classes, that would still be the case -
 it would just be that under some circumstances, the compiler would do it for
 you).


I suspect that's what the end result will be with shared. Anything else just 
seems like an illusion of correctness.



 However, it sounds like Walter wants to postpone discussing this seriously
 until after scope is sorted out.


Yes.



 way too many folks just slap __gshared on stuff if they want
 it to be shared (which is almost always the wrong thing to do).


That's why it's not allowed in  safe code.
Aug 13 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:

 I'm also tempted to argue that making shared virtually unusable without
 casting it away would be a good idea


It's a bad idea, no two ways about it. The bummer here is that this is 
the only topic (and one where D gets it right) off of a whole list that 
Shachar gave, which I'll copy below. His slides are at 
http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improv
ment-opportunities. 
Is the talk video anywhere?


 - No RAII support, despite the fact everybody here seems to think that D
supports RAII.


So that is slide 4. Could you please give a bit of detail?


 - Recursive const makes many cases where I can use const in C++ (and
 enjoy the protection it provides) simply mutable in D.


(It's transitive, not recursive.) Can't help much here but note that 
C++'s const being shallow is a source of confusion among beginning 
programmers. It's a matter in which reasonable people may disagree. I 
clearly see how someone used to C++'s const wold feel uncomfortable with 
D's.


 - This one I have not complained about yet. Operator overloads
 stepping on each other's toes. In my case, I have a container (with
 opIndex that accepts a custom type and opOpAssign!"~") and I place in
 it a struct with some operator overloads as well (have not reduced
 the cause yet, hence no previous complaint about this one). So, when
 I write

 Container[IndexType] ~= Type;

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

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

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

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


The opIndexOpAssign family is intentional and arguably a good thing. The 
semantics of std::map's operator[] are controversial and suboptimal; 
opIndexOpAssign is specially designed to allow efficient dictionaries 
and sparse arrays. If you get to reduce the code we'd definitely want to 
fix whatever bug is there.


 - GC. GC. GC. Some more GC.


You mean there's too much of it? We're on that.


 - Integral type operations promotion and the constant need for casts.


This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP 
has bugs that we need to fix.


 - No warning for signed/unsigned comparisons. An unfailing source for bugs.


This is actionable too.


 - No ref type.


This you need to live with.

We'd love to make the life easier for Weka, but you need to be careful 
when mixing things of the D ethos you don't like but won't change 
(qualifiers, ref) with things that we can improve.

Did you try the .d/.di compile-time table?


Andrei
Aug 13 2016
next sibling parent Seb <seb wilzba.ch> writes:
On Sunday, 14 August 2016 at 00:26:31 UTC, Andrei Alexandrescu 
wrote:

 On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d 
 wrote:

 I'm also tempted to argue that making shared virtually 
 unusable without
 casting it away would be a good idea


 It's a bad idea, no two ways about it. The bummer here is that 
 this is the only topic (and one where D gets it right) off of a 
 whole list that Shachar gave, which I'll copy below. His slides 
 are at 
 http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improv
ment-opportunities. Is the talk video anywhere?


https://youtu.be/yIH_0ew-maI?t=21m34s
Aug 13 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 14/08/16 03:26, Andrei Alexandrescu wrote:

 On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:

 I'm also tempted to argue that making shared virtually unusable without
 casting it away would be a good idea


 It's a bad idea, no two ways about it. The bummer here is that this is
 the only topic (and one where D gets it right) off of a whole list that
 Shachar gave, which I'll copy below. His slides are at
 http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improvement-opportunities.
 Is the talk video anywhere?


 - No RAII support, despite the fact everybody here seems to think that
 D supports RAII.


 So that is slide 4. Could you please give a bit of detail?


http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html


 - Recursive const makes many cases where I can use const in C++ (and
 enjoy the protection it provides) simply mutable in D.


 (It's transitive, not recursive.) Can't help much here but note that
 C++'s const being shallow is a source of confusion among beginning
 programmers. It's a matter in which reasonable people may disagree. I
 clearly see how someone used to C++'s const wold feel uncomfortable with
 D's.


I'm quite fine with disagreeing on this point, but I do want to make 
sure we agree on what it is we disagree about.

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

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

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

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

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

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

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

Compound this with the total mess that is "inout", and I, personally, 
just gave up. I know I'm not the only one.


 The opIndexOpAssign family is intentional and arguably a good thing. The
 semantics of std::map's operator[] are controversial and suboptimal;
 opIndexOpAssign is specially designed to allow efficient dictionaries
 and sparse arrays. If you get to reduce the code we'd definitely want to
 fix whatever bug is there.


I will. I just don't know how long it will take me to get to it. I 
already tried to recreate it simply with two structs and just the 
relevant ops, without success (though, now that I think of it, it might 
have been with a different version than the one that compiles our code).

If you want, since I know you have access, I can send you the line 
number from which this was taken.

Either way, this is just one example out of many where the interaction 
between features creates complex situations that either result in not 
defined (as opposed to undefined) behavior, or result in behavior that 
may be well defined, but is surprising to the programmer.


 - GC. GC. GC. Some more GC.


 You mean there's too much of it? We're on that.


Not exactly, but I have nothing to say here which you don't already 
know, so let's leave it at that.


 - Integral type operations promotion and the constant need for casts.


 This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP
 has bugs that we need to fix.


Won't solve my problems unless VRP's scope is significantly enhanced. 
Your book said VRP is only defined to work on the same expression it is 
in. So long as that's the case, it's not a matter of fixing bugs.

Also, I should point out, that I'm not suggesting D allow implicit 
narrowing conversions. Instead, I think D should drop the pretense that 
C expressions should maintain their semantics precisely, and stop 
widening expressions.

I must confess that I have never heard of this rule in C before 
encountering it in D. Any time I needed some expression to take place 
with a width larger than the input arguments, I always casted them.

Since this is still necessary for long, I think dropping this rule won't 
be too big of an issue.


 - No ref type.


 This you need to live with.


Can you expand a little on the rational for that? Also, part of our 
problems with this is that introspection also does not see refs, which 
causes the following two functions to report the same signature:

void func1(int arg);
void func2(ref int arg);



 We'd love to make the life easier for Weka,


I'd like to make it clear here that I speak of my own experience. I do 
talk with people, and some of the engineers share some of my criticism. 
However, please don't think that just because I'm more vocal than others 
in Weka, it means that my opinions are shared by all. Please treat my 
posts here as my own.

  but you need to be careful

 when mixing things of the D ethos you don't like but won't change
 (qualifiers, ref) with things that we can improve.

 Did you try the .d/.di compile-time table?


Not my task, so what I'm writing here is second hand knowledge from one 
random water cooler talk. Please excuse me if I'm making gross 
misrepresentations of reality here.

 From what I understand, there is a problem with the way imports are put 
in the di files. In particular, take the following code:

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

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

The ideal di for it would be:

import some.struct: SomeStruct;

SomeStruct func();

Sadly, the actual di also contains the totally unnecessary:

import some.other.struct: SomeOtherStruct;

The result is that the di contains too many imports, and no gains are 
made vis compilation times.

Shachar
Aug 13 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/14/2016 01:18 AM, Shachar Shemesh wrote:

 On 14/08/16 03:26, Andrei Alexandrescu wrote:

 On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:

 I'm also tempted to argue that making shared virtually unusable without
 casting it away would be a good idea


 It's a bad idea, no two ways about it. The bummer here is that this is
 the only topic (and one where D gets it right) off of a whole list that
 Shachar gave, which I'll copy below. His slides are at
 http://www.slideshare.net/ShacharShemesh1/dconf-2016-d-improvement-opportunities.

 Is the talk video anywhere?


 - No RAII support, despite the fact everybody here seems to think that
 D supports RAII.


 So that is slide 4. Could you please give a bit of detail?


 http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html


OK. One thing we can't stress enough is that everything - talks, slides, 
newsgroup posts - about a bug in the language definition or 
implementation must be in support of an issue. No issue no honey. I 
submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf 
and preapproved it. Please carry future considerations there.


 I'm quite fine with disagreeing on this point, but I do want to make
 sure we agree on what it is we disagree about.

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

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

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

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

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

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

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

 Compound this with the total mess that is "inout", and I, personally,
 just gave up. I know I'm not the only one.


I understand. One thing we want to do to improve on that is to deduce 
const for template methods. See 
https://issues.dlang.org/show_bug.cgi?id=16389.


 The opIndexOpAssign family is intentional and arguably a good thing. The
 semantics of std::map's operator[] are controversial and suboptimal;
 opIndexOpAssign is specially designed to allow efficient dictionaries
 and sparse arrays. If you get to reduce the code we'd definitely want to
 fix whatever bug is there.


 I will. I just don't know how long it will take me to get to it. I
 already tried to recreate it simply with two structs and just the
 relevant ops, without success (though, now that I think of it, it might
 have been with a different version than the one that compiles our code).

 If you want, since I know you have access, I can send you the line
 number from which this was taken.

 Either way, this is just one example out of many where the interaction
 between features creates complex situations that either result in not
 defined (as opposed to undefined) behavior, or result in behavior that
 may be well defined, but is surprising to the programmer.


This being a matter of perception, there's no disagreement here. To turn 
this into something actionable it would be great if you thought of ways 
to simplify said interaction without breaking code (e.g. by removing 
unnecessary constraints).


 - Integral type operations promotion and the constant need for casts.


 This is... funny coming from a self-proclaimed C++ lover. Anyhow, VRP
 has bugs that we need to fix.


 Won't solve my problems unless VRP's scope is significantly enhanced.
 Your book said VRP is only defined to work on the same expression it is
 in. So long as that's the case, it's not a matter of fixing bugs.


It's a matter of school of thought. C and C++ allow implicit casts that 


casts needed. Here again we're not talking about a bug in the language 
or the "right" or "wrong" language design, it's just a matter in which 
different languages do different things.


 Also, I should point out, that I'm not suggesting D allow implicit
 narrowing conversions. Instead, I think D should drop the pretense that
 C expressions should maintain their semantics precisely, and stop
 widening expressions.


This will not happen.


 I must confess that I have never heard of this rule in C before
 encountering it in D.


Which rule?


 Any time I needed some expression to take place
 with a width larger than the input arguments, I always casted them.


So then why do you complain D asks for "too many" casts?


 Since this is still necessary for long, I think dropping this rule won't
 be too big of an issue.


You kind of lost me there. So which rule?


 - No ref type.


 This you need to live with.


 Can you expand a little on the rational for that?


The "ref" attribute has been a fundamental part of the language for too 
long.


 Also, part of our
 problems with this is that introspection also does not see refs, which
 causes the following two functions to report the same signature:

 void func1(int arg);
 void func2(ref int arg);


I actually think you can do introspection on any argument to figure 
whether it has "ref".


 We'd love to make the life easier for Weka,


 I'd like to make it clear here that I speak of my own experience. I do
 talk with people, and some of the engineers share some of my criticism.
 However, please don't think that just because I'm more vocal than others
 in Weka, it means that my opinions are shared by all. Please treat my
 posts here as my own.


There are some good points that we could easily agree need to be 
improved. At some point you must get in gear and submit some issues to 
move forward on things important to Weka.


 From what I understand, there is a problem with the way imports are put
 in the di files. In particular, take the following code:

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

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

 The ideal di for it would be:

 import some.struct: SomeStruct;

 SomeStruct func();

 Sadly, the actual di also contains the totally unnecessary:

 import some.other.struct: SomeOtherStruct;

 The result is that the di contains too many imports, and no gains are
 made vis compilation times.


I think you forgot to mention the issue number :o).


Andrei
Aug 14 2016
next sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 14/08/16 17:07, Andrei Alexandrescu wrote:

 On 08/14/2016 01:18 AM, Shachar Shemesh wrote:

 So that is slide 4. Could you please give a bit of detail?


 http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html


 
 OK. One thing we can't stress enough is that everything - talks, slides,
 newsgroup posts - about a bug in the language definition or
 implementation must be in support of an issue. No issue no honey. I
 submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf
 and preapproved it. Please carry future considerations there.


Thank you. To be fair, though, you might want to close it as a duplicate
of https://issues.dlang.org/show_bug.cgi?id=14246




 I understand. One thing we want to do to improve on that is to deduce
 const for template methods. See
 https://issues.dlang.org/show_bug.cgi?id=16389.


Personally, I also think that inout should stop acting like it is a
fourth form of protection.

 Here again we're not talking about a bug in the language
 or the "right" or "wrong" language design, it's just a matter in which
 different languages do different things.
 

 Also, I should point out, that I'm not suggesting D allow implicit
 narrowing conversions. Instead, I think D should drop the pretense that
 C expressions should maintain their semantics precisely, and stop
 widening expressions.


 
 This will not happen.


I had a whole list of places where D already isn't compatible with C for
a statement that compiles in both. I cannot find it. I'll start a new
thread when I do.


 

 I must confess that I have never heard of this rule in C before
 encountering it in D.


 
 Which rule?


The rule that says "ubyte + ubyte = uint".


 Can you expand a little on the rational for that?


 
 The "ref" attribute has been a fundamental part of the language for too
 long.


I'm sorry, I simply don't understand that answer. How is turning "ref"
into a type modifier hinder you in any way? No old compiling code breaks
as a result.


 

 Also, part of our
 problems with this is that introspection also does not see refs, which
 causes the following two functions to report the same signature:

 void func1(int arg);
 void func2(ref int arg);


 
 I actually think you can do introspection on any argument to figure
 whether it has "ref".
 

 We'd love to make the life easier for Weka,


 I'd like to make it clear here that I speak of my own experience. I do
 talk with people, and some of the engineers share some of my criticism.
 However, please don't think that just because I'm more vocal than others
 in Weka, it means that my opinions are shared by all. Please treat my
 posts here as my own.


 
 There are some good points that we could easily agree need to be
 improved. At some point you must get in gear and submit some issues to
 move forward on things important to Weka.


The problem is that many of those points are contended (or, at least,
used to be). If you read through the thread I pointed to regarding the
destructor issue, for example, you will see that people actually argue
that the way D currently does things is the correct way to do things.

If I submit an issue to the forum, and get back the reply "that's a know
thing, and that's on purpose", I don't see any point in submitting an issue.


 

 From what I understand, there is a problem with the way imports are put
 in the di files. In particular, take the following code:

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

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

 The ideal di for it would be:

 import some.struct: SomeStruct;

 SomeStruct func();

 Sadly, the actual di also contains the totally unnecessary:

 import some.other.struct: SomeOtherStruct;

 The result is that the di contains too many imports, and no gains are
 made vis compilation times.


 
 I think you forgot to mention the issue number :o).


Like I said, I'm just a relay on that front. I'll try to get the people
actually working on it to submit an issue.

Shachar
Aug 14 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/14/16 2:03 PM, Shachar Shemesh wrote:

 On 14/08/16 17:07, Andrei Alexandrescu wrote:

 On 08/14/2016 01:18 AM, Shachar Shemesh wrote:

 So that is slide 4. Could you please give a bit of detail?


 http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html


 OK. One thing we can't stress enough is that everything - talks, slides,
 newsgroup posts - about a bug in the language definition or
 implementation must be in support of an issue. No issue no honey. I
 submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf
 and preapproved it. Please carry future considerations there.


 Thank you. To be fair, though, you might want to close it as a duplicate
 of https://issues.dlang.org/show_bug.cgi?id=14246


Thanks. For now I raised both to critical.


 I understand. One thing we want to do to improve on that is to deduce
 const for template methods. See
 https://issues.dlang.org/show_bug.cgi?id=16389.


 Personally, I also think that inout should stop acting like it is a
 fourth form of protection.


I'm not a fan of inout either. We need to think collectively of ways to 
move things forward from where we are to a better place.


 Also, I should point out, that I'm not suggesting D allow implicit
 narrowing conversions. Instead, I think D should drop the pretense that
 C expressions should maintain their semantics precisely, and stop
 widening expressions.


 This will not happen.


 I had a whole list of places where D already isn't compatible with C for
 a statement that compiles in both. I cannot find it. I'll start a new
 thread when I do.


That would be very helpful.


 I must confess that I have never heard of this rule in C before
 encountering it in D.


 Which rule?


 The rule that says "ubyte + ubyte = uint".


That will not happen. It would break tons of code in subtle ways. You 
are a competent engineer so you know better than asking for it.


 Can you expand a little on the rational for that?


 The "ref" attribute has been a fundamental part of the language for too
 long.


 I'm sorry, I simply don't understand that answer. How is turning "ref"
 into a type modifier hinder you in any way? No old compiling code breaks
 as a result.


Of course it breaks all code that introspects e.g. parameter types and 
finds "ref T" instead of "T". It is a fundamental change to the language 
that is also questionable on its own (C++ has and continues to have 
inordinate complications because of references being an almost-type). 
Pick your fights properly, and fight them well.


 Also, part of our
 problems with this is that introspection also does not see refs, which
 causes the following two functions to report the same signature:

 void func1(int arg);
 void func2(ref int arg);


 I actually think you can do introspection on any argument to figure
 whether it has "ref".




Just making sure you read the above. Please give it a look.


 There are some good points that we could easily agree need to be
 improved. At some point you must get in gear and submit some issues to
 move forward on things important to Weka.


 The problem is that many of those points are contended (or, at least,
 used to be). If you read through the thread I pointed to regarding the
 destructor issue, for example, you will see that people actually argue
 that the way D currently does things is the correct way to do things.


Did anyone in the leadership say so? If not, you're safe to ignore it; 
statistically anything suggested herein will find a strong opponent. I'm 
with you on this, and Walter is too (just confirmed via email). The 
issues are preapproved. I've also raised the issues to critical.


 If I submit an issue to the forum, and get back the reply "that's a know
 thing, and that's on purpose", I don't see any point in submitting an issue.


If you get it from Walter and myself, yes. Otherwise, again, ignore and 
press on. Again: choose your fights and fight them well. I know in your 
heart of hearts have an understanding of what you can change and what 
you cannot.


 The result is that the di contains too many imports, and no gains are
 made vis compilation times.


 I think you forgot to mention the issue number :o).


 Like I said, I'm just a relay on that front. I'll try to get the people
 actually working on it to submit an issue.


Thanks. I should add that as long as the .di does not import the .d, the 
slowdown due to the computed table will not occur. So the worry is not 
warranted.


Andrei
Aug 14 2016
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, August 14, 2016 14:35:49 Andrei Alexandrescu via Digitalmars-d 
wrote:

 On 8/14/16 2:03 PM, Shachar Shemesh wrote:

 On 14/08/16 17:07, Andrei Alexandrescu wrote:

 On 08/14/2016 01:18 AM, Shachar Shemesh wrote:

 I must confess that I have never heard of this rule in C before
 encountering it in D.


 Which rule?


 The rule that says "ubyte + ubyte = uint".


 That will not happen. It would break tons of code in subtle ways. You
 are a competent engineer so you know better than asking for it.


No offense, but that comes across as pretty condescending. I agree that
changing the integer promotion rules would be very risky, but that's the
sort of response that seems more likely to offend than to educate or
convince.

- Jonathan M Davis
Aug 14 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/14/16 11:40 PM, Jonathan M Davis via Digitalmars-d wrote:

 On Sunday, August 14, 2016 14:35:49 Andrei Alexandrescu via Digitalmars-d
 wrote:

 On 8/14/16 2:03 PM, Shachar Shemesh wrote:

 On 14/08/16 17:07, Andrei Alexandrescu wrote:

 On 08/14/2016 01:18 AM, Shachar Shemesh wrote:

 I must confess that I have never heard of this rule in C before
 encountering it in D.


 Which rule?


 The rule that says "ubyte + ubyte = uint".


 That will not happen. It would break tons of code in subtle ways. You
 are a competent engineer so you know better than asking for it.


 No offense, but that comes across as pretty condescending. I agree that
 changing the integer promotion rules would be very risky, but that's the
 sort of response that seems more likely to offend than to educate or
 convince.


Apologies for the possible offensive interpretation. My statement should 
be taken at face value - it is indeed not difficult for a programmer to 
project that changing a fundamental operator typing rule has wide 
ripples. My larger point is that there's a clear distinction among 
Shachar's list items: some are things we can work on, and some aren't. 
Putting them together dilutes the positive impact of the list. -- Andrei
Aug 14 2016
parent reply John Smith <gyroheli gmail.com> writes:
Well there are some things I feel could be improved, a lot of the 
things are really just minor but what is a deal breaker for me 
mostly is the compilers. The GCC and Clang implementations are 
really far behind in terms of the version, so they are missing a 
lot of features. A lot of the features that I'd want to use D 
for. In the download section it also says "good optimization" but 
it honestly isn't. I rewrote a small portion for one of my 
projects to test out D but looking at the assembly a lot of it 
was questionable. I'd say DMD probably produced the best assembly 
but then there's the problem that it doesn't support MMX 
instructions. Even on 64-bit it still uses the FPU, which I can't 
really use. The FPU isn't consistent enough for simulations that 
run on separate computers and different OSs that need to be 
synced through a network.

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

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

http://ideone.com/INGSsZ

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

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

On Sunday, 14 August 2016 at 18:45:06 UTC, Walter Bright wrote:

 This rule was retained for D to make it easier to translate 
 code from C/C++ to D. Changing the rule could result in subtle 
 and invisible bugs for such translations and for C/C++ 
 programmers who are so used to the integral promotion rules 
 that they aren't even really aware of reliance upon them.

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

     byte = byte + byte;

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

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

     byte = cast(byte)(byte + byte);


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

On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:

 Well there are some things I feel could be improved, a lot of 
 the things are really just minor but what is a deal breaker for 
 me mostly is the compilers. The GCC and Clang implementations 
 are really far behind in terms of the version, so they are 
 missing a lot of features. A lot of the features that I'd want 
 to use D for.


That's not true for LDC - it's on par with the latest DMD version 
since a while now. It might be that the version shipped with your 
Linux distribution is a bit outdated.

http://forum.dlang.org/post/uxupejapglpeokaiqqjg forum.dlang.org



 In the download section it also says "good optimization" but it 
 honestly isn't. I rewrote a small portion for one of my 
 projects to test out D but looking at the assembly a lot of it 
 was questionable. I'd say DMD probably produced the best 
 assembly but then there's the problem that it doesn't support 
 MMX instructions.


That's weird - LDC allows great optimization, see e.g. these two 
benchmarks:

https://github.com/kostya/benchmarks
http://forum.dlang.org/post/zxkkjezakirlfepndjxk forum.dlang.org


 Even on 64-bit it still uses the FPU, which I can't really use. 
 The FPU isn't consistent enough for simulations that run on 
 separate computers and different OSs that need to be synced 
 through a network.


Inconsistent FP math is a known issue, but most likely a 
fusedMath pragma will be added soon:

http://forum.dlang.org/post/hjaiavlfkoamenidomsa forum.dlang.org
https://github.com/ldc-developers/ldc/issues/1669


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


Yep you are correct about the motivation: __gshared got its ugly 
name to remind
the programmer about the dangerous world he wades into.
There are usually safer & more elegant ways, e.g.:

http://tour.dlang.io/tour/en/multithreading/std-parallelism
http://tour.dlang.io/tour/en/multithreading/synchronization-sharing
http://tour.dlang.io/tour/en/multithreading/message-passing
Aug 18 2016
prev sibling next sibling parent ag0aep6g <anonymous example.com> writes:
On 08/19/2016 12:50 AM, John Smith wrote:

 Well there are some things I feel could be improved, a lot of the things
 are really just minor but what is a deal breaker for me mostly is the
 compilers. The GCC and Clang implementations are really far behind in
 terms of the version, so they are missing a lot of features. A lot of
 the features that I'd want to use D for.


LDC has been catching up quite nicely. LDC 1.0.0 (current release) is at 
front-end 2.070, and 1.1.0 (beta) is at 2.071 which matches the current 
DMD release.

https://github.com/ldc-developers/ldc/releases


 In the download section it also
 says "good optimization" but it honestly isn't. I rewrote a small
 portion for one of my projects to test out D but looking at the assembly
 a lot of it was questionable. I'd say DMD probably produced the best
 assembly but then there's the problem that it doesn't support MMX
 instructions.


I'm not very knowledgeable on optimized machine code, but as far I know, 
LDC/GDC usually produce significantly faster binaries than DMD. So when 
DMD comes out ahead, that's not typical. Might be an outlier.

[...]

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


That's exactly it. `__gshared` has a weird name because `shared` should 
generally be used instead. `__gshared` throws thread-safety out the 
window, while `shared` is supposed to at least make sure that the 
shared-ness is visible to the programmer.


 But it is used a lot, and it wouldn't be possible to do certain
 things without it. I forget but the dynamic library loader for D,
 derelict, is one such case.


Those certain things should be relatively rare low-level tasks. When 
`__gshared` is used more than `shared`, then `shared` may (currently) be 
failing its goals. Of course, a low-level project like Derelict may just 
have more use for `__gshared`.


 There's no "const T&" equivalent in D. Basically constant variables need
 to be copied and non-constant variables can be passed with the use of
 "ref". So you need to write two different functions that in essence do
 the same thing.


You can pass const variables per ref: void foo(ref const int bar) {}

What you can't do is pass rvalues in such a parameter. That's what the 
other function/overload is needed for. That doesn't mean that everything 
is just fine as it is.

[...]

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


You may be aware of this, but you can slice a T[n] to get a T[] which is 
a range.

[...]

 Well you could say the same for the same for int. Why isn't "int + int =
 long"? Right now it is following the rule "int + int = int". Maybe cause
 the values aren't as small but I could argue the same thing. If we add
 2147483647 with 2147483647, the value stored is -2. Under the same sort
 of thought, you probably wouldn't find that acceptable either correct?
 At some point you are going to run out of types that have larger
 storage. What is "cent + cent" going to have as a larger type? At some
 point you just have to accept that you are working with a finite set of
 numbers. For D the compromise happens with the type int. C/C++ just
 accepts that and maintains consistency rather than flip floping at an
 arbitrary type.


I don't think that C "just accepts that". It still promotes a sum of 
smaller types to int.

Observe:

----
#include<stdio.h>

int main()
{
     unsigned char a = 255;

     printf("%d\n", (a + a) / 2); /* 255 */
     printf("%d\n", (unsigned char)(a + a) / 2); /* 127 */

     return 0;
}
----

If `a + a` were an unsigned char, we'd expect the two outputs to be the 
same.

The difference between D and C is that C has implicit narrowing. I.e., 
it lets you assign an int to a char just like that, throwing away the 
high bits. D requires a cast for it.

So, why is int the go-to type? I can't answer with authority, but for D 
I think it's just because that's what C does.
Aug 18 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:

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


std.range is one of the libraries that has never used the GC 
much. Only tiny parts of it ever have,

Moreover, dynamic arrays do not necessarily have to be GC'd. 
Heck, you can even malloc them if you want to 
(`(cast(int*)malloc(int.sizeof))[0 .. 1]` gives an int[] of 
length 1).

This has been a common misconception lately... :(



 Well you could say the same for the same for int. Why isn't 
 "int + int = long"?


Yeah, if I was designing things, I'd make it promote the smaller 
size to the larger size in the expression. So byte + byte = byte 
and byte + short goes to short, and so on. Moreover, I'd make it 
check both sides of the equation, so int = byte + byte would 
convert the bytes to ints first too. It'd be quite nice, and I 
think it would work in most cases... it might even work the same 
as C in most cases, though I'm not sure.

(the one thing people might find weird is auto a = b + c; means a 
is a byte if b and c are bytes. In C, it would be an int. but who 
writes that in C anyway.)


Alas, C insisted on making everything int all the time and D 
followed that :(
Aug 18 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:

 Alas, C insisted on making everything int all the time and D followed that :(


One would have to be *really* sure of their ground in coming up with allegedly 
better rules.
Aug 19 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 20/08/16 00:51, Walter Bright wrote:

 On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:

 Alas, C insisted on making everything int all the time and D followed
 that :(




Actually, Adam's suggestion on how things should work is precisely how C 
works (except it trails off at int).

a = b + c;

if b and c are both a byte, and a is a byte, the result is unpromoted. 
If a is a short, the result is promoted. I know the mechanism is 
completely different than what Adam was suggesting, but the end result 
is precisely the same.


 One would have to be *really* sure of their ground in coming up with
 allegedly better rules.


Would "no narrowing implicit casts" be considered such a better rule? :-)

Again, I'm not saying it's a bad rule, just that does have consequences. 
What I'm saying is that we are, already, changing things.

Shachar
Aug 20 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/20/2016 8:25 AM, Shachar Shemesh wrote:

 Actually, Adam's suggestion on how things should work is precisely how C works


No, it's subtly different. Which is my point that one must be very, very
careful 
when proposing different behavior.
Aug 20 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 20/08/16 21:00, Walter Bright wrote:

 On 8/20/2016 8:25 AM, Shachar Shemesh wrote:

 Actually, Adam's suggestion on how things should work is precisely how
 C works


 No, it's subtly different. Which is my point that one must be very, very
 careful when proposing different behavior.


Can you give an example of an expression that would yield different 
results in both modes?


To frame the discussion in a constructive way, I'll suggest an 
algorithmic definition of (my interpretation of) Adam's proposal:

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

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

If more than one use is possible (i.e. - overloading), use the largest 
one applicable.


I believe the above solves my problem, without losing compatibility with 
C (counter examples welcome, so we can continue the discussion in a 
productive way), and without foregoing erroring out on narrowing 
conversions.

Shachar
Aug 20 2016
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 08/21/2016 07:12 AM, Shachar Shemesh wrote:

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


What's "most expanded"?


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


So when only ubytes are involved, all calculations would be done on 
ubytes, no promotions, right? There are cases where that would give 
different results than doing promotions.

Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands are 
promoted to a larger type, you get 255 as the result. If they are not, 
you have the equivalent of `ubyte x = 255; x *= 2; x /= 2;` which gives 
you 127.
Aug 21 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/21/2016 2:47 AM, ag0aep6g wrote:

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


 So when only ubytes are involved, all calculations would be done on ubytes, no
 promotions, right? There are cases where that would give different results than
 doing promotions.

 Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands are promoted to a
 larger type, you get 255 as the result. If they are not, you have the
equivalent
 of `ubyte x = 255; x *= 2; x /= 2;` which gives you 127.


That's right.

The thing is, programmers are so used to C integral promotion rules they often 
are completely unaware of them and how they work, despite relying on them. This 
is what makes changing the rules so pernicious and dangerous.

I've had to explain the promotion rules to professionals with 10 years of 
experience in C/C++, and finally stopped being surprised at that.

D does change the rules, but only in a way that adds compile time errors to 
them. So no surprises.

(Nobody knows how function overloading works in C++ either, but that's 
forgivable :-) )
Aug 21 2016
parent reply Solomon E <default avatar.org> writes:
On Sunday, 21 August 2016 at 17:26:24 UTC, Walter Bright wrote:

 On 8/21/2016 2:47 AM, ag0aep6g wrote:

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


 So when only ubytes are involved, all calculations would be 
 done on ubytes, no
 promotions, right? There are cases where that would give 
 different results than
 doing promotions.

 Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands 
 are promoted to a
 larger type, you get 255 as the result. If they are not, you 
 have the equivalent
 of `ubyte x = 255; x *= 2; x /= 2;` which gives you 127.


 That's right.

 The thing is, programmers are so used to C integral promotion 
 rules they often are completely unaware of them and how they 
 work, despite relying on them. This is what makes changing the 
 rules so pernicious and dangerous.

 I've had to explain the promotion rules to professionals with 
 10 years of experience in C/C++, and finally stopped being 
 surprised at that.

 D does change the rules, but only in a way that adds compile 
 time errors to them. So no surprises.

 (Nobody knows how function overloading works in C++ either, but 
 that's forgivable :-) )


I have a speculative answer to the topic of this thread, which I 
was wanting to write a comment here about, before I saw the last 
two comments in this thread.

Look in the D Language Reference, the spec. Look for the word 
"error" there. It occurs many times, in code that is erroneous in 
the spec.

Also, notice the number of question marks in the code sample near 
the end of the page on Declarations. Notice that the questions 
raised are not answered there.

The D spec is full of errors, literally, or teasers sometimes. It 
seems improbable to me that D will become popular unless that is 
first fixed, and the attitude that it represents. It's a sign of 
unsoundness, at least unsoundness about how to teach a language 
or how to standardize it, that comes through clearly at a surface 
level, even if someone doesn't have specific disagreements with 
the design of D.

Erroneous code should be omitted from a spec, or at least clearly 
marked such as by a red background.

Mixing lines commented as errors together with later lines 
commented as "ok" in the same code quote blocks makes it even 
more confusing. (Someone who doesn't know any D yet might even 
think that D gives you the results of whatever lines are correct, 
skipping the errors as if they were empty lines. Programming 
languages differ enough that that's a possible feature, the sort 
of feature that might result in a language being described as 
"exciting" even.)

Anyone feel free to correct me or say I'm all wrong about this. 
I'm not an expert on teaching programming languages. I'm just a 
learner, and just as a hobby.
Aug 21 2016
parent Solomon E <default avatar.org> writes:
On Sunday, 21 August 2016 at 23:07:43 UTC, Solomon E wrote:

 The D spec is full of errors, literally, or teasers sometimes.


....

 Erroneous code should be omitted from a spec, or at least 
 clearly marked such as by a red background.


I'd like to respond critically to my own silly comment.

It's a great achievement that D has so many features, more 
versatility than C++, and yet the same few pages can serve as 
both the language specification and as the language reference for 
experienced D programmers, and also as an introduction to D 
features for programmers new to D, and include sufficient 
examples of what should cause errors as well as what should be 
valid code. It helps make the language lighter to pick up and 
better maintained than if it had separate long books of official 
information for each of those 5 purposes.

So the complaint that errors should have a "red background" is 
classic bikeshedding about what color to paint the bikeshed. Most 
people don't have any difficulty seeing "// error" at or near the 
end of a line as a clear marker that the whole line is an error 
before they start reading the line as if it might be valid, 
shifting their intuition of what the text is trying to say, then 
have the ending surprise them. Most people don't turn around and 
then think "// ok" is a surprise ending either. Most people don't 
have any difficulty scanning for sets of valid formulas or 
sentences to use, or scanning for sets of errors or mistakes to 
avoid, when incorrect and correct lines are interspersed randomly 
in a reference or textbook.

Most programmers can handle languages that reverse the order of 
"if" statements or the order of declaration and use just as well. 
So putting the indicators of whether a line is an error or 
correct at the end of a line is an arbitrary, harmless choice.

If a significant number of people did have any problem with that, 
it would have been cleaned up already. So obviously it isn't a 
problem and it's just a ridiculous, whiny complaint.
Aug 22 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 21/08/16 12:47, ag0aep6g wrote:

 On 08/21/2016 07:12 AM, Shachar Shemesh wrote:

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


 What's "most expanded"?


As expanded as we plan on making it. In our current semantics, "int" or 
"uint".


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


 So when only ubytes are involved, all calculations would be done on
 ubytes, no promotions, right? There are cases where that would give
 different results than doing promotions.

 Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands are
 promoted to a larger type, you get 255 as the result. If they are not,
 you have the equivalent of `ubyte x = 255; x *= 2; x /= 2;` which gives
 you 127.


You are right. This is a hole in this suggestion. Let me think if it is 
plugable.

Shachar
Aug 21 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 22 August 2016 at 05:54:17 UTC, Shachar Shemesh wrote:

 On 21/08/16 12:47, ag0aep6g wrote:

 Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands 
 are
 promoted to a larger type, you get 255 as the result. If they 
 are not,
 you have the equivalent of `ubyte x = 255; x *= 2; x /= 2;` 
 which gives
 you 127.


 You are right. This is a hole in this suggestion. Let me think 
 if it is plugable.



I actually consider that no different than `float a = int(1) / 
int(2);` and see it as a feature.

But, of course, it does fall under the category of silent 
breaking change (well, we could warn, but still).
Aug 22 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/21/2016 01:12 AM, Shachar Shemesh wrote:

 I'll suggest an algorithmic definition of (my interpretation of) Adam's
 proposal:

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

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

 If more than one use is possible (i.e. - overloading), use the largest
 one applicable.


How is this different than VRP? -- Andrei
Aug 21 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/20/2016 11:25 AM, Shachar Shemesh wrote:

 On 20/08/16 00:51, Walter Bright wrote:

 On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:

 Alas, C insisted on making everything int all the time and D followed
 that :(




 Actually, Adam's suggestion on how things should work is precisely how C
 works (except it trails off at int).

 a = b + c;

 if b and c are both a byte, and a is a byte, the result is unpromoted.
 If a is a short, the result is promoted. I know the mechanism is
 completely different than what Adam was suggesting, but the end result
 is precisely the same.


Consider:

void fun(byte);
void fun(int);
fun(b + c);

Under the new rule, this code (and much more) would silently change 
behavior. How would that get fixed?


 One would have to be *really* sure of their ground in coming up with
 allegedly better rules.


 Would "no narrowing implicit casts" be considered such a better rule? :-)

 Again, I'm not saying it's a bad rule, just that does have consequences.
 What I'm saying is that we are, already, changing things.


Again: choose your fights/points and fight/make them well. This is not 
one worth having.


Andrei
Aug 21 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 21 August 2016 at 16:31:41 UTC, Andrei Alexandrescu 
wrote:

 Consider:

 void fun(byte);
 void fun(int);
 fun(b + c);


Does anybody actually do that in the real world? Given the int 
promotion rule, such an overload is something i'd flag as always 
bug prone and confusing anyway.

With D's current rules, I am more likely to make just the int 
version and cast stuff down inside to get user code to compile 
more easily. My color.d, for example, has this:

         /// Construct a color with the given values. They should 
be in range 0
<= x <= 255, where 255 is maximum intensity and 0 is minimum 
intensity.
         nothrow pure  nogc
         this(int red, int green, int blue, int alpha = 255) {
                 // workaround dmd bug 10937
                 if(__ctfe)
                         this.components[0] = cast(ubyte) red;
                 else
                         this.r = cast(ubyte) red;
                 this.g = cast(ubyte) green;
                 this.b = cast(ubyte) blue;
                 this.a = cast(ubyte) alpha;
         }


Just because I got sick of constantly doing the casts on the user 
side. VRP is brilliant in little cases, but the fact that it 
doesn't work across statements really hurts it in real world use.

These casts are arguably wrong, defeating the point of the no 
implicit narrowing rule, but when a rule is so annoying that you 
hack around it, it has already failed.
Aug 22 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 21/08/16 19:31, Andrei Alexandrescu wrote:

 On 08/20/2016 11:25 AM, Shachar Shemesh wrote:

 On 20/08/16 00:51, Walter Bright wrote:

 On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:

 Alas, C insisted on making everything int all the time and D followed
 that :(




 Actually, Adam's suggestion on how things should work is precisely how C
 works (except it trails off at int).

 a = b + c;

 if b and c are both a byte, and a is a byte, the result is unpromoted.
 If a is a short, the result is promoted. I know the mechanism is
 completely different than what Adam was suggesting, but the end result
 is precisely the same.


 Consider:

 void fun(byte);
 void fun(int);
 fun(b + c);

 Under the new rule, this code (and much more) would silently change
 behavior. How would that get fixed?


Not under my suggested implementation:

 If more than one use is possible (i.e. - overloading), use the largest one
applicable.


Shahcar
Aug 22 2016
parent reply Markus <markus orm.ich> writes:
Take a look on this discussion thread and you know WHY D IS NOT 
SO POPULAR.

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

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

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

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

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

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

Regards

Markus
Aug 29 2016
parent reply eugene <egordeev18 gmail.com> writes:
On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:

 Take a look on this discussion thread and you know WHY D IS NOT 
 SO POPULAR.

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



Hello,
the url https://dlang.org/overview.html states that "It's a 
practical language for practical programmers", i think this is 
the vision statement)))
Aug 29 2016
parent reply Markus <markus orm.ich> writes:
On Monday, 29 August 2016 at 14:31:50 UTC, eugene wrote:

 On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:

 Take a look on this discussion thread and you know WHY D IS 
 NOT SO POPULAR.

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



 Hello,
 the url https://dlang.org/overview.html states that "It's a 
 practical language for practical programmers", i think this is 
 the vision statement)))


Take a look on https://dlang.org/ : "D is a systems programming 
language with C-like syntax..."

The overview-page http://dlang.org/overview.html has two main 
sections which compares D with C++.

The tour https://tour.dlang.org/ is nearly empty, but on the 
first page it states that D is an "evolution of C++ (without the 
mistakes)" (the real content is hidden in the menu-sections).

Most of the (very good) articles in 
https://dlang.org/articles.html compare D-features with C++. If I 
want to learn how D templates work, I do not need to know what is 
bad in C++-Templates.

 From my point of view this misleading for people comming to D 
first time. D is a mature full featured language by its own. D 
has its roots in C++ (and C) but is full fledged now and should 
represent its features and strength with continuously referencing 
C++ and without this repetitive "without mistakes".

Many young people are looking for alternatives to the boring Java 
Ecosystem. If you position D in the, from there perspective, 
grandparents-language C++ edge, you will miss them.

Regards

Markus
Aug 30 2016
next sibling parent reply Markus <markus orm.ich> writes:
On Tuesday, 30 August 2016 at 07:56:06 UTC, Markus wrote:

 On Monday, 29 August 2016 at 14:31:50 UTC, eugene wrote:

 On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:

[...]



 Hello,
 the url https://dlang.org/overview.html states that "It's a 
 practical language for practical programmers", i think this is 
 the vision statement)))


 Take a look on https://dlang.org/ : "D is a systems programming 
 language with C-like syntax..."

 The overview-page http://dlang.org/overview.html has two main 
 sections which compares D with C++.

 The tour https://tour.dlang.org/ is nearly empty, but on the 
 first page it states that D is an "evolution of C++ (without 
 the mistakes)" (the real content is hidden in the 
 menu-sections).

 Most of the (very good) articles in 
 https://dlang.org/articles.html compare D-features with C++. If 
 I want to learn how D templates work, I do not need to know 
 what is bad in C++-Templates.

 From my point of view this misleading for people comming to D 
 first time. D is a mature full featured language by its own. D 
 has its roots in C++ (and C) but is full fledged now and should 
 represent its features and strength with continuously 
 referencing C++ and without this repetitive "without mistakes".

 Many young people are looking for alternatives to the boring 
 Java Ecosystem. If you position D in the, from there 
 perspective, grandparents-language C++ edge, you will miss them.

 Regards

 Markus


Sorry, two typos, should be read as:
...
D has its roots in C++ (and C) but is full fledged now and should
represent its features and strength WITHOUT continuously
referencing C++ and without this repetitive "without mistakes".
...
 From my point of view this is misleading for people coming to D
first time.
Aug 30 2016
parent reply eugene <egordeev18 gmail.com> writes:
On Tuesday, 30 August 2016 at 08:00:35 UTC, Markus wrote:

 D has its roots in C++ (and C) but is full fledged now and 
 should
 represent its features and strength WITHOUT continuously
 referencing C++ and without this repetitive "without mistakes".
 ...
 From my point of view this is misleading for people coming to D
 first time.


i think it is to invite C\C++ developers to use D instead of what 
they now use. I dont think D currently can supersede neither 
C\C++ nor java, since both sides have a huge amount of libs, 
frameworks as it's a key why they are still highly used, though 
java lacks in speed of evolution and C++ is becoming more complex 
and C lacks abstractions like OOP
Aug 30 2016
parent reply John Burrton <john.burton jbmail.com> writes:
On Tuesday, 30 August 2016 at 08:34:23 UTC, eugene wrote:

 On Tuesday, 30 August 2016 at 08:00:35 UTC, Markus wrote:

 D has its roots in C++ (and C) but is full fledged now and 
 should
 represent its features and strength WITHOUT continuously
 referencing C++ and without this repetitive "without mistakes".
 ...
 From my point of view this is misleading for people coming to D
 first time.


 i think it is to invite C\C++ developers to use D instead of 
 what they now use. I dont think D currently can supersede 
 neither C\C++ nor java, since both sides have a huge amount of 
 libs, frameworks as it's a key why they are still highly used, 
 though java lacks in speed of evolution and C++ is becoming 
 more complex and C lacks abstractions like OOP


One thing that put me off looking a D again for a long time was 
the code example on the front page.

Perhaps like many people, I like C, I liked early C++ as being a 
much better C, but I look at "Modern" C++ with dismay. I liked C 
and early C++ because they were systems programming languages, 
where you could always see and understand the mapping from the 
language to the underlying machine, both for instructions and 
memory usage. Modern C++ has lost this. It's no longer considered 
"best practice" to write code that maps directly to simple 
machine constructs and use libraries when you want something 
"bigger". I look at C++ with dismay now. Everything they added 
works by "magic" or template "tricks" where you have little or no 
idea how the underlying code works or how memory is used without 
going into real depth.


This is why I've looked for a new language and I think D fits 
that quite well. It's not lost the plot like C++ seems to have 
done. it's simple to write and understand, but it has higher 
level constructs when you want them.

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

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

It makes the language look like some weird high level functional 
language where you don't ask how it works and you shouldn't care 
how it maps to the machine instructions and memory.

I realize that the same is actually fairly simple using ranges 
etc.  and have no complaints about the code or having it as a 
sample.
But it reminded me of haskel and functional programming, and 
memory management where it all just works "by magic" and you're 
patted on the head and told not to worry about it.

I feel this is a good example for later on, and I'm in no way 
complaining about the code but a very bad thing for the first 
thing you see on the front page.

I'm willing to admit I might be the only one :P But I'd much 
rather see the "better C" side as my first view of typical D code 
than this.
Aug 30 2016
next sibling parent John Burton <john.burton jbmail.com> writes:
On Tuesday, 30 August 2016 at 10:50:17 UTC, John Burton wrote:

 I'm willing to admit I might be the only one :P But I'd much 
 rather see the "better C" side as my first view of typical D 
 code than this.


And I want to be clear... None of this is a complaint. I just 
wanted to post what personally put me off looking at D again for 
a while as a data point :)
Aug 30 2016
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 30 August 2016 at 10:50:17 UTC, John Burrton wrote:


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

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

 It makes the language look like some weird high level 
 functional language where you don't ask how it works and you 
 shouldn't care how it maps to the machine instructions and 
 memory.


I bet you if you had a C-style example on the front page, people 
would complain that it's old fashioned and not really different 
from C, and they'd ask "Why can't I do things like 
`stdin.byLineCopy.array.sort!((a, b) => ...` in D?".
Aug 30 2016
parent reply John Burton <john.burton jbmail.com> writes:
On Tuesday, 30 August 2016 at 11:17:33 UTC, Chris wrote:

 On Tuesday, 30 August 2016 at 10:50:17 UTC, John Burrton wrote:


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

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

 It makes the language look like some weird high level 
 functional language where you don't ask how it works and you 
 shouldn't care how it maps to the machine instructions and 
 memory.


 I bet you if you had a C-style example on the front page, 
 people would complain that it's old fashioned and not really 
 different from C, and they'd ask "Why can't I do things like 
 `stdin.byLineCopy.array.sort!((a, b) => ...` in D?".


Yeah I know...
As I said not really a complaint ... But it d make me think d was 
too high level a language with too much 'magic' . Other people 
will have different opinions
Aug 30 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 30 August 2016 at 11:29:45 UTC, John Burton wrote:

 As I said not really a complaint ... But it d make me think d 
 was too high level a language with too much 'magic' . Other 
 people will have different opinions


Indeed, I'm not a fan of that example either...

but we could turn this weakness into a strength: have two 
side-by-side implementations and emphasize that the same language 
handles both styles.
Aug 30 2016
next sibling parent reply eugene <egordeev18 gmail.com> writes:
On Tuesday, 30 August 2016 at 13:34:05 UTC, Adam D. Ruppe wrote:

 On Tuesday, 30 August 2016 at 11:29:45 UTC, John Burton wrote:

 As I said not really a complaint ... But it d make me think d 
 was too high level a language with too much 'magic' . Other 
 people will have different opinions


 Indeed, I'm not a fan of that example either...

 but we could turn this weakness into a strength: have two 
 side-by-side implementations and emphasize that the same 
 language handles both styles.


i think it will lead to something like: "Why do they have 
different examples for the same thing?" or "Why there are only 
few different examples to do the same thing? I thought D could 
give me more abilities" and so on)))
Aug 30 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 30 August 2016 at 13:42:21 UTC, eugene wrote:

 i think it will lead to something like: "Why do they have 
 different examples for the same thing?"


<h1>D is multi paradigm:</h1>
<code> C style example </code>
<code> functional style example </code>

<p>With D, your existing expertise carries over from C while 
opening doors to new stuff.</p>

<hr>


<h1>D is whatever</h1>
<code> example reinforces header </code>

<p>Explanation here. <a href="federalnetwork">Would you like to 
know more?</a></p>



that's how I'd do it, the code and surrounding text reinforce 
each other.
Aug 30 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/30/2016 10:04 AM, Adam D. Ruppe wrote:

 <code> C style example </code>
 <code> functional style example </code>


That doesn't sounds like a good idea. -- Andrei
Aug 30 2016
prev sibling parent eugene <egordeev18 gmail.com> writes:
On Tuesday, 30 August 2016 at 13:34:05 UTC, Adam D. Ruppe wrote:

 On Tuesday, 30 August 2016 at 11:29:45 UTC, John Burton wrote:

 As I said not really a complaint ... But it d make me think d 
 was too high level a language with too much 'magic' . Other 
 people will have different opinions


 Indeed, I'm not a fan of that example either...

 but we could turn this weakness into a strength: have two 
 side-by-side implementations and emphasize that the same 
 language handles both styles.


another way is to fulfill the FAQ page with questions and answers 
from the forum so newbies could first read the page before 
thinking and asking what others thought and asked before))) but 
then the FAQ page must reside as a link in the header, e.g. 
between "Learn" and "Documentation" and forum must state: "first 
look at FAQ then ask question" like the way on StackOverflow.com
Aug 30 2016
prev sibling next sibling parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D
Subject: Re: Why D is not popular enough?
References: <fovgxbqlwnpantfwqhlf forum.dlang.org>
 <noqbpd$1121$1 digitalmars.com> <noqdi0$13ob$1 digitalmars.com>
 <mailman.968.1471232459.3131.digitalmars-d puremagic.com>
 <norf57$2mu7$1 digitalmars.com> <gotwqwrklefthzsmzzaa forum.dlang.org>
 <dgaoyxmwzmozqvhkazft forum.dlang.org> <np7v0p$2qgd$1 digitalmars.com>
 <np9soo$295v$1 digitalmars.com> <npcl1d$2vgl$1 digitalmars.com>
 <npet31$2vnh$1 digitalmars.com> <wohfqgwucwtpawzspofc forum.dlang.org>
 <cmkdeeernialawyvunul forum.dlang.org> <rsocrlywlrqwpshweoml forum.dlang.org>
 <lgrsbvxozczvwzhknfnj forum.dlang.org> <tybmypxbzeujhfmbvihl forum.dlang.org>
 <pauycpiwvpnmzguguwhj forum.dlang.org>
In-Reply-To: <pauycpiwvpnmzguguwhj forum.dlang.org>

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

On 08/30/2016 01:50 PM, John Burrton wrote:

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



=20
     stdin
         .byLineCopy
         .array
         .sort!((a, b) =3D> a > b) // descending order
         .each!writeln;
=20
 It makes the language look like some weird high level functional
 language where you don't ask how it works and you shouldn't care how it=



 maps to the machine instructions and memory.


On a related point I think it is important to emphasize that such
pipelines are cool not because they look high-level but also because
with decent inlinining compiler (LDC/GDC) they generate as efficient
code as for hand written C style implementation based on loop.

There are plenty of languages that allow similar kind of high level
programming but it usually comes with considerable overhead, contrary to =
D.

Though this specific is not very good as it requires lot of allocation
by the algorithm used. My favorite short snippet I commonly use when
evangelizing D is splitting stdin by whitespaces:

void main ( )
{
    import std.stdio, std.algorithm, std.uni;

    stdin
        .byLine // note that no byLineCopy is needed here
        .map!(line =3D> line.splitter!isWhite)
        .joiner
        .each!writeln;
}

It is 100% Unicode correct, does not allocate any memory garbage and
does exactly what told to do while being orders of magnitude more
readable than any C style loop version one can come up with.


--SC4mD97WGt8lDvNtqNOU48V8ogQtmCccB--
Aug 30 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/30/2016 06:50 AM, John Burrton wrote:

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

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


Sadly if this doesn't float your boat you're unlikely to enjoy most of 
what D has to offer. -- Andrei
Aug 30 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu 
wrote:

 Sadly if this doesn't float your boat you're unlikely to enjoy 
 most of what D has to offer. -- Andrei


This might be the most wrong statement you have ever said on this 
forum.

D's biggest appeal to me is that it *doesn't* force me to use 
whatever bizarre style is popular this month. It is multiparadigm 
out of the box, and flexible enough to adapt to new paradigms as 
they happen.
Aug 30 2016
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/30/2016 10:19 AM, Adam D. Ruppe wrote:

 On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu wrote:

 Sadly if this doesn't float your boat you're unlikely to enjoy most of
 what D has to offer. -- Andrei


 This might be the most wrong statement you have ever said on this forum.


I'm sure I said much worse! :o) -- Andrei
Aug 30 2016
prev sibling parent reply CRAIG DILLABAUGH <craig.dillabaugh gmail.com> writes:
On Tuesday, 30 August 2016 at 14:19:02 UTC, Adam D. Ruppe wrote:

 On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu 
 wrote:

 Sadly if this doesn't float your boat you're unlikely to enjoy 
 most of what D has to offer. -- Andrei


 This might be the most wrong statement you have ever said on 
 this forum.

 D's biggest appeal to me is that it *doesn't* force me to use 
 whatever bizarre style is popular this month. It is 
 multiparadigm out of the box, and flexible enough to adapt to 
 new paradigms as they happen.


I am going to vote with Adam here.  If memory serves me correctly 
what initially drew me in to the D language was a statement on 
the main page that "D is not a religion".  I think at the time I 
had been doing some work with Java, where everything had to be an 
object. Man, I hate Java for that.

Also, I think saying if you don't like functional programming you 
will miss 'most' of what D has to offer is really selling the 
language short.  After all you can write C or C++ style code in D 
if you want, which may be very attractive to some folks.
Aug 30 2016
parent reply Bienlein <jeti789 web.de> writes:
On Tuesday, 30 August 2016 at 18:36:19 UTC, CRAIG DILLABAUGH 
wrote:

 I am going to vote with Adam here.  If memory serves me 
 correctly what initially drew me in to the D language was a 
 statement on the main page that "D is not a religion".  I think 
 at the time I had been doing some work with Java, where 
 everything had to be an object. Man, I hate Java for that.


Many of the inconsitencies and problems in Java come from basic 
types not being objects. Everything being objects is a great way 
to keep things easy to understand, consistent and clean. It has 
some impact on performance, but a lot can be done here which is 
more than sufficient for application programming. Hot Spot 
runtime code optimization in Java is very effective.


 Also, I think saying if you don't like functional programming 
 you will miss 'most' of what D has to offer is really selling 
 the language short.  After all you can write C or C++ style 
 code in D if you want, which may be very attractive to some 
 folks.


D has a lot to offer with regard to functional programming. It 
has pure functions and true immutable classes (true = also sub 
objects become immutable), which Scala all doesn't have (because 
of restrictions of the JVM). Does D have tail call recursion 
optimization? I don't know, actually. If D had that and pattern 
matching, it would beat Scala with all it's hype by a big leap.
Sep 01 2016
parent reply qznc <qznc web.de> writes:
On Thursday, 1 September 2016 at 08:04:00 UTC, Bienlein wrote:

 D has a lot to offer with regard to functional programming. It 
 has pure functions and true immutable classes (true = also sub 
 objects become immutable), which Scala all doesn't have 
 (because of restrictions of the JVM). Does D have tail call 
 recursion optimization? I don't know, actually. If D had that 
 and pattern matching, it would beat Scala with all it's hype by 
 a big leap.


D does not guarantee tail calls, but the compiler might sometimes 
decide to do it. Functional programmer usually want to guarantee, 
so they don't have to write a loop. The downside of TCO is that 
the stack trace is missing frames, which can be very confusing.

D has no syntax for pattern matching, but some library support:
https://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching
Sep 01 2016
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 1 September 2016 at 12:04:51 UTC, qznc wrote:

 On Thursday, 1 September 2016 at 08:04:00 UTC, Bienlein wrote:

 D has a lot to offer with regard to functional programming. It 
 has pure functions and true immutable classes (true = also sub 
 objects become immutable), which Scala all doesn't have 
 (because of restrictions of the JVM). Does D have tail call 
 recursion optimization? I don't know, actually. If D had that 
 and pattern matching, it would beat Scala with all it's hype 
 by a big leap.


 D does not guarantee tail calls, but the compiler might 
 sometimes decide to do it. Functional programmer usually want 
 to guarantee, so they don't have to write a loop. The downside 
 of TCO is that the stack trace is missing frames, which can be 
 very confusing.


There's a DIP about adding a TCO attribute/pragma:
https://github.com/dlang/DIPs/pull/6

FYI: There's some discussion about it's benefit in comparison to 
functional language D does have loops and it's a lot easier to 
write and read them.
If you want to chime in, please do so at the PR discussion.


 D has no syntax for pattern matching, but some library support:
 https://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching


Yep it's pretty easy to do within library code, if you use an 
object chain you might also want to have a look at castSwitch.

https://dlang.org/phobos/std_algorithm_comparison.html#.castSwitch
Sep 01 2016
parent bachmeier <no spam.net> writes:
On Thursday, 1 September 2016 at 17:10:00 UTC, Seb wrote:


 FYI: There's some discussion about it's benefit in comparison 
 to functional language D does have loops and it's a lot easier 
 to write and read them.


Some are of that opinion. However, this is D, not Python or Go, 
so claims about the one true preference is not a valid argument 
against a particular feature.
Sep 01 2016
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu 
wrote:

 On 08/30/2016 06:50 AM, John Burrton wrote:

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

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


 Sadly if this doesn't float your boat you're unlikely to enjoy 
 most of what D has to offer. -- Andrei


That particular bit of code doesn't really ring "pragmatic", just 
"clever". Honestly the front page examples are just scary.

     // Round floating point numbers
     import std.algorithm, std.conv, std.functional,
            std.math, std.regex, std.stdio;

     alias round = pipe!(to!real, std.math.round, to!string);
     static reFloatingPoint = ctRegex!`[0-9]+\.[0-9]+`;

     void main()
     {
         // Replace anything that looks like a real
         // number with the rounded equivalent.
         stdin
             .byLine
             .map!(l => l.replaceAll!(c => c.hit.round)
                                     (reFloatingPoint))
             .each!writeln;
     }

A clever and impractical piece of program that is hard to read 
for most programmers.
Aug 30 2016
prev sibling parent John Burton <john.burton jbmail.com> writes:
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu 
wrote:

 On 08/30/2016 06:50 AM, John Burrton wrote:

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

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


 Sadly if this doesn't float your boat you're unlikely to enjoy 
 most of what D has to offer. -- Andrei


I tried hard not to be misunderstood.

My problem isn't with this *code*. I think the fact that you can 
do this in D and it's still in general likely to be close or 
equal to the efficiency of a handwritten loop is awesome and a 
great reason to use the language. I WANT to write code like this.

This is a problem with my perception. That such code was 
necessarily going to be slow and bloated compared with C loops. 
Which of course isn't true in D but I've seen that promise so 
many times before that I took a look and thought, nice... but not 
the language I want.

I wonder how many other people did the same.

Anyway I'll shut up now, I don't want any of this to sound like a 
criticism. If anything it was my mistake, but one that the 
example lead me to, wrongly :)
Aug 30 2016
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 30 August 2016 at 07:56:06 UTC, Markus wrote:


 Most of the (very good) articles in 
 https://dlang.org/articles.html compare D-features with C++. If 
 I want to learn how D templates work, I do not need to know 
 what is bad in C++-Templates.


True. Any C++ programmer interested in this topic will see the 
differences anyway (or refer them to the section "D for C++ 
programmers").


 From my point of view this misleading for people comming to D 
 first time. D is a mature full featured language by its own. D 
 has its roots in C++ (and C) but is full fledged now and should 
 represent its features and strength with continuously 
 referencing C++ and without this repetitive "without mistakes".


The D community always links D to C++, which makes D look like 
the eternal "wanna be" or "runner-up". D has developed its own 
"style" and should no longer be compared to C++ feature by 
feature. It's useless because it's no longer applicable.


 Many young people are looking for alternatives to the boring 
 Java Ecosystem. If you position D in the, from there 
 perspective, grandparents-language C++ edge, you will miss them.


You have a point there. It's been said time and again that trying 
to win over the C++ crowd (that has put years of work into 
mastering the language) will not generate many new D users (the 
odd one, alright). But D can attract users from Python and Java 
etc. It's time D became a bit more self-confident about its own 
achievements. It'd make more sense to compare D, in terms of 
outlook, features and solutions, to other newer languages like 
Nim, Go or Swift, because those new languages are the real 
competition, that's where people go when they look for new 
languages once they're unhappy with Java or Python or whatever.

The constant references to C++ are understandable, though, if you 
consider that both Walter and Andrei come from a C++ background, 
so the whole issue of C++ may loom larger in their minds than in 
yours or mine.
Aug 30 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 3:42 AM, Chris wrote:

 [...]


I agree it's time to remove comparisons with C++, although there is room for a 
"D for C++ Programmers" section and, of course, "Interfacing D to C++".
Aug 30 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 11:22 AM, Walter Bright wrote:

 On 8/30/2016 3:42 AM, Chris wrote:

 [...]


 I agree it's time to remove comparisons with C++, although there is room for a
 "D for C++ Programmers" section and, of course, "Interfacing D to C++".



https://github.com/dlang/dlang.org/pull/1459
Aug 30 2016
prev sibling parent Chris <wendlec tcd.ie> writes:
On Tuesday, 30 August 2016 at 18:22:59 UTC, Walter Bright wrote:

 On 8/30/2016 3:42 AM, Chris wrote:

 [...]


 I agree it's time to remove comparisons with C++, although 
 there is room for a "D for C++ Programmers" section and, of 
 course, "Interfacing D to C++".


I think this will do D good in the long run.
Aug 31 2016
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/30/2016 03:56 AM, Markus wrote:

 On Monday, 29 August 2016 at 14:31:50 UTC, eugene wrote:

 On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:

 Take a look on this discussion thread and you know WHY D IS NOT SO
 POPULAR.

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



 Hello,
 the url https://dlang.org/overview.html states that "It's a practical
 language for practical programmers", i think this is the vision
 statement)))


 Take a look on https://dlang.org/ : "D is a systems programming language
 with C-like syntax..."

 The overview-page http://dlang.org/overview.html has two main sections
 which compares D with C++.


I think we'd do good to avoid explicit comparison with specific 
languages, within reason. Focusing on what makes D unique and 
interesting across _all_ languages on the landscape is a much more 
fertile approach.


Andrei
Aug 30 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 12:56 AM, Markus wrote:

 The tour https://tour.dlang.org/ is nearly empty, but on the first page it
 states that D is an "evolution of C++ (without the mistakes)" (the real content
 is hidden in the menu-sections).


I was going to fix that, but can't find where it is on github. The "Open
Source" 
links to https://github.com/stonemaster/dlang-tour, but it isn't there.
Aug 30 2016
parent reply mate <aiueo aiueo.aiueo> writes:
On Tuesday, 30 August 2016 at 20:25:42 UTC, Walter Bright wrote:

 On 8/30/2016 12:56 AM, Markus wrote:

 The tour https://tour.dlang.org/ is nearly empty, but on the 
 first page it
 states that D is an "evolution of C++ (without the mistakes)" 
 (the real content
 is hidden in the menu-sections).


 I was going to fix that, but can't find where it is on github. 
 The "Open Source" links to 
 https://github.com/stonemaster/dlang-tour, but it isn't there.


Found it here:
https://github.com/dlang-tour/english/blob/master/welcome/welcome-to-d.md

But it has many offspring to be updated as well:
https://github.com/dlang-tour/japanese/blob/master/welcome/welcome-to-d.md
https://github.com/dlang-tour/german/blob/master/welcome/welcome-to-d.md
https://github.com/dlang-tour/chinese/blob/master/welcome/welcome-to-d.md
https://github.com/dlang-tour/italian/blob/master/welcome/welcome-to-d.md
https://github.com/dlang-tour/spanish/blob/master/welcome/welcome-to-d.md
https://github.com/dlang-tour/turkish/blob/master/welcome/welcome-to-d.md
https://github.com/dlang-tour/romanian/blob/master/welcome/welcome-to-d.md
https://github.com/dlang-tour/french/blob/master/welcome/welcome-to-d.md
https://github.com/dlang-tour/swedish/blob/master/welcome/welcome-to-d.md
Aug 30 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 2:41 PM, mate wrote:

 On Tuesday, 30 August 2016 at 20:25:42 UTC, Walter Bright wrote:

 On 8/30/2016 12:56 AM, Markus wrote:

 The tour https://tour.dlang.org/ is nearly empty, but on the first page it
 states that D is an "evolution of C++ (without the mistakes)" (the real content
 is hidden in the menu-sections).


 I was going to fix that, but can't find where it is on github. The "Open
 Source" links to https://github.com/stonemaster/dlang-tour, but it isn't there.


 Found it here:
 https://github.com/dlang-tour/english/blob/master/welcome/welcome-to-d.md


Oh, I see the problem. I was looking at:

https://github.com/stonemaster/dlang-tour

when I should have looked at:

https://github.com/dlang-tour

Looks like the link at https://tour.dlang.org/ needs fixing?
Aug 30 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 2:41 PM, mate wrote:

 On Tuesday, 30 August 2016 at 20:25:42 UTC, Walter Bright wrote:

 On 8/30/2016 12:56 AM, Markus wrote:

 The tour https://tour.dlang.org/ is nearly empty, but on the first page it
 states that D is an "evolution of C++ (without the mistakes)" (the real content
 is hidden in the menu-sections).


 I was going to fix that, but can't find where it is on github. The "Open
 Source" links to https://github.com/stonemaster/dlang-tour, but it isn't there.


 Found it here:
 https://github.com/dlang-tour/english/blob/master/welcome/welcome-to-d.md

 But it has many offspring to be updated as well:
 https://github.com/dlang-tour/japanese/blob/master/welcome/welcome-to-d.md
 https://github.com/dlang-tour/german/blob/master/welcome/welcome-to-d.md
 https://github.com/dlang-tour/chinese/blob/master/welcome/welcome-to-d.md
 https://github.com/dlang-tour/italian/blob/master/welcome/welcome-to-d.md
 https://github.com/dlang-tour/spanish/blob/master/welcome/welcome-to-d.md
 https://github.com/dlang-tour/turkish/blob/master/welcome/welcome-to-d.md
 https://github.com/dlang-tour/romanian/blob/master/welcome/welcome-to-d.md
 https://github.com/dlang-tour/french/blob/master/welcome/welcome-to-d.md
 https://github.com/dlang-tour/swedish/blob/master/welcome/welcome-to-d.md


Thanks for your help!

https://github.com/dlang-tour/english/pull/91
Aug 30 2016
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Wednesday, 31 August 2016 at 01:12:10 UTC, Walter Bright wrote:

 On 8/30/2016 2:41 PM, mate wrote:

[...]


 Thanks for your help!

 https://github.com/dlang-tour/english/pull/91


Your change just went live
http://tour.dlang.org ;)
Aug 30 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/30/2016 6:30 PM, ZombineDev wrote:

 Your change just went live
 http://tour.dlang.org ;)


Thanks! Note that the other languages need updating, too.
Aug 30 2016
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 31 August 2016 at 04:03:32 UTC, Walter Bright wrote:

 On 8/30/2016 6:30 PM, ZombineDev wrote:

 Your change just went live
 http://tour.dlang.org ;)


 Thanks! Note that the other languages need updating, too.


Done (FYI the translations aren't officially published yet) ;-)
Aug 31 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2016 2:17 AM, Seb wrote:

 Done (FYI the translations aren't officially published yet) ;-)


Danke schoen!
Aug 31 2016
prev sibling parent John Smith <gyroheli gmail.com> writes:
On Friday, 19 August 2016 at 02:59:40 UTC, Adam D. Ruppe wrote:

 On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:

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


 std.range is one of the libraries that has never used the GC 
 much. Only tiny parts of it ever have,

 Moreover, dynamic arrays do not necessarily have to be GC'd. 
 Heck, you can even malloc them if you want to 
 (`(cast(int*)malloc(int.sizeof))[0 .. 1]` gives an int[] of 
 length 1).

 This has been a common misconception lately... :(



Never really said that was the case. The restriction was caused 
for the need to be able to change the length of the array. Which 
you can't do: (cast(int*)malloc(int.sizeof))[0 .. 1].length = 0. 
If that wasn't std.range then it was something else, it's been a 
while since I used it.
Aug 21 2016
prev sibling next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 18 Aug 2016 22:50:27 +0000
schrieb John Smith <gyroheli gmail.com>:


 Well you could say the same for the same for int. Why isn't "int 
 + int = long"? Right now it is following the rule "int + int = 
 int".


I believe in C, int reflects the native machine word that the
CPU always uses to perform arithmetics. Together with
undefined overflow behavior (due to allowing different HW
implementations) of signed types I suppose it was the best bet
to at least widen smaller types to that type.

Even on today's amd64 CPUs int/uint remain the most efficient
integral type for multiplication and division.

If we hypothetically switched to a ubyte+ubyte=ubyte semantic,
then code like this breaks silently:

ubyte a = 210;
ubyte b = 244;
float f = 1.1 * (a + b);

Or otherwise instead of casting uints to ubytes you now start
casting ubytes to uints all over the place. What we have is
the guarantee that the result will reliably be at least 32-bit
in D.

-- 
Marco
Aug 19 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote:

 If we hypothetically switched to a ubyte+ubyte=ubyte semantic, 
 then code like this breaks silently:


However, if it took the entire statement into account, it could 
handle that... by my rule, it would see there's a float in there 
and thus automatically cast a and b to float before doing 
anything.

The compiler would parse

Assign(float, Multiply(float, Parenthetical(Add(a, b))))

In a semantic transformation step, it would see that since the 
lhs is float, the rhs is now casted to float, then it does that 
recursively through it all and a and b get promoted to float so 
the bits are never lost.

I really do think that would work.


Alas, I don't see D ever changing anyway, this is too deep in its 
C bones.
Aug 19 2016
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 19 Aug 2016 13:36:05 +0000
schrieb Adam D. Ruppe <destructionator gmail.com>:


 On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote:

 If we hypothetically switched to a ubyte+ubyte=ubyte semantic, 
 then code like this breaks silently:  


 
 However, if it took the entire statement into account, it could 
 handle that... by my rule, it would see there's a float in there 
 and thus automatically cast a and b to float before doing 
 anything.


Float math is slow compared to integer math and precision loss
occurs when this rule is also applied to (u)int and (u)long
with only the deprecated (as per amd64 spec) real type being
large enough for 64-bit integers.

-- 
Marco
Aug 19 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 19 August 2016 at 15:01:58 UTC, Marco Leise wrote:

 Float math is slow compared to integer math and precision loss
 occurs when this rule is also applied to (u)int and (u)long
 with only the deprecated (as per amd64 spec) real type being
 large enough for 64-bit integers.


You're working with float anyway, so I believe the price is paid 
even by today's C rules.

The intermediates might be different though, I'm not sure.
Aug 19 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/19/2016 8:19 AM, Adam D. Ruppe wrote:

 You're working with float anyway, so I believe the price is paid even by
today's
 C rules.


Nope, the operands of integral sub-expressions are not promoted to float.


 The intermediates might be different though, I'm not sure.
Aug 19 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 19 August 2016 at 15:01:58 UTC, Marco Leise wrote:

 Am Fri, 19 Aug 2016 13:36:05 +0000
 schrieb Adam D. Ruppe <destructionator gmail.com>:


 On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote:

 If we hypothetically switched to a ubyte+ubyte=ubyte 
 semantic, then code like this breaks silently:


 
 However, if it took the entire statement into account, it 
 could handle that... by my rule, it would see there's a float 
 in there and thus automatically cast a and b to float before 
 doing anything.


 Float math is slow compared to integer math and precision loss
 occurs when this rule is also applied to (u)int and (u)long
 with only the deprecated (as per amd64 spec) real type being
 large enough for 64-bit integers.


Try multiplications and divisions.
Sep 01 2016
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 August 2016 at 00:50, John Smith via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Well there are some things I feel could be improved, a lot of the things are
 really just minor but what is a deal breaker for me mostly is the compilers.
 The GCC and Clang implementations are really far behind in terms of the
 version, so they are missing a lot of features. A lot of the features that
 I'd want to use D for.


This is a constant vicious cycle.  Sometimes I wonder of how better it
would be for all if D was instead defined by a spec, not an
implementation that adds small feature changes in an ad hoc manner as
it sees fit.
Aug 20 2016
prev sibling parent Shachar Shemesh <shachar weka.io> writes:
On 14/08/16 21:35, Andrei Alexandrescu wrote:

 I should add that as long as the .di does not import the .d, the
 slowdown due to the computed table will not occur. So the worry is not
 warranted.


I'm not sure the above is true in cases of imports that are not circular 
for the optimal dis, but are circular when flattened. Then again, but 
I'm not close enough to the issue to say for sure.

Shachar
Aug 14 2016
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/14/2016 11:03 AM, Shachar Shemesh wrote:

 Which rule?


 The rule that says "ubyte + ubyte = uint".


Many people are surprised by this rule, but it is deeply embedded in C and C++.

In C99,

-------------------------------
6.3.1.8 Usual Arithmetic Conversions

Then the following rules are applied to the promoted operands:

If both operands have the same type, then no further conversion is needed.

Otherwise, if both operands have signed integer types or both have unsigned
integer types, the operand with the type of lesser integer conversion rank is
converted to the type of the operand with greater rank.

Otherwise, if the operand that has unsigned integer type has rank greater or
equal to the rank of the type of the other operand, then the operand with
signed integer type is converted to the type of the operand with unsigned
integer type.

Otherwise, if the type of the operand with signed integer type can represent
all of the values of the type of the operand with unsigned integer type, then
the operand with unsigned integer type is converted to the type of the
operand with signed integer type.

Otherwise, both operands are converted to the unsigned integer type
corresponding to the type of the operand with signed integer type.
--------------------------------------------

This rule was retained for D to make it easier to translate code from C/C++ to 
D. Changing the rule could result in subtle and invisible bugs for such 
translations and for C/C++ programmers who are so used to the integral
promotion 
rules that they aren't even really aware of reliance upon them.

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

     byte = byte + byte;

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

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

     byte = cast(byte)(byte + byte);

where the user presumably knows what he's doing.
Aug 14 2016
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 14 August 2016 at 18:03:24 UTC, Shachar Shemesh wrote:

 

 I must confess that I have never heard of this rule in C 
 before encountering it in D.


 
 Which rule?


 The rule that says "ubyte + ubyte = uint".


https://www.google.fr/search?q=C+int+promotion+rules&ie=utf-8&oe=utf-8&client=firefox-b&gfe_rd=cr&ei=xaOxV5vuMpGx8weWtIawAw#q=c+int+promotion+rules+standard

This is so central to understanding the C language that I'm 
surprized here. There's no forum, FAQ that doesn't mention it.
Aug 15 2016
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 08/14/2016 07:07 AM, Andrei Alexandrescu wrote:

 On 08/14/2016 01:18 AM, Shachar Shemesh wrote:



 Also, part of our
 problems with this is that introspection also does not see refs, which
 causes the following two functions to report the same signature:

 void func1(int arg);
 void func2(ref int arg);


 I actually think you can do introspection on any argument to figure
 whether it has "ref".


Yes, it exists. However, I tried std.traits.Parameters but that wasn't 
it. A colleague reminded us that it's std.traits.ParameterStorageClassTuple:

   http://dlang.org/phobos/std_traits.html#ParameterStorageClassTuple

Ali
Aug 15 2016
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 15 Aug 2016 10:54:11 -0700
schrieb Ali =C3=87ehreli <acehreli yahoo.com>:


 On 08/14/2016 07:07 AM, Andrei Alexandrescu wrote:
  > On 08/14/2016 01:18 AM, Shachar Shemesh wrote: =20
=20
  >> Also, part of our
  >> problems with this is that introspection also does not see refs, which
  >> causes the following two functions to report the same signature:
  >>
  >> void func1(int arg);
  >> void func2(ref int arg); =20
  >
  > I actually think you can do introspection on any argument to figure
  > whether it has "ref". =20
=20
 Yes, it exists. However, I tried std.traits.Parameters but that wasn't=20
 it. A colleague reminded us that it's std.traits.ParameterStorageClassTup=


le:

=20
    http://dlang.org/phobos/std_traits.html#ParameterStorageClassTuple
=20
 Ali
=20


In fact, std.traits.Parameters _retains_ ref as long as you
don't unpack the tuple:

void foo(ref int);
void bar(Parameters!foo args);=20

'bar' is now "void function(ref int)"

You can then access 'args.length' and 'args[n]' to get at each
argument or pass 'args' on as is to the next function.

You can also create a ref argument for 'T' out of thin air by
writing:

alias RefArg =3D Parameters!((ref T) {});

Just remember that 'RefArg' is again a tuple and you
always need to access args[0] to use it.

--=20
Marco
Aug 19 2016
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
On Sun, 14 Aug 2016 08:18:08 +0300, Shachar Shemesh wrote:

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


I can often put const on things. However, it's an added step, the 
compiler doesn't prompt me, and I can't add it everywhere. The result is 
that I make things const-correct about 2% of the time.

If function parameters were const by default, that would prompt me to try 
to make my code const-correct. If there were a module-level annotation I 
could use to turn on const-by-default, I would use it.
Aug 14 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Friday, 12 August 2016 at 22:58:45 UTC, Steven Schveighoffer 
wrote:

 It's broken because it's inconsistent. If the compiler is going 
 to complain about races in one case, but not in other 
 equivalent cases, then the feature is useless.


If anything, it guarantee you that this kind of things will NEVER 
happen if not shared, which is in itself a huge benefit.


 If all I have to do to avoid compiler complaints is rewrite my 
 expression in an equivalent way, then what is the point of the 
 complaint? At that point, it's just a style guide.


The ways are equivalent only in the absence of race condition on 
a. This is not guaranteed for shared.
Aug 13 2016
prev sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 12 August 2016 at 18:04:53 UTC, Andrei Alexandrescu 
wrote:

 On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:

 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 Honestly, I don't think that shared is broken.


 Yes. It is broken.

 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)


 How is this broken and how should it behave? -- Andrei


The problem is no one knows if it's broken or not because there 
is no official documentation saying what shared is supposed to do.

This is all we get

"The shared attribute modifies the type from T to shared(T), the 
same way as const does."

https://dlang.org/spec/attribute.html
Aug 14 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, August 12, 2016 13:21:10 Steven Schveighoffer via Digitalmars-d 
wrote:

 On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

 Honestly, I don't think that shared is broken.


 Yes. It is broken.

 shared int x;
 ++x; // error, must use atomicOp.
 x = x + 1; // OK(!)

 The thing that is NOT broken is unshared.

 There's literally not much you can do with shared, and what you can do
 isn't consistent or useful.

 It needs lots of attention.


It does not surprise me in the least if there are bugs related to shared in
the compiler, and we definitely don't deal with it properly in druntime with
regards to stuff like Mutex and Condition. But I don't agree with the idea
that shared is fundamentally broken.

- Jonathan M Davis
Aug 12 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2016 11:34 AM, Jonathan M Davis via Digitalmars-d wrote:

 It does not surprise me in the least if there are bugs related to shared in
 the compiler, and we definitely don't deal with it properly in druntime with
 regards to stuff like Mutex and Condition. But I don't agree with the idea
 that shared is fundamentally broken.


I'd put it more as being largely unimplemented. However, it still works as 
separating by type data that is shared vs data that is local, and that is still 
immensely valuable.

Also, one thing at a time. Scope has been largely unimplemented forever, and 
this DIP intends to fix that.
Aug 12 2016
prev sibling next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Fri, 12 Aug 2016 09:38:13 +0000, Guillaume Piolat wrote:

  From the best of my knowledge you cannot do these things in in
 C++:

 https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-


through-CTFE

You can use an external tool at build time to do this, but it's awkward. 
(DMD, when it was C++-based, used that technique to generate a few 
things.)


 https://p0nce.github.io/d-idioms/#Embed-a-dynamic-library-in-an-


executable

You need a resources script for it with MSVC++. If you're building an ELF 
executable, you can use `objcopy(1)` to convert a data file into an 
object file containing static data.

Which is, I feel, the story of life using D vs C++. You can get it done 
in C++, but it might take some external tools, it's going to be awkward, 
and it's going to be different on every platform.
Aug 12 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 12/08/16 12:38, Guillaume Piolat wrote:

 From the best of my knowledge you cannot do these things in in C++:

 https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE


I maintain an open source program called fakeroot-ng. It is written in 
C++. Just today, while doing some cleanups, I ran across this point when 
trying to convert a table to const.

So, yes, having a CTFE to compute the table would have been great, and 
had fakeroot-ng been written in D, I would have. Then again, the 
ultimate cost of not doing this is so low, that I didn't really feel 
cheated out of it.

That table was not expensive to compute, and its constantness wasn't 
crucial enough even for me to put a wrapper pointer and only access it 
through it. Had that not been the case, and had that table been more 
expensive to computer, I'd probably compute at compile time with an 
external tool.

The point is that while I missed have D's CTFE to compute that table, I 
didn't miss it much, and I don't miss D features often. Sadly, I cannot 
say the same thing about the things in C++ I miss when I write D. They 
are both everyday and, to me, without reasonable substitutes.

Shachar
Aug 12 2016
next sibling parent reply =?UTF-8?B?bcO5c2Rs?= <mdsdl msdl.fr> writes:
On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:

 I cannot say the same thing about the things in C++ I miss when 
 I write D.


Be constructive and enumerate them.
Aug 12 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 12/08/16 17:50, mùsdl wrote:

 On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:

 I cannot say the same thing about the things in C++ I miss when I
 write D.


 Be constructive and enumerate them.


I'll give some highlights, but those are, mostly, things that I've 
already listed in this forum and in my lightening talk.

- No RAII support, despite the fact everybody here seems to think that D 
supports RAII.
- Recursive const makes many cases where I can use const in C++ (and 
enjoy the protection it provides) simply mutable in D.
- This one I have not complained about yet. Operator overloads stepping 
on each other's toes. In my case, I have a container (with opIndex that 
accepts a custom type and opOpAssign!"~") and I place in it a struct 
with some operator overloads as well (have not reduced the cause yet, 
hence no previous complaint about this one). So, when I write

Container[IndexType] ~= Type;

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

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

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

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

- GC. GC. GC. Some more GC.
- Integral type operations promotion and the constant need for casts.
- No warning for signed/unsigned comparisons. An unfailing source for bugs.
- No ref type.

These are just off the top of my head. There are more. Like I said, my 
frustrations with D are daily.

Shachar
Aug 12 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2016 12:29 PM, Shachar Shemesh wrote:

 - No RAII support, despite the fact everybody here seems to think that D
 supports RAII.


Please explain.


 - Recursive const makes many cases where I can use const in C++ (and enjoy the
 protection it provides) simply mutable in D.


Right, in C++ you can have a const pointer to mutable. On the other hand, in
C++ 
you cannot have 'const T' apply to what is accessible through T.


 - This one I have not complained about yet. Operator overloads stepping on each
 other's toes. In my case, I have a container (with opIndex that accepts a
custom
 type and opOpAssign!"~") and I place in it a struct with some operator
overloads
 as well (have not reduced the cause yet, hence no previous complaint about this
 one). So, when I write

 Container[IndexType] ~= Type;

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

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

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

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

 - GC. GC. GC. Some more GC.
 - Integral type operations promotion and the constant need for casts.


I don't understand this. Integral type promotions are the same as in C++. The 
casts are needed for integral type demotions (i.e. narrowing conversions). 
Having implicit narrowing conversions in C++ is a significant source of bugs,
as 
the most significant bits are silently discarded.


 - No warning for signed/unsigned comparisons. An unfailing source for bugs.


Understood, but to be pedantic, such warnings are extensions to C++ compilers, 
not part of the language.


 - No ref type.


D has the ref storage class. What difference are you seeing?
Aug 12 2016
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote:

 - Recursive const makes many cases where I can use const in C++ 
 (and enjoy the protection it provides) simply mutable in D.


FWIW HeadConst can be easily done in a library and will hopefully 
soon be in Phobos.

https://github.com/dlang/phobos/pull/3862

Note that the reverse of having a easy to use recursive const in 
library code of C++ is not true.
Aug 12 2016
prev sibling parent reply Vadim Lopatin <coolreader.org gmail.com> writes:
On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote:

 I'll give some highlights, but those are, mostly, things that 
 I've already listed in this forum and in my lightening talk.

 - No RAII support, despite the fact everybody here seems to 
 think that D supports RAII.
 Shachar


There IS RAII in D.
I'm using it in DlangUI extensively for managing resources.
Aug 21 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 22/08/16 09:31, Vadim Lopatin wrote:

 On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote:

 I'll give some highlights, but those are, mostly, things that I've
 already listed in this forum and in my lightening talk.

 - No RAII support, despite the fact everybody here seems to think that
 D supports RAII.
 Shachar


 There IS RAII in D.
 I'm using it in DlangUI extensively for managing resources.


Then, depending on your precise use, you might have leaks.

Shachar
Aug 22 2016
parent Vadim Lopatin <coolreader.org gmail.com> writes:
On Monday, 22 August 2016 at 07:05:01 UTC, Shachar Shemesh wrote:

 On 22/08/16 09:31, Vadim Lopatin wrote:

 On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh

 - No RAII support, despite the fact everybody here seems to 
 think that
 D supports RAII.
 Shachar


 There IS RAII in D.
 I'm using it in DlangUI extensively for managing resources.


 Then, depending on your precise use, you might have leaks.


To avoid leaks, it's necessary to prevent destructor calling from 
GC for objects which hold resources - they have to be called 
manually via destroy() or by some RAII technique.
I'm using Reference Counting.
Aug 22 2016
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:

 So, yes, having a CTFE to compute the table would have been 
 great, and had fakeroot-ng been written in D, I would have. 
 Then again, the ultimate cost of not doing this is so low, that 
 I didn't really feel cheated out of it.


I was just giving examples of things that aren't possible in C++, 
or are possible but less easy, require external programs, require 
incredible macros...

If it's not easy it's as if it doesn't exist.
Aug 12 2016
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:

 That table was not expensive to compute, and its constantness 
 wasn't crucial enough even for me to put a wrapper pointer and 
 only access it through it. Had that not been the case, and had 
 that table been more expensive to computer, I'd probably 
 compute at compile time with an external tool.

 Shachar


And you are forgetting about composability. If I can compute a 
table at compile-time this means I can go higher on the 
abstraction ladder.


void interpFast(string expr)(float x)
{
     // here a look-up computed at compile-time
     static immutable table = makeTable!exp(0, 100, 0.1f);
     int ipart = cast(int)x;
     int fpart = x - ipart;
     return linInterp(table[ipart], table[ipart+1], fpart);
}

void main()
{
    // automatically tabulated
    float x = interpFast!"pow(cos(x) + 4, x)"(0.5f);
}


Not only is this impossible in C++, but being cumbersome it means 
that people won't do it and loose optimization opportunities.
Aug 12 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2016 7:41 AM, Shachar Shemesh wrote:

 That table was not expensive to compute, and its constantness wasn't crucial
 enough even for me to put a wrapper pointer and only access it through it. Had
 that not been the case, and had that table been more expensive to computer, I'd
 probably compute at compile time with an external tool.


What I do (and is done in building DMD) is write a program (optabgen.c) to 
generate the tables and write a C++ source file, then compile the generated
file 
into DMD.
Aug 12 2016
parent reply Shachar Shemesh <shachar weka.io> writes:
On 12/08/16 22:07, Walter Bright wrote:

 On 8/12/2016 7:41 AM, Shachar Shemesh wrote:

 That table was not expensive to compute, and its constantness wasn't
 crucial
 enough even for me to put a wrapper pointer and only access it through
 it. Had
 that not been the case, and had that table been more expensive to
 computer, I'd
 probably compute at compile time with an external tool.


 What I do (and is done in building DMD) is write a program (optabgen.c)
 to generate the tables and write a C++ source file, then compile the
 generated file into DMD.


Yes, I'm sorry. I meant to say "build time" instead of "compile time". 
That is precisely what I meant.

Shachar
Aug 12 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2016 12:14 PM, Shachar Shemesh wrote:

 On 12/08/16 22:07, Walter Bright wrote:

 On 8/12/2016 7:41 AM, Shachar Shemesh wrote:

 That table was not expensive to compute, and its constantness wasn't
 crucial
 enough even for me to put a wrapper pointer and only access it through
 it. Had
 that not been the case, and had that table been more expensive to
 computer, I'd
 probably compute at compile time with an external tool.


 What I do (and is done in building DMD) is write a program (optabgen.c)
 to generate the tables and write a C++ source file, then compile the
 generated file into DMD.


 Yes, I'm sorry. I meant to say "build time" instead of "compile time". That is
 precisely what I meant.


I'm surprised that I've never seen anyone else use such a technique. It's so 
unusual I've seen it be unrepresentable in some 'make' replacements.

I suppose it's like unittest and ddoc. Sure, you can do it with some
contortions 
and/or some external tooling, but having it conveniently built in to the 
language changes everything.
Aug 12 2016
next sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 12/08/16 22:55, Walter Bright wrote:

 
 I'm surprised that I've never seen anyone else use such a technique.
 It's so unusual I've seen it be unrepresentable in some 'make'
 replacements.
 
 I suppose it's like unittest and ddoc. Sure, you can do it with some
 contortions and/or some external tooling, but having it conveniently
 built in to the language changes everything.
 


Actually, even with it being easilly accessible in the compiler, there
are sometimes reasons to still do it with an external tool.

My next task at work requires precomputing a table. This might prove to
be a quite intensive task, and the result will change quite rarely.
Under those circumstances, I believe I will not wish to compute it each
time the system is compiled, but to compute it when it changes and use a
cached version.

This means I still need a build rule for it, which means that if the
build system does not support it, sucks to be me.

Shachar
Aug 12 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 04:06 PM, Shachar Shemesh wrote:

 On 12/08/16 22:55, Walter Bright wrote:

 I'm surprised that I've never seen anyone else use such a technique.
 It's so unusual I've seen it be unrepresentable in some 'make'
 replacements.

 I suppose it's like unittest and ddoc. Sure, you can do it with some
 contortions and/or some external tooling, but having it conveniently
 built in to the language changes everything.


 Actually, even with it being easilly accessible in the compiler, there
 are sometimes reasons to still do it with an external tool.

 My next task at work requires precomputing a table. This might prove to
 be a quite intensive task, and the result will change quite rarely.
 Under those circumstances, I believe I will not wish to compute it each
 time the system is compiled, but to compute it when it changes and use a
 cached version.


I wonder if you can arrange things such that a compile-time table is 
computed only upon a change in the source file. I mean:

// table.di
extern double[] table;

// table.d
double[] table = makeComplicatedTable();

double[1024] makeComplicatedTable() {
    ... compile-time computation ...
}

People use the interface file table.di. The complicated computation goes 
in table.o which is generated only when table.d is changed.


Andrei
Aug 12 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 03:55 PM, Walter Bright wrote:

 On 8/12/2016 12:14 PM, Shachar Shemesh wrote:

 On 12/08/16 22:07, Walter Bright wrote:

 On 8/12/2016 7:41 AM, Shachar Shemesh wrote:

 That table was not expensive to compute, and its constantness wasn't
 crucial
 enough even for me to put a wrapper pointer and only access it through
 it. Had
 that not been the case, and had that table been more expensive to
 computer, I'd
 probably compute at compile time with an external tool.


 What I do (and is done in building DMD) is write a program (optabgen.c)
 to generate the tables and write a C++ source file, then compile the
 generated file into DMD.


 Yes, I'm sorry. I meant to say "build time" instead of "compile time".
 That is
 precisely what I meant.


 I'm surprised that I've never seen anyone else use such a technique.


It's a matter of frequenting the appropriate circles. The technique is 
in wide use.

Andrei
Aug 12 2016
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote:

 I am a C++ expert who has looked at D in the past. Perhaps my 
 reasons for not programming in D may be taken as some of the 
 reasons why D "is not popular enough". My opinions are not 
 meant to start a flame war, even if some of my insights may be 
 harsh to those who do use D. They will hopefully give some idea 
 of why and where D went wrong in trying to appeal to the 
 general intelligent programmer as a programming language.

 1) Until very recently the documentation for D has been very 
 substandard. I do notice better documentation both on the web 
 site now and a few more books on D as a programming language. 
 For a very long time after D was created, even after version 2 
 was created, there was essentially no decent documentation at 
 all. If you are trying to promote the use of a computer 
 language to the general public you must create first-rate 
 documentation and explanation of your computer language from 
 the very beginning. Without this first-rate documentation your 
 programming language, no matter how good it might be, is just a 
 toy to those who want to play around with it and try it out. 
 This is the case that D promoted for a very long time, so the 
 expectation that D was going to become popular to the 
 programming public with such poor documentation was just 
 foolish. C took off as a programming language for the general 
 programming when Kernigan and Ritchie wrote their classic book 
 and C++ took off as a programming language for the general 
 public when Stroustrop and subsequently Lippman wrote their 
 classuc books. While I think that Alexandrescu's book is decent 
 it is not written at the level of these others.


I never got that point, really. When I started to program in D 
around 2010, documentation for D was almost non existent, but I 
quickly learned how to use it by just, well, using it. 
Programming languages have a lot of things in common, once you 
know one (or two) others are not so hard to learn/understand/use. 
If you come from a C++ background, understanding D should be a 
piece of cake.


 2) While I greatly respect the programming abilities of Mr. 
 Bright and Mr. Alexandrescu and their hard work in creating and 
 improving D, having followed both from the C++ world, the 
 arrogance by which D was initially and repeatedly compared 
 against C/C++ has been totally out of place since the 
 beginning. C++ is a very good language and the effort made to 
 denigrate it with specious and ridiculously false arguments 
 about it vis-a-vis D as a programming language has almost 
 irreparably hurt D as a serious programming language 
 irrespective of its actual abilities or weaknesses. You are not 
 going to appeal to the really intelligent programmers out there 
 if you are not honest and rigorous in discussion of your own 
 programming language in relation to others. All that you end up 
 doing is to alienate anyone with real programming intelligence 
 by the tactics that D has taken over the years with such 
 comparisons.


Cf. Patrick's comment. Let me add this: by constantly mentioning 
`intelligent programmers` you insinuate that people who use D are 
idiots who religiously worship the language. Anything but. The 
thing is that in D things are moving (and people in the community 
perceive it as something positive), which brings me to your next 
point.


 3) D has suffered greatly because it has had too many moving 
 targets as if constant change to something slightly better is 
 going to endear programmers to using a computer language. 
 Programmers need stability. The needed to know that if they are 
 using a programming language they are getting a particular 
 standard at a particular time with particular libraries that 
 work. They also need backward compatibility when things change. 
 D appears to have presented an almost constantly moving target 
 to this programmer, where adding/changing some feature is much 
 more important than fixing problems and providing stability.


True. I admit that I "fear" every new release in the sense that 
something will break and I'll have to fix it. More often than 
not, however, the fixes are trivial, and if they make sense and 
improve the language, I'm willing to pay the price. But your 
argument shows the fix D developers are in: to provide a better 
language without changing it (paradox). The trivial truth is that 
you can only improve a language by changing it and you need a 
community that is willing to go along with the changes. For this 
reason D hasn't taken off, because most people are not willing to 
risk (or cannot afford) frequent changes. Personally, I don't 
know which is worse, frequent (educated) changes or years of 
suboptimal coding until changes are made at long last (cf. Java). 
Mind you, well established languages like Java and C++ are now 
adopting things that have been around in D (and other languages) 
for a while, because those concepts have proven to be useful.

This said, D has become a lot better in terms of deprecating 
things. You get a warning well in advance and you can prepare for 
the (breaking) changes. My perception (which might be biased) is 
that people look at D, bash it and trash it, but nevertheless 
take things on board when developing the next version of C++ or 
whatever - without giving credit later. The Led Zeppelin 
syndrome[1].

[1] https://www.youtube.com/watch?v=tiiY4ciKFQA


 4) As a C++ programmer largely interested in C++ template 
 programming, C++ concepts etc., and potential 
 compile-time/run-time introspection, I have never found a 
 compelling reason to use D rather than C++. I do recognize that 
 C++'s template syntax is difficult and abstruse but I do not 
 and have never seen where D improves upon these matters in any 
 serious and rigorous way. This may be because the documentation 
 about these areas in D is either very light or almost 
 completely lacking. Even in Mr. Alexandrescu's book the 
 discussion of these areas was very light in my estimation. So 
 whatever D has to offer in these areas, if there are really 
 impovements, is either lacking in the D documentation or does 
 not really exist for me.


I cannot comment on this, because I don't know what you've read, 
know or want to know about D.


 Edward Diener
Aug 12 2016
prev sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 11/08/16 18:41, Edward Diener wrote:

 2) While I greatly respect the programming abilities of Mr. Bright and
 Mr. Alexandrescu and their hard work in creating and improving D, having
 followed both from the C++ world, the arrogance by which D was initially
 and repeatedly compared against C/C++ has been totally out of place
 since the beginning. C++ is a very good language and the effort made to
 denigrate it with specious and ridiculously false arguments about it
 vis-a-vis D as a programming language has almost irreparably hurt D as a
 serious programming language irrespective of its actual abilities or
 weaknesses. You are not going to appeal to the really intelligent
 programmers out there if you are not honest and rigorous in discussion
 of your own programming language in relation to others. All that you end
 up doing is to alienate anyone with real programming intelligence by the
 tactics that D has taken over the years with such comparisons.


To me, this is not so much the question of alienating C++ programmers, 
as it is that this arrogance is actively hindering D from becoming 
better. Any time I raise an issue I have with D, the discussion with 
both AA and WB seems more like an argument designed to prove to me that 
I am wrong than like a discussion aimed to make D better. Once they 
decide that something is best a certain way, it is very very difficult 
to make them see the downsides of that decision, much less act on it.

And, to me, this is an actual threat to D's future as a wide spread 
programming language. This attitude, if unchanged, will doom D to become 
a niche language, only suited for those who do not need it for anything 
that WB and AA have not thought of.


 4) As a C++ programmer largely interested in C++ template programming,
 C++ concepts etc., and potential compile-time/run-time introspection, I
 have never found a compelling reason to use D rather than C++. I do
 recognize that C++'s template syntax is difficult and abstruse but I do
 not and have never seen where D improves upon these matters in any
 serious and rigorous way. This may be because the documentation about
 these areas in D is either very light or almost completely lacking. Even
 in Mr. Alexandrescu's book the discussion of these areas was very light
 in my estimation. So whatever D has to offer in these areas, if there
 are really impovements, is either lacking in the D documentation or does
 not really exist for me.


Here I'm not sure I follow you. I love C++, but its compile time 
execution is just horrible. Yes, if you are fluent with functional 
programming you will probably get by sufficiently, but since C++ isn't 
itself a functional language, this means doing C++ meta-programming 
requires a different programming paradigm than programming C++.

It is a very very very high barrier to pass.

Personally, I'm not a fan of doing too much during compile time. I think 
it introduces a level of complexity into your program, where the program 
as seen by the CPU is considerably different than the one you see in 
your source editor, that is hard to track and debug. As such, the 
weakness of C++'s meta programming has not been a major setback for me.

If you do like compile time programming, however, I don't see how you 
can claim that C++'s is good enough, when compared to D's.

Shachar
Aug 12 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/12/2016 10:51 AM, Shachar Shemesh wrote:

 To me, this is not so much the question of alienating C++ programmers,
 as it is that this arrogance is actively hindering D from becoming better.


I agree it would behoove us to be more humble. -- Andrei
Aug 12 2016
prev sibling next sibling parent Karabuta <karabutaworld gmail.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:

 For years, i was travelling along Golang, Rust, Perl, Ruby, 
 Python, PHP, JScript, JVM Languages.
 Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many 
 more that i can't remember.

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

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

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?


That guy who was very popular in your high school, you remember? 
How did he become so popular?

D doesn't have much of what it takes to become popular that is 
why it is not :) Just ask yourself, why is JavaScript so popular? 
How about PHP?
Aug 14 2016
prev sibling next sibling parent reply Emre Temelkuran <etemelkuran gmail.com> writes:
It's easy to understand conservative programmers, you can even 
use C++ for web programming but it's waste of time and it won't 
give you the performance of Dropoid toolkit for Java. Also it's 
reliability is depends on your skills. Everyone leaving lower 
level languages other than the internet of things and game 
development industry. I noticed that, there was no significant 
progress on software industry for tens of years until higher 
level languages came out.
Aug 15 2016
parent Chris <wendlec tcd.ie> writes:
On Monday, 15 August 2016 at 13:10:01 UTC, Emre Temelkuran wrote:

 It's easy to understand conservative programmers, you can even 
 use C++ for web programming but it's waste of time and it won't 
 give you the performance of Dropoid toolkit for Java. Also it's 
 reliability is depends on your skills. Everyone leaving lower 
 level languages other than the internet of things and game 
 development industry. I noticed that, there was no significant 
 progress on software industry for tens of years until higher 
 level languages came out.


Do you know vibe.d? http://vibed.org/
Aug 15 2016
prev sibling parent reply Daniel <nobody nowhere.com> writes:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:

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

 Why people need NodeJS, Typescript etc, when there is already 
 better looking lang?
 Everyone talking about how ugly is Golang. So why people are 
 going on it? Performance concerns? Why languages that are not 
 backed up by huge companies are looking like they failed?


     I lurk this forum every so often, since the time when there 
was this funny guy who ranted like a rude drunkard.
     At work I developed in dBase, Turbo Pascal, Delphi, Visual 

most of my few hobby project and freelance work have been in 
Delphi, then Lazarus.
     D seems to have enhanced a lot, and I have even downloaded 
dlangide source once to try compiling and running it. I ran into 
some dub dependency problem and forgot about it.
     I guess, bundling the tools, ide and a couple good demos into 
an easily downloadable installation package (or package repo as 
in Debian) could be of some help. See for example:

https://sourceforge.net/projects/lazarus/files/

http://www.oracle.com/technetwork/java/javase/downloads/jdk-netbeans-jsp-142931.html?ssSourceSiteId=otnes

Hope this helps,

Daniel
Aug 19 2016
parent Daniel <imnot thisguy.com> writes:
On Saturday, 20 August 2016 at 00:19:30 UTC, Daniel wrote:

 On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
 Hope this helps,

 Daniel


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

Daniel
Aug 19 2016