www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Vision document for H1 2018

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Hello, the vision document of the Founation for the first six months of 
2018 is here:

https://wiki.dlang.org/Vision/2018H1

In addition to the expected items, we have a new top-level priority - 
locking down the language definition. This is in recognition of the fact 
that we need a precise definition of the language going forward.


Thanks,

Andrei
Mar 09 2018
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:

 Hello, the vision document of the Founation for the first six 
 months of 2018 is here:

 https://wiki.dlang.org/Vision/2018H1

 In addition to the expected items, we have a new top-level 
 priority - locking down the language definition. This is in 
 recognition of the fact that we need a precise definition of 
 the language going forward.


 Thanks,

 Andrei


Very nice, love how concrete this document has become, including 
listing the members of the core team, especially compared to the 
vague early vision statements.

One note about  nogc: I've seen complaints about the -vgc reports 
on reddit, that they're not very useful for mixed  nogc usage, 
where the GC is used for part of the codebase, not sure if 
something can be done about that.
Mar 09 2018
parent bachmeier <no spam.net> writes:
On Saturday, 10 March 2018 at 00:03:20 UTC, Joakim wrote:

 Very nice, love how concrete this document has become, 
 including listing the members of the core team, especially 
 compared to the vague early vision statements.

 One note about  nogc: I've seen complaints about the -vgc 
 reports on reddit, that they're not very useful for mixed  nogc 
 usage, where the GC is used for part of the codebase, not sure 
 if something can be done about that.


https://issues.dlang.org/show_bug.cgi?id=18404
Mar 09 2018
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 10/03/2018 10:43 AM, Andrei Alexandrescu wrote:

 Hello, the vision document of the Founation for the first six months of 
 2018 is here:
 
 https://wiki.dlang.org/Vision/2018H1
 
 In addition to the expected items, we have a new top-level priority - 
 locking down the language definition. This is in recognition of the fact 
 that we need a precise definition of the language going forward.
 
 
 Thanks,
 
 Andrei


I was going to edit the document and argue for it (but procedure has 
been a bit different this time), shared libraries.

 From what I saw in 2017 and pre 2016 too they are the number one 
implementation issue of D that drives people away. Almost everything 
else can be worked around.

Now that we have  nogc exceptions, and are going pay-as-you-go for 
runtime, this is the biggest thing holding us back IMO.

We need clear use cases with example code that works cross-platform.

With D-host, With C-host, merged with host, unmerged to host. Stuff like 
that.
Mar 09 2018
prev sibling next sibling parent psychoticRabbit <meagain meagain.com> writes:
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:

 Hello, the vision document of the Founation for the first six 
 months of 2018 is here:


nice.

andd that 'langauge specification' is really important too.. or 
people will drift towards languages that 'are' properly specified.

None of us like to be surprised by what the compiler does. The 
spec should tell it what to do.

and...just don't implement a 'no hugs' policy, or I'm outta here 
;-)
Mar 09 2018
prev sibling next sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:

 Hello, the vision document of the Founation for the first six 
 months of 2018 is here:

 https://wiki.dlang.org/Vision/2018H1


According to the State of D Survey, 71% of the respondents don't 
care about betterC. Why is betterC on the priority list?
Mar 10 2018
next sibling parent Dukc <ajieskola gmail.com> writes:
On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:

 According to the State of D Survey, 71% of the respondents 
 don't care about betterC. Why is betterC on the priority list?


I believe it's because it's so important for the 29% who care. If 
you're doing an module for project written in another language 
and don't want to introduce DRuntime yet, or are compiling to 
JavaScript for example, --BetterC can be a lot more helpful than 
killing autodecoding or whatever.
Mar 10 2018
prev sibling next sibling parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:

 On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
 wrote:

 Hello, the vision document of the Founation for the first six 
 months of 2018 is here:

 https://wiki.dlang.org/Vision/2018H1


 According to the State of D Survey, 71% of the respondents 
 don't care about betterC. Why is betterC on the priority list?


Yeah. Why should D worry about tying itself into C when it can't 
even interface with itself through DLLs?
Mar 10 2018
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:

 Yeah. Why should D worry about tying itself into C when it 
 can't even interface with itself through DLLs?


A reasonable point.

But.. in any case.. people work on what they are motivated to 
work on.

That's really all there is to it.

That's how the open source community works.

Top down, corporate direction, simply does not apply here.

One day you (or some other D programmer) might need betterC - who 
knows - and it'll be there for you - cause someone else was 
motivated to do it.
Mar 10 2018
next sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Saturday, 10 March 2018 at 11:07:56 UTC, psychoticRabbit wrote:

 On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:

 Yeah. Why should D worry about tying itself into C when it 
 can't even interface with itself through DLLs?


 A reasonable point.

 But.. in any case.. people work on what they are motivated to 
 work on.

 That's really all there is to it.

 That's how the open source community works.


I'm talking about the D Foundation priority list, not about the 
open source community surrounding it. I have nothing against 
betterC, the community is free to work on it, but I don't 
understand why it's a *priority* for the D foundation. Is there 
any funding involved requesting explicitly betterC support?
Mar 10 2018
next sibling parent psychoticRabbit <meagain meagain.com> writes:
On Saturday, 10 March 2018 at 11:45:25 UTC, rumbu wrote:

 I'm talking about the D Foundation priority list, not about the 
 open source community surrounding it. I have nothing against 
 betterC, the community is free to work on it, but I don't 
 understand why it's a *priority* for the D foundation. Is there 
 any funding involved requesting explicitly betterC support?


I think cause interoperating with C/C++, as well as encouraging 
migrating C/C++ code over D..has always been a key objective for 
Andrei and Walter (as least that's the impression I get - as a 
relative newcomer to D).

So I doesn't surprise me that it would be (remain) a priority for 
the D foundation, which they (and others) represent.

All power to em...

Although... I'm just not convinced that C programmers will give 
up C, and C++ programmers will give up C++ ... well... certainly 
I don't see any mass migration on the horizon of my crystal ball.

Everyone will end up programming in C++, Java, or .NET .. says 
the crystal ball.
Mar 10 2018
prev sibling parent psychoticRabbit <meagain meagain.com> writes:
On Saturday, 10 March 2018 at 11:45:25 UTC, rumbu wrote:

 I'm talking about the D Foundation priority list, not about the 
 open source community surrounding it. I have nothing against 
 betterC, the community is free to work on it, but I don't 
 understand why it's a *priority* for the D foundation. Is there 
 any funding involved requesting explicitly betterC support?


perhaps this question can be one of many, that the community ask 
the members of the D foundation, on stage, during the Q and A at 
the upcoming Dconf ;-)

there will be a roasting.. won't there?
Mar 10 2018
prev sibling parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Saturday, 10 March 2018 at 11:07:56 UTC, psychoticRabbit wrote:

 On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:

 Yeah. Why should D worry about tying itself into C when it 
 can't even interface with itself through DLLs?


 A reasonable point.

 But.. in any case.. people work on what they are motivated to 
 work on.

 That's really all there is to it.

 That's how the open source community works.

 Top down, corporate direction, simply does not apply here.

 One day you (or some other D programmer) might need betterC - 
 who knows - and it'll be there for you - cause someone else was 
 motivated to do it.


Well, no. I'm more concerned with the fact that the D Language 
Foundation is focused on BetterC, yet does not mention DLLs at 
all.

For God's sake, if D is the future, why does it continue to leech 

function calling C (FFI/PInvoke) yet are way more popular. I get 
the feeling that most of the C++ programmers who would come to D 
have already done so.

The most I'll ever need of interfacing with C and C++ is to be 
able to call their functions from D. I've no reason for BetterC.

And what's with the language design, anyway? D has been designed 
with features that C++ programmers don't want, then now the D 
Language Foundation is wasting effort to change the language to 
rope those programmers in? If D was meant to be C++ 2.0, 
shouldn't it have been designed that way from the start?


had a GC, was awesome to program in and was very fast. Why can't 
D own up to these facts, rather than becoming a leech of C++?

Every day D becomes more like C++ 2.0, why can't it just be D?
Mar 10 2018
next sibling parent Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:

 On Saturday, 10 March 2018 at 11:07:56 UTC, psychoticRabbit 
 wrote:

 On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote:


 [Omitted]


I also would like to point out that I don't care if some 
open-source developers decide to create BetterC in their free 
time. More power to them. It doesn't concern me.

What does concern me is that BetterC is the focus of the *D 
Language Foundation*. Why isn't interfacing with D more important?

I'm becoming more and more skeptical of the future of D.
Mar 10 2018
prev sibling next sibling parent reply R <Ryzo1201 gmail.com> writes:
On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:

 Well, no. I'm more concerned with the fact that the D Language 
 Foundation is focused on BetterC, yet does not mention DLLs at 
 all.

 For God's sake, if D is the future, why does it continue to 

 basic function calling C (FFI/PInvoke) yet are way more 
 popular. I get the feeling that most of the C++ programmers who 
 would come to D have already done so.

 The most I'll ever need of interfacing with C and C++ is to be 
 able to call their functions from D. I've no reason for BetterC.

 And what's with the language design, anyway? D has been 
 designed with features that C++ programmers don't want, then 
 now the D Language Foundation is wasting effort to change the 
 language to rope those programmers in? If D was meant to be C++ 
 2.0, shouldn't it have been designed that way from the start?


 had a GC, was awesome to program in and was very fast. Why 
 can't D own up to these facts, rather than becoming a leech of 
 C++?

 Every day D becomes more like C++ 2.0, why can't it just be D?


Point to the wall on the left side. That is what your talking to. 
D its focus on C++ as a bad plan has been made pushed by many 
people ( lots who left ). Its like asking Go for Generics.

And its very nice to see the "71% in the poll do not want 
BetterC", well, screw them comment. So what is the point again by 
asking people opinions? And sure, BetterC can be reused to 
improve the D core but that is not what people want NOW. And yet, 
its a priority when 71% say its not!

D simply is not equipped for dealing with people who come from 

here are C++ old timers ( yes, there are exceptions ) and they 
only think in that direction.

Kind of ironic when D keeps pushing for more features hoping that 
it will attract C++ developers and the young kid on the block 
Rust is already eating up that market. And "scripting" language 
like PHP, that everybody criticizes just keeps growing and gained 
11% market share in the last 7 years ( at now 83% ). Where as D 
its gain has been minimalist thanks to people leaving almost as 
fast as it gain.

There is a lesson the be learned in this somewhere...
Mar 10 2018
next sibling parent Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:

 On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:

 Well, no. I'm more concerned with the fact that the D Language 
 Foundation is focused on BetterC, yet does not mention DLLs at 
 all.

 For God's sake, if D is the future, why does it continue to 

 basic function calling C (FFI/PInvoke) yet are way more 
 popular. I get the feeling that most of the C++ programmers 
 who would come to D have already done so.

 The most I'll ever need of interfacing with C and C++ is to be 
 able to call their functions from D. I've no reason for 
 BetterC.

 And what's with the language design, anyway? D has been 
 designed with features that C++ programmers don't want, then 
 now the D Language Foundation is wasting effort to change the 
 language to rope those programmers in? If D was meant to be 
 C++ 2.0, shouldn't it have been designed that way from the 
 start?


 that had a GC, was awesome to program in and was very fast. 
 Why can't D own up to these facts, rather than becoming a 
 leech of C++?

 Every day D becomes more like C++ 2.0, why can't it just be D?


 Point to the wall on the left side. That is what your talking 
 to. D its focus on C++ as a bad plan has been made pushed by 
 many people ( lots who left ). Its like asking Go for Generics.


Yeah. It quite seems like that. Maybe after BetterC will the 
foundation get its priorities right.


 And its very nice to see the "71% in the poll do not want 
 BetterC", well, screw them comment. So what is the point again 
 by asking people opinions? And sure, BetterC can be reused to 
 improve the D core but that is not what people want NOW. And 
 yet, its a priority when 71% say its not!


Didn't BetterC start before the poll was issued? I hope that more 
polls like this are created in the future so that the leadership 
knows where it's priorities are based upon community demands.


 D simply is not equipped for dealing with people who come from 

 people here are C++ old timers ( yes, there are exceptions ) 
 and they only think in that direction.

 Kind of ironic when D keeps pushing for more features hoping 
 that it will attract C++ developers and the young kid on the 
 block Rust is already eating up that market. And "scripting" 
 language like PHP, that everybody criticizes just keeps growing 
 and gained 11% market share in the last 7 years ( at now 83% ). 
 Where as D its gain has been minimalist thanks to people 
 leaving almost as fast as it gain.

 There is a lesson the be learned in this somewhere...


I wholeheartedly agree, but I believe this direction is because 
that the "C++ old timers" are in the leadership. I don't think 
there are "too many" in the community.

I also wish to point out that I'm not attacking Walter or Alex; I 
love the language they've created, but I'm fairly annoyed with 
their allocation of resources. They need to stick by the language 
they've created.
Mar 10 2018
prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:

 Point to the wall on the left side. That is what your talking 
 to. D its focus on C++ as a bad plan has been made pushed by 
 many people ( lots who left ). Its like asking Go for Generics.

 And its very nice to see the "71% in the poll do not want 
 BetterC", well, screw them comment. So what is the point again 
 by asking people opinions? And sure, BetterC can be reused to 
 improve the D core but that is not what people want NOW. And 
 yet, its a priority when 71% say its not!

 D simply is not equipped for dealing with people who come from 

 people here are C++ old timers ( yes, there are exceptions ) 
 and they only think in that direction.
 There is a lesson the be learned in this somewhere...
 ....


Again, D is not run by some corporation.

Nor is it a democracy - where majority rule. (read this sentence 
over and over till you get it)

It's a language that develops because people are sufficiently 
motivated to put in the time to develop what interests them.

Have your say and leave it at that. Stop attacking the work 
others are doing.

And stop your discriminatory use of the phrase 'old timers'.
Mar 10 2018
parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 11 March 2018 at 01:21:27 UTC, psychoticRabbit wrote:

 On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:

 Point to the wall on the left side. That is what your talking 
 to. D its focus on C++ as a bad plan has been made pushed by 
 many people ( lots who left ). Its like asking Go for Generics.

 And its very nice to see the "71% in the poll do not want 
 BetterC", well, screw them comment. So what is the point again 
 by asking people opinions? And sure, BetterC can be reused to 
 improve the D core but that is not what people want NOW. And 
 yet, its a priority when 71% say its not!

 D simply is not equipped for dealing with people who come from 

 people here are C++ old timers ( yes, there are exceptions ) 
 and they only think in that direction.
 There is a lesson the be learned in this somewhere...
 ....


 Again, D is not run by some corporation.

 Nor is it a democracy - where majority rule. (read this 
 sentence over and over till you get it)


The D Language Foundation, being the leading body of D, should 
hold some responsibility to the interests of the majority.

It is not a dictatorship (read this sentence over and over till 
you get it).
Mar 10 2018
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:

 The D Language Foundation, being the leading body of D, should 
 hold some responsibility to the interests of the majority.



And also the minority. A lesson that humanity has to learn over 
and over again.
Mar 10 2018
parent Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 11 March 2018 at 01:45:01 UTC, psychoticRabbit wrote:

 On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:

 The D Language Foundation, being the leading body of D, should 
 hold some responsibility to the interests of the majority.



 And also the minority. A lesson that humanity has to learn over 
 and over again.


Despite the fact that D struggles to interface with itself yet 
the priorities of the foundation are to make D easily interface 
with C? I don't care if they listen to the minority, but make 
sure your priorities are in line before doing so. I think BetterC 
will be something useful in the future, not now.
Mar 10 2018
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:


 The D Language Foundation, being the leading body of D, should 
 hold some responsibility to the interests of the majority.


Please read my post from earlier:

https://forum.dlang.org/post/chsqspkoxbcdqjcqbfjc forum.dlang.org

The survey *will* have an influence on what gets priority in the 
future, but it certainly can't be seen as representing the 
majority of D programming interests.



 It is not a dictatorship (read this sentence over and over till 
 you get it).


No one is forcing you to use BetterC and its existence doesn't 
change anything about how you can use the language. Obviously, 
there are a number of areas that need work. The survey can help 
decide which of those to put resources into first, but it doesn't 
mean that other things deemed important have to be dropped.
Mar 10 2018
parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 11 March 2018 at 01:50:22 UTC, Mike Parker wrote:

 On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote:


 The D Language Foundation, being the leading body of D, should 
 hold some responsibility to the interests of the majority.


 Please read my post from earlier:

 https://forum.dlang.org/post/chsqspkoxbcdqjcqbfjc forum.dlang.org

 The survey *will* have an influence on what gets priority in 
 the future, but it certainly can't be seen as representing the 
 majority of D programming interests.


Good. That's definitely for the better.


 It is not a dictatorship (read this sentence over and over 
 till you get it).


 No one is forcing you to use BetterC and its existence doesn't 
 change anything about how you can use the language. Obviously, 
 there are a number of areas that need work. The survey can help 
 decide which of those to put resources into first, but it 
 doesn't mean that other things deemed important have to be 
 dropped.


That sentence was to counter psychoticRabbit. I didn't mean it 
literally. If you've read my earlier posts, it's not BetterC I 
have an issue with, it's the allocation of time.

As you said, hopefully the survey will help clear up these issues 
with D.
Mar 10 2018
parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 01:53:30 UTC, Dylan Graham wrote:

 That sentence was to counter psychoticRabbit. I didn't mean it 
 literally. If you've read my earlier posts, it's not BetterC I 
 have an issue with, it's the allocation of time.


Well that should have been the basis of your original argument.

i.e. How can the D Foundation encourage new additional resoures 
to focus on things that also matter to the community.

Instead, you started by attacking the D Foundation for allocating 
resources to betterc.
Mar 10 2018
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 01:58:50 UTC, psychoticRabbit wrote:

 i.e. How can the D Foundation encourage new additional resoures 
 to focus on things that also matter to the community.



and btw. the mention about strengthing the use of DIPS, does just 
that.

there are many improvement to 'process' that can be done to 
encourage more people to contribute to D.

This is not about betterc at all, really.
Mar 10 2018
parent Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 11 March 2018 at 02:02:15 UTC, psychoticRabbit wrote:

 On Sunday, 11 March 2018 at 01:58:50 UTC, psychoticRabbit wrote:

 i.e. How can the D Foundation encourage new additional 
 resoures to focus on things that also matter to the community.



 and btw. the mention about strengthing the use of DIPS, does 
 just that.

 there are many improvement to 'process' that can be done to 
 encourage more people to contribute to D.

 This is not about betterc at all, really.


Then it does seem like things will improve. I hope there will be 
more surveys in the future and I'm very happy with the new DIP 
process.

My original argument was that BetterC is a mismanagement of 
resources, and I still stand by that.
Mar 10 2018
prev sibling parent Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 11 March 2018 at 01:58:50 UTC, psychoticRabbit wrote:

 On Sunday, 11 March 2018 at 01:53:30 UTC, Dylan Graham wrote:

 That sentence was to counter psychoticRabbit. I didn't mean it 
 literally. If you've read my earlier posts, it's not BetterC I 
 have an issue with, it's the allocation of time.


 Well that should have been the basis of your original argument.


I stated that in my second reply to you.


 i.e. How can the D Foundation encourage new additional resoures 
 to focus on things that also matter to the community.

 Instead, you started by attacking the D Foundation for 
 allocating resources to betterc.


You've got me there. I could've done much better to convince.
Mar 10 2018
prev sibling parent psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote:

 .... And "scripting" language like PHP, that everybody 
 criticizes just keeps growing and gained 11% market share in 
 the last 7 years ( at now 83% ). Where as D its gain has been 
 minimalist thanks to people leaving almost as fast as it gain.


Well, according to the TIOBE Index, C was the language of 2017.

Java is almost always on top, followed by C, followed closely by 
C++.

And it's not just 'old timers' using those languages... surely.

And scripting language can pretty much replace any other 
scripting language.

It's the 'real' programming languages that matter ;-)

And D's not doing to badly at all...despite betterc

https://www.tiobe.com/tiobe-index/d/

(although I wonder what happended back in 2009 ??)
Mar 10 2018
prev sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:

 Every day D becomes more like C++ 2.0, why can't it just be D?


Oddly enough, I think this is D's strength.

Golang tried to draw the line, and look where that got it. Now 
it's a limited language for a specific domain  (at least until Go 
3.0).

Rust decided (and Go to some extent), to introduce foreign syntax 
that was vastly different to what the majority of programmers are 
familiar with, and, it makes it difficult to transistion to 
because its syntax is so unlike the syntax most people will 
continue to have to work with.


jump right in and use it. And, they can continue to go back and 
forth without syntax related psychosis developing.

betterc is just another way of supporting that crowd..and it's a 
very big crowd.

Your problem is not betterc, but something else. So focus on that 
instead.






D is also particulary useful for some problems.

Better to use both, not one or the other.

Thanks to not being Go or Rust, you can do that - cause concepts, 
syntax  etc, are really compatible with both.
Mar 10 2018
next sibling parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote:

 On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:

 Every day D becomes more like C++ 2.0, why can't it just be D?


 Oddly enough, I think this is D's strength.


I really don't.


 Golang tried to draw the line, and look where that got it. Now 
 it's a limited language for a specific domain  (at least until 
 Go 3.0).

 Rust decided (and Go to some extent), to introduce foreign 
 syntax that was vastly different to what the majority of 
 programmers are familiar with, and, it makes it difficult to 
 transistion to because its syntax is so unlike the syntax most 
 people will continue to have to work with.


 jump right in and use it. And, they can continue to go back and 
 forth without syntax related psychosis developing.

 betterc is just another way of supporting that crowd..and it's 
 a very big crowd.


Yeah, 29% of the crowd.


 Your problem is not betterc, but something else. So focus on 
 that instead.


You're right, my problem isn't BetterC, it's the fact that 
Foundation can't get its priorities right. BetterC is a symptom.








I'm my current use-case, D is 'vastly superior'. I wouldn't have 
switched to D if there was no reason to.


 D is also particulary useful for some problems.

 Better to use both, not one or the other.

 Thanks to not being Go or Rust, you can do that - cause 
 concepts, syntax  etc, are really compatible with both.


I'm not sure what you mean at that last sentence.
Mar 10 2018
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote:

 I'm not sure what you mean at that last sentence.



can easily switch between them.

Whereas as Go and Rust have their own thing going, making those 
languages really difficult in terms of "programmer" portability.

C++ became popular cause C programmers could easily use it.
Java became popular cause C/C++ programmers could easily use it.

it.


can easily use it.
Mar 10 2018
parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 11 March 2018 at 01:41:33 UTC, psychoticRabbit wrote:

 On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote:

 I'm not sure what you mean at that last sentence.



 can easily switch between them.

 Whereas as Go and Rust have their own thing going, making those 
 languages really difficult in terms of "programmer" portability.

 C++ became popular cause C programmers could easily use it.
 Java became popular cause C/C++ programmers could easily use it.

 it.


 can easily use it.


Rust was more popular and who could use that?
Rust is popular because of its ideas, not because it pandered.
Mar 10 2018
parent psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 01:46:09 UTC, Dylan Graham wrote:

 Rust was more popular and who could use that?
 Rust is popular because of its ideas, not because it pandered.



I don't see "programmer" portability as being pandering.

It common sense.

Rust is good, in that it seeks to do something different. I like 
that.

But I live in the real world, and need to switch between 
languages often.

Language theory is nice and all that, but "programmer" 
portability is paramount for me.. not popular ideas.

And Rust is popular... with Rust programmers.
Mar 10 2018
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote:

 betterc is just another way of supporting that crowd..and it's 
 a very big crowd.


 Yeah, 29% of the crowd.


29% of the existing D crowd who answered the survey, which means 
around 150 people, or about how many download one compiler, dmd, 
in an average hour of the day:

http://erdani.com/d/downloads.daily.png

Meanwhile, Walter wrote a blog post about his betterC efforts 
last year, and it was the third-most liked link from dlang.org on 
reddit over the last year, with 226 net likes:

https://www.reddit.com/domain/dlang.org/top/?sort=top&t=year

No. 2?  Another article about using D without the GC.

Now, as I've said on the forum several times, I personally don't 
care for  nogc or betterC: I don't use them.  I'm sure many 
existing D users don't either.  However, as those reddit stats 
show, there is interest from _outside_ the D community for them.

When it comes to strategic decisions like this to bring in new 
users from outside the community, you cannot depend on polling 
users within the community to figure it out.  Argue against 
betterC really bringing in new users if you want, but arguing 
that it doesn't help existing users is missing the point.

I'm not sure how successful betterC will be in pulling in those 
users, as I'm not a C/C++ programmer and don't know what they 
want, but the popularity of those links suggests the D foundation 
is on the right track.


 Your problem is not betterc, but something else. So focus on 
 that instead.


 You're right, my problem isn't BetterC, it's the fact that 
 Foundation can't get its priorities right. BetterC is a symptom.


The Foundation's priorities are not simply serving the existing 
users but growing the userbase.
Mar 11 2018
prev sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote:

 On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:









Because, even the language creators seem to not recognize this, D 

identical. Basically, if my source code doesn't use any .NET 
framework function, it will compile successfully with dmd without 
any (major) change.


contact with the D language, but fails to keep his enthusiasm 

world and Phobos looks like a mess from his point of view.




D concepts were introduced in the language: local functions, '_' 
as digit separator, binary literals, ref returns, tuples, 

the table: slices.

In the same time, D delegates new features (and sometime existing 
ones) to library implementation, instead of assume them in the 
language syntax.
Mar 10 2018
next sibling parent psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:



 instantly.


OT:

Interestingly, my uni is still stuck in the OOP paradigm, and is 
now teaching intro to OOP using .NET Core, cause it's now cross 
platform, and people can also used VS code, which also cross 
platform.

but running > dotnet myprogram (.dll)

is just an awful experience ;-)

although, that's how java works to.. and java is probably the 
most widely used language of all.
Mar 11 2018
prev sibling next sibling parent reply R <Ryzo1201 gmail.com> writes:
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:

 Because, even the language creators seem to not recognize this, 

 identical. Basically, if my source code doesn't use any .NET 
 framework function, it will compile successfully with dmd 
 without any (major) change.


Most people do not have issues with the core language of D. You 
can come from any of the above mentioned languages ( like C, C++, 
Rust, PHP, Python, Nim, ... ) and get going with D. That is what 
attracted me in the first place. The language looks good but the 
moment you actually start using D its issue after issue.

With the usual response here: "Why do you not fix it yourself or 
pay for it". Maybe because most people who come want to use the 
tools and be productive and not spend their time fixing up those 
tools.

Its a mentality issue that some do not get here. In order to grow 
you need consumers for your product. If you force or whine to 
them to fix the issues, they leave. When they leave you lose 
potential growth. That loss in growth means losing potential 
members that can fix and want to fix the issues.

One can call it selfish but every language is based upon this 
principle. No growth and community of lots of selfish users means 
no other members to fix the issues. It is the 9 Circles of Hell.



 contact with the D language, but fails to keep his enthusiasm 

 world and Phobos looks like a mess from his point of view.


+1!

It has the language mostly right but its everything around it 
that is simply a mess. When one compares that to Rust. They are 
not having constant discussion about replacing cargo ( as dub in 
D has issues ). They do not need to have multiple documentation 
generators. The cross platform is simple and fast. Same applies 

the whole platform as such. D is like a children sandbox where 
everybody is playing with their own toys. So when other complain 
about the mess of the playground, the responds by some is just as 
typical.





I am sure that lots of D members will be quick to point out, that 

contributors. Now why did you not contribute! /sarcasm




 of D concepts were introduced in the language: local functions, 
 '_' as digit separator, binary literals, ref returns, tuples, 

 on the table: slices.


Yep ... Things are moving faster in the .net camp thanks to the 
focus on .net Core and the RyuJit.

Here is a fun one, with Blazer now being part of the official 
.net.

https://github.com/aspnet/blazor




 In the same time, D delegates new features (and sometime 
 existing ones) to library implementation, instead of assume 
 them in the language syntax.



 instantly.


Personally i am waiting to see CoreRT finalized:

https://github.com/dotnet/corert

-> CppCodeGen/C++
-> RyuJIT codegen
-> Webasm

Its already working and getting better by the day.

Other languages are moving forwards at blazing speeds and D seems 
to put it priorities on adding new exiting features. Where as a 
large part of the outcry is the issues with the library, lacking 
editors support, cross platform issues, ...
Mar 11 2018
next sibling parent reply bachmeier <no spam.net> writes:
On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote:


 With the usual response here: "Why do you not fix it yourself 
 or pay for it". Maybe because most people who come want to use 
 the tools and be productive and not spend their time fixing up 
 those tools.


I've never seen anyone write that. Most likely you saw someone 
post something that looks similar, but has a dramatically 
different meaning. The usual response is "If you want something 
done, you're going to have to do it yourself or pay someone to do 
it for you, or else it won't get done."


 Its a mentality issue that some do not get here. In order to 
 grow you need consumers for your product. If you force or whine 
 to them to fix the issues, they leave. When they leave you lose 
 potential growth. That loss in growth means losing potential 
 members that can fix and want to fix the issues.


And this clarifies the source of your confusion. The D 
programming language is an open source project, not a for-profit 
company. D is not the language you're looking for.
Mar 11 2018
parent reply rumbu <rumbu rumbu.ro> writes:
On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:

 And this clarifies the source of your confusion. The D 
 programming language is an open source project, not a 
 for-profit company. D is not the language you're looking for.



72 pull requests form 24 contributors were merged on ~master. And 



no-brainer. Contributing to D needs an advanced degree in 
computer science. Using the information on the D wiki didn't 
helped me until now to successfully compile and test a fresh copy 
of dmd or phobos.
Mar 11 2018
next sibling parent Aravinda VK <mail aravindavk.in> writes:
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

 On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:

 And this clarifies the source of your confusion. The D 
 programming language is an open source project, not a 
 for-profit company. D is not the language you're looking for.



 week 72 pull requests form 24 contributors were merged on 



 a no-brainer. Contributing to D needs an advanced degree in 
 computer science. Using the information on the D wiki didn't 
 helped me until now to successfully compile and test a fresh 
 copy of dmd or phobos.


I contributed to phobos for the first time for the release 
2.079.0. Experience was smooth and also I learnt many new things 
from the review comments. I was able to follow wiki page to 
compile phobos or compile one specific module. Please let us know 
the issue faced, so that wiki can be improved.
Mar 11 2018
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

 On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:

 And this clarifies the source of your confusion. The D 
 programming language is an open source project, not a 
 for-profit company. D is not the language you're looking for.



 week 72 pull requests form 24 contributors were merged on 




compiler there's a dedicated team of full-time developers.

Also to be fair, the activity on dmd isn't that low either though 
the last week was a one with low-traffic:

https://github.com/dlang/dmd/pulse

Typically ~40 PRs get merged per PR for dmd alone:

https://auto-tester.puremagic.com/chart.ghtml?projectid=1

With druntime + phobos, it's a lot more.



 a no-brainer. Contributing to D needs an advanced degree in 
 computer science. Using the information on the D wiki didn't 
 helped me until now to successfully compile and test a fresh 
 copy of dmd or phobos.


I assume you are using Windows?
Setup on Posix is really simple.
git clone all three repos + run make.

There's also a bash script to automate this:

https://github.com/dlang/tools/blob/master/setup.sh

 From what I heard it's a bit tricky on Windows. I only tried with 
wine and that worked out-of-the-box for me. Execute the DMD 
installer, set PATH, DM_HOME and HOST_DC and then run the win32 
makefiles work fine.

What could be done from your perspective to make the setup easier?
Mar 11 2018
next sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:

 I assume you are using Windows?


Yes, I'm the typical lazy convenient Windows user scared of the 
terminal window.


 Setup on Posix is really simple.
 git clone all three repos + run make.


I am happy for Posix users. Theoretically the process is the same 
on Windows.


 There's also a bash script to automate this:

 https://github.com/dlang/tools/blob/master/setup.sh


This will need Linux subsystem as a Windows feature installed. 
Bash scripts do not work on Windows. Or other third party 
applications that are not listed as prerequisites on wiki.


 From what I heard it's a bit tricky on Windows. I only tried 
 with wine and that worked out-of-the-box for me. Execute the 
 DMD installer, set PATH, DM_HOME and HOST_DC and then run the 
 win32 makefiles work fine.


make -fwin32.mak release
Error: don't know how to make 'release'

Ok, let's skip this, make it without "release".

Now test it:

cd test
make all -j8
Command error: undefined switch '-j8'



 What could be done from your perspective to make the setup 
 easier?


 From my perspective I would like to have an working setup, not 

compiler, you just need to open roslyn.sln in Visual Studio, make 
your modification, run the test suite, commit, you're done.
Mar 11 2018
parent reply Laeeth Isharc <Laeeth laeeth.com> writes:
On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote:

 On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:

 [...]


 Yes, I'm the typical lazy convenient Windows user scared of the 
 terminal window.


 [...]


 I am happy for Posix users. Theoretically the process is the 
 same on Windows.


 [...]


 This will need Linux subsystem as a Windows feature installed. 
 Bash scripts do not work on Windows. Or other third party 
 applications that are not listed as prerequisites on wiki.


 [...]


 make -fwin32.mak release
 Error: don't know how to make 'release'

 Ok, let's skip this, make it without "release".

 Now test it:

 cd test
 make all -j8
 Command error: undefined switch '-j8'


Why are you adding -j8 ? Does it say to do so in the instructions 
? Try without it.  (I can't test here as typing from my phone).
Mar 11 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, March 12, 2018 03:37:11 Laeeth Isharc via Digitalmars-d-announce 
wrote:

 On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote:

 On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:

 [...]


 Yes, I'm the typical lazy convenient Windows user scared of the
 terminal window.


 [...]


 I am happy for Posix users. Theoretically the process is the
 same on Windows.


 [...]


 This will need Linux subsystem as a Windows feature installed.
 Bash scripts do not work on Windows. Or other third party
 applications that are not listed as prerequisites on wiki.


 [...]


 make -fwin32.mak release
 Error: don't know how to make 'release'

 Ok, let's skip this, make it without "release".

 Now test it:

 cd test
 make all -j8
 Command error: undefined switch '-j8'


 Why are you adding -j8 ? Does it say to do so in the instructions
 ? Try without it.  (I can't test here as typing from my phone).


When dealing with building on Windows, it would definitely pay to read the
instructions and not assume anything about make, since unfortunately, the
Windows build uses the digital mars make, which is severely limited in
comparison to the BSD make or GNU make.

- Jonathan M Davis
Mar 11 2018
parent Seb <seb wilzba.ch> writes:
On Monday, 12 March 2018 at 04:54:22 UTC, Jonathan M Davis wrote:

 On Monday, March 12, 2018 03:37:11 Laeeth Isharc via 
 Digitalmars-d-announce wrote:

 On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote:

 [...]


 Why are you adding -j8 ? Does it say to do so in the 
 instructions ? Try without it.  (I can't test here as typing 
 from my phone).


 When dealing with building on Windows, it would definitely pay 
 to read the instructions and not assume anything about make, 
 since unfortunately, the Windows build uses the digital mars 
 make, which is severely limited in comparison to the BSD make 
 or GNU make.

 - Jonathan M Davis


That's only partially true and the reason for the error. GNU/BSD 
make is required to run the DMD testsuite.
BTW removal of DigitalMars Make has been officially approved 
since a long time, but it's blocked since it's so hard to make 
changes to the auto-tester.
Mar 11 2018
prev sibling parent rumbu <rumbu rumbu.ro> writes:
On Monday, 12 March 2018 at 03:37:11 UTC, Laeeth Isharc wrote:

 cd test
 make all -j8
 Command error: undefined switch '-j8'


 Why are you adding -j8 ? Does it say to do so in the 
 instructions ? Try without it.  (I can't test here as typing 
 from my phone).


https://wiki.dlang.org/DMD_development

Of course, it works without the -j8 switch, but the documentation 
doesn't say that multiple threads option is only available on 
Linux.
Mar 11 2018
prev sibling parent reply SealabJaster <sealabjaster gmail.com> writes:
On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote:

 What could be done from your perspective to make the setup 
 easier?


(This is from the perspective of a novice programmer, who hasn't 
really interacted with open source projects much)

When I first tried to compile dmd+druntime+phobos quite a while 
ago, I found the information on the wiki about building on 
windows[1] pretty unhelpful (in fact I never managed get all 3 to 
compile properly), though that seems to have gotten a lot better 
now (especially that it tells you how to structure your 
directories, which from what I remember you just had to piece 
together and guess from what the wiki commands were doing 
originally). Luckily the two contributions I made back then 
didn't require me to actually have any of that working...

As a spoiled Windows user, I like convenience, and I like things 
being easy to do. For me, trying to simply build everything was a 
frustrating task that took up a few days of time (reminder, this 
*was* quite a bit ago before the Windows part of the wiki was 
updated, and I was/still am pretty new to working on projects 
that aren't my own).

One of the more frustrating yet annoyingly simple issues I was 
having was that the version of Make in my PATH (GNU Make at a 
guess) wasn't able to use win32.mak, which led to me getting 
confused and frustrated for a day or two before I figured 
out(can't remember how exactly) that I had to use Digital Mars' 
make... I don't think there's any clear text on the wiki that 
says "For Windows, you *need* to use Digital Mars' make to use 
win32.mak".

After I changed to using Digital Mars' Make, I ran into another 
annoying but very simple issue. The wiki says to use "make 
-fwin32.mak release", ok fine:
```
PS D:\Coding\D\Tools\dlang\dmd2\src\dmd\src> make -fwin32.mak 
release
Error: can't read makefile 'win32'
```

Turns out all I had to do was put a space between '-f' and 
'win32.mak'. Thankfully I only wasted about 30mins at most 
figuring that out. Didn't make it any less frustrating though.

Around the time I was adding std.traits.isCopyable to Phobos, I 
thought to myself "Maybe I can at least get the testing stuff to 
work!"... So I go to the wiki and see something along the lines 
of "make -fposix.mak std/traits.test" and thought that win32.mak 
would have the same functionality - however it doesn't, and only 
has a target to unittest the entirety of Phobos, giving me the 
impression Windows seems to just be a footnote compared to Posix 
platforms. ('make -f win32.mak dscanner' is another example). For 
isCopyable, it was easier for me to just develop it in it's own 
file, move it into std.traits, and hope the auto-tester could 
build it.

I think I did manage to get "make -f win32.mak unittest" (for 
phobos) to work at one point, but a test that included sockets 
failed (I think it was a test between paired sockets, and one of 
them timed out). This of course made it feel pointless to use, 
since it'd just always fail.

One last example of a very tiny issue, is that for DMD, the 
makefiles you use to build it are in, for example 
'dmd2/src/dmd/src/win32.mak', instead of 'dmd2/src/dmd/win32.mak' 
making it a bit inconsistent with 
druntime('dmd2/src/druntime/win32.mak') and 
phobos('dmd2/src/phobos/win32.mak').

There were certainly a bunch more tiny issues and bumps I had 
when trying to build things my first time around that I can't 
remember, whether it be due to my own incompetency or due to 
issues with the wiki/win32.mak, and after the two changes I made 
to Phobos I just had no will to continue, and gave up for a while.

I genuinely feel it'd have been easier for me to just load up 
Ubuntu on a VM and go from there, instead of developing on 
Windows.

One thing I'd would have liked, as a Windows/lazy user, and as a 
beginner, is a single file/tool that would've helped me setup and 
build everything (like that setup.sh you linked, except it's a 
Bash script...)

And in a perfect world, we wouldn't need 3 different makefiles 
(win32.mak, win64.mak, and posix.mak), but instead there'd either 
be a single makefile, or some other tool is used to provide a 
cross-platform way to access the current features of posix.mak. I 
understand that this isn't an easy issue to solve though, hence 
the "in a perfect world" (you could also say, in a perfect world, 
everyone develops on a Posix platform! ;)).

Then I recently gathered up the will to want to contribute again, 
and decided to make a Powershell script that does exactly that 
for me which actually turned out to work pretty well, I can build 
all 3 projects without too much hassle, and without having to 
remember all those annoying pitfalls e.g. "-f win32.mak instead 
of -fwin32.mak", something I would've liked to have in the first 
place. Or so I thought.

I wanted to try and add some colouring[2] to dmd's error messages 
(sounds easy enough right?), so I have a quick look and see all I 
need to do is add some backticks around certain parts of the 
error message[3, as an example]. So I add my backticks into one 
error I can easily trigger, build it using my powershell script, 
and then all I see is that an exception (I think it was actually 
a RangeError) was thrown, and the stack trace was just a bunch of 
addresses without any text. (I don't have that build of dmd.exe 
anymore, and most of dmd has been colourised by now, so I can't 
get an accurate copy-paste of what happened or try to reproduce 
it.)

I decided "that's not supposed to happen", and tried to colourise 
a few other error messages... but I got the exact same result. I 
try to take an already coloursised error message, copy and paste 
it to another file, and try again to no avail.

At that point I decided that it's probably yet another issue with 
my build environment that I'll have to try an work out, but if I 
can't even get something 'trivial' such as colouring in messages 
working without frustration, then I can't be bothered to put in 
any more effort with trying to do anything else (I'd rather not 
be stuck only being able to do documentation changes), since, at 
least in my experience, I'm probably just too inexperienced, and 
I just keep hitting road blocks and endless frustrations.

I have a lot of free time, and I have a lot of love for this 
language, but when I struggle to get _anything_ to work (and also 
struggle to find something I'm actually capable of trying to do, 
I find Bugzilla a bit hard to use) then it makes me demotivated. 
Maybe I'm missing something, maybe I'm just an idiot, maybe the 
wiki is incorrect, etc. There's clearly _something_ wrong with 
what I'm doing, but I can't bring myself to try and figure out 
what anymore (I say that, but I know full well I'll shortly want 
to try again, and again, and again, until I can finally help out 
with dlang ;( ). I'd like to note that the process of submitting 
the PRs didn't make me run into any issue (though, the changes 
were really simple, so I doubt there was much room for something 
to stop them)

This post may not be all that helpful, but I feel the need to 
voice the frustrations with my experience. Sorry for the 
pointless/off-topic rant.

[1] https://wiki.dlang.org/Building_under_Windows
[2] https://github.com/dlang/dmd/projects/2
[3] https://github.com/dlang/dmd/pull/7781/files
Mar 12 2018
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote:

 This post may not be all that helpful, but I feel the need to 
 voice the frustrations with my experience. Sorry for the 
 pointless/off-topic rant.


Thank you for this post, I found this actually really insightful. 
I'm also (relatively) inexperienced, a Windows user, and I have 
time/motivation for contributing. Your post is very relatable to 
me. But while you actually tried to compile dmd, I kind of pushed 
it aside after seeing how much there is involved in setting it 
up, predicting a big hassle like you describe. I really wish it 
could be as simple as cloning the repository and running a 
command on Windows.
Mar 12 2018
parent reply psychoticRabbit <meagain meagain.com> writes:
On Monday, 12 March 2018 at 19:09:42 UTC, Dennis wrote:

 On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote:

 This post may not be all that helpful, but I feel the need to 
 voice the frustrations with my experience. Sorry for the 
 pointless/off-topic rant.


 Thank you for this post, I found this actually really 
 insightful. I'm also (relatively) inexperienced, a Windows 
 user, and I have time/motivation for contributing. Your post is 
 very relatable to me. But while you actually tried to compile 
 dmd, I kind of pushed it aside after seeing how much there is 
 involved in setting it up, predicting a big hassle like you 
 describe. I really wish it could be as simple as cloning the 
 repository and running a command on Windows.


hey... I have 25+ years experience as a systems administator.

i.e I'm very, very used to doing very complex things. complex, is 
my day at the office.

But even I couldn't get my head around how to compile D from 
source on Windows ;-)

I do have it compling just fine on my freebsd system, and 
multiple different linux's I use. But Windows? Forget it. Someone 
will need to explain in detail how that is actually done - I no 
longer have the patience for working that one out.
Mar 12 2018
parent Meta <jared771 gmail.com> writes:
On Tuesday, 13 March 2018 at 01:23:39 UTC, psychoticRabbit wrote:

 hey... I have 25+ years experience as a systems administator.

 i.e I'm very, very used to doing very complex things. complex, 
 is my day at the office.

 But even I couldn't get my head around how to compile D from 
 source on Windows ;-)

 I do have it compling just fine on my freebsd system, and 
 multiple different linux's I use. But Windows? Forget it. 
 Someone will need to explain in detail how that is actually 
 done - I no longer have the patience for working that one out.


As a counterpoint, I _did_ manage to compile DMD, Phobos and 
Druntime on Windows as a lowly university student using only the 
instructions from the wiki, and I'm no genius. It _is_ possible 
and not very difficult as long as you follow the instructions to 
the letter.

Of course this was also before you needed to have HOST_DC defined 
in your path, and the repo layout was a bit different, but it's 
not an insurmountable problem. And if you run into problems, you 
can come here or go on IRC to ask for help.
Mar 12 2018
prev sibling parent ag0aep6g <anonymous example.com> writes:
On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote:

 I wanted to try and add some colouring[2] to dmd's error 
 messages (sounds easy enough right?), so I have a quick look 
 and see all I need to do is add some backticks around certain 
 parts of the error message[3, as an example]. So I add my 
 backticks into one error I can easily trigger, build it using 
 my powershell script, and then all I see is that an exception 
 (I think it was actually a RangeError) was thrown, and the 
 stack trace was just a bunch of addresses without any text. (I 
 don't have that build of dmd.exe anymore, and most of dmd has 
 been colourised by now, so I can't get an accurate copy-paste 
 of what happened or try to reproduce it.)

 I decided "that's not supposed to happen", and tried to 
 colourise a few other error messages... but I got the exact 
 same result. I try to take an already coloursised error 
 message, copy and paste it to another file, and try again to no 
 avail.

 At that point I decided that it's probably yet another issue 
 with my build environment that I'll have to try an work out, 
 but if I can't even get something 'trivial' such as colouring 
 in messages working without frustration, then I can't be 
 bothered to put in any more effort with trying to do anything 
 else (I'd rather not be stuck only being able to do 
 documentation changes), since, at least in my experience, I'm 
 probably just too inexperienced, and I just keep hitting road 
 blocks and endless frustrations.


If all you did was adding backticks to error messages, you might 
have been hitting issue 18403 [1]. That bug caused Windows DMD to 
crash whenever it tried printing a colored error message. It's 
very possible that you did nothing wrong, and you just had bad 
luck.

When you can't make sense of something like that, posting here in 
the forum is often worthwhile (Learn or General, though; not 
Announce). It's still pretty common that newcomers find bugs. 
More experienced members of the community can help determine if 
you're hitting one. If it's not a bug, they can help fixing 
things on your end.


[1] https://issues.dlang.org/show_bug.cgi?id=18403
Mar 12 2018
prev sibling next sibling parent reply Laeeth Isharc <Laeeth laeeth.com> writes:
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

 On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:

 And this clarifies the source of your confusion. The D 
 programming language is an open source project, not a 
 for-profit company. D is not the language you're looking for.



 week 72 pull requests form 24 contributors were merged on 



 a no-brainer. Contributing to D needs an advanced degree in 
 computer science. Using the information on the D wiki didn't 
 helped me until now to successfully compile and test a fresh 
 copy of dmd or phobos.


Funnily enough, becoming a significant contributor to the 
ecosystem - compiler or Phobos - demonstrably does not require 
even a complete graduation from high school or any industrial 
programming experience.  I know of what I speak, but I don't say 
who as it's not for me to say.

I was in Munich over new year and I asked someone else who has 
been a star contributor how he got involved.  It was really easy 
for him to start contributing, so he did.  But different people 
find different things easy.

You don't need to have subsystem for Linux to use bash.  Just the 
standard git client for Windows is enough.

I agree the Windows experience could be easier upfront.  Still, 
it's better than it used to be and next year it will be better 
again.


because they are organised around different principles.  Yes, the 
pain is upfront with D, and it's not for everyone.  However on 
the basis of rational calculation the pain in learning something 
new is a small part of the total cost of the technology choice 
and for some people by far not the most relevant question.

And it's an advantage in hiring because the D community filters 
for people who have a tolerance for discomfort upfront.

It would be wonderful to be able to wave a wand and make all of 
life's little frustrations disappear.  But in my experience, 
that's not what is possible - one picks from the choices 
available and the new ones one thinks up.  People have a tendency 
to think that leadership has more power to just change things 
then is actually the case.

I'm going to be building standard developer images from scratch 
programmatically.  Transform froma Windows  ISO into  a VM 
image.Maybe I could open source those scripts and then it's 
easier to get to the bottom of any install and build problems and 
one can replicate difficulties.
Mar 11 2018
parent rumbu <rumbu rumbu.ro> writes:
On Monday, 12 March 2018 at 03:11:34 UTC, Laeeth Isharc wrote:

 You don't need to have subsystem for Linux to use bash.  Just 
 the standard git client for Windows is enough.


Happy to find out about this. It's not like using git bash 
everyday on Windows to know this by default.

sh setup.sh
[...]
make -> Command error: undefined switch '-C'
Mar 11 2018
prev sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote:

 On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote:

 And this clarifies the source of your confusion. The D 
 programming language is an open source project, not a 
 for-profit company. D is not the language you're looking for.



 week 72 pull requests form 24 contributors were merged on 



 a no-brainer. Contributing to D needs an advanced degree in 
 computer science. Using the information on the D wiki didn't 
 helped me until now to successfully compile and test a fresh 
 copy of dmd or phobos.


Hey.. I feel your pain.. I like things to be easy too ;-)


world, does not make a lot of sense, really.

It's like comparing my local corner shop to some worldwide 
supermarket chain.

What's the point in going into the local corner shop and 
complaing that they don't stock this or that, but the supermarket 
down the road does. Or complaining that they charge $4 for a loaf 
of bread, when down the road at the supermarket it only costs 
$2.50.

You have to compare apples with apples, not apples with shiny red 
toffee apples ;-)
Mar 11 2018
parent reply rumbu <rumbu rumbu.ro> writes:
On Monday, 12 March 2018 at 04:48:43 UTC, psychoticRabbit wrote:



 D world, does not make a lot of sense, really.

 It's like comparing my local corner shop to some worldwide 
 supermarket chain.


I'm comparing two open source projects, both hosted on github. 
Both available in the same supermarket. It seems that one of them 
is easy to reach to, the other one is on the top shelf and you 
need a forklift to reach it. And when you bring the forklift, you 
find out that you need two additional excavators running on a 
special kind of fuel which is not available in your country.

I'm comparing the contributing experience, because almost every 
time when someone complains about something, is invited to 
contribute himself.
Mar 11 2018
parent psychoticRabbit <meagain meagain.com> writes:
On Monday, 12 March 2018 at 06:13:35 UTC, rumbu wrote:

 I'm comparing two open source projects, both hosted on github. 
 Both available in the same supermarket. It seems that one of 
 them is easy to reach to, the other one is on the top shelf and 
 you need a forklift to reach it. And when you bring the 
 forklift, you find out that you need two additional excavators 
 running on a special kind of fuel which is not available in 
 your country.

 I'm comparing the contributing experience, because almost every 
 time when someone complains about something, is invited to 
 contribute himself.


yeah, but if you know in advance, that you need a fork lift to 
reach it, and that you'll also need two additional excavators 
running on a special kind of fuel, which is not available in your 
country...then..and only then.. are your expectations in line 
with reality ;-)

but people come to D, thinking they can just walk over to the 
shelf and take it.
(because that's often what they are used to).

Some of us are actually used to the very opposite - i.e you 
always have make that extra effort, even to do the most simple 
things. But that effort just seems normal to us.

I agree, there needs to be more middle ground, which both types 
will benefit from in the end.
Mar 11 2018
prev sibling parent psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote:

 I am sure that lots of D members will be quick to point out, 

 source contributors. Now why did you not contribute! /sarcasm



D has only open source contributors.

For that matter, so is Rust (a 1/2 billion $ organisation, at 
least), run by sjw's who will 'attack' (as opposed to 'point 
out') anyone that speaks out against anything. As for cross 
platform, have you tried running Rust in Windows XP?

Anyway.. I'm going back to the sandbox, to play with my own toys.
Mar 11 2018
prev sibling next sibling parent Frank Brassard <frbrass otma.li> writes:
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:

 Because, even the language creators seem to not recognize this, 

 identical. Basically, if my source code doesn't use any .NET 
 framework function, it will compile successfully with dmd 
 without any (major) change.


As an aside, I had to translate a special-use decompression 


of that experience.
Mar 11 2018
prev sibling next sibling parent reply Laeeth Isharc <Laeeth laeeth.com> writes:
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:

 On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote:

 On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote:









 Because, even the language creators seem to not recognize this, 

 identical. Basically, if my source code doesn't use any .NET 
 framework function, it will compile successfully with dmd 
 without any (major) change.


 contact with the D language, but fails to keep his enthusiasm 

 world and Phobos looks like a mess from his point of view.




 lot of D concepts were introduced in the language: local 
 functions, '_' as digit separator, binary literals, ref 
 returns, tuples, templates, immutability. Guess what the next 


 In the same time, D delegates new features (and sometime 
 existing ones) to library implementation, instead of assume 
 them in the language syntax.



 instantly.


It's a good thing not bad that other languages are inspired by 
what works.  Languages aren't in a vicious battle to the death, a 

great!

I don't think D is stagnating at all - on the contrary, it's 
amazing to see the ecosystem flourishing, no matter where you 
look - documentation, adoption, libraries, commercial adoption.

I think it's reasonable to disagree with the strategic decision 
made to move capabilities from compiler to libraries.  But you 
really have to make an argument about why you disagree if you are 
you expect to be persuasive because there is a thought-through 
argument for the choices made, which I am sure you must be 
familiar with.

I don't think it matters much whether you are right about what 

cross-platform is ready because D is quite an ambitious language 
and doesn't need to depend on adoption from any one community to 
continue growing at an impressive rate.  As it happens though, as 
an empirical matter I doubt it.


wrappers for our analytics.  Not that easy for that purpose, from 
what I could see.  Looks like the primitives are stack only, and 
I tried to figure out how to use them elsewhere and gave up 
because it wasn't that easy.



general case.  It's better in many ways, but different and 
unfamiliar and everything unfamiliar is disconcerting in the 
beginning.
Mar 11 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, March 12, 2018 03:31:36 Laeeth Isharc via Digitalmars-d-announce 
wrote:



 general case.  It's better in many ways, but different and
 unfamiliar and everything unfamiliar is disconcerting in the
 beginning.


Yeah, I remember when I was first dealing with D years ago, and the range
stuff that was in there was totally unfamiliar, and it annoyed me, because I
just wanted the iterators that I was familiar with so that I could easily do
what I wanted to do. Granted, it was worse to figure all of that out then,
since the documentation was much worse (e.g. at the time, there was a
compiler bug that made it so that auto return functions did not show up in
the documentation, so all of std.algorithm explicitly listed the return
types, making it downright scary), but still, at the time, I just didn't
want to deal with figuring out the unfamiliar concept, so it annoyed me.
Now, I actually understand ranges and am very glad that they're there, but
as a D newbie, they were annoying, because they were unfamiliar. I think
that I'd approach it all very differently now, since at the time, I was in
college and just generally a far less experienced programmer, but I think
that many of us tend to look for what we expect when learning a new language
or library, and when that's not what we get, it can be disconcerting to
begin with.

Phobos is very unique in its approach with ranges, likely making it a major
learning experience for anyone from any language, but AFAIK, the only
language with a comparable approach in its standard library is C++, and I'd

programmer - at least to begin with. D does things differently, so anyone
learning it is just going to have to expect to deal with a learning curve.
How steep a curve that is is going to depend on the programmer's experience
and background, but it's going to be there regardless.

- Jonathan M Davis
Mar 11 2018
parent reply bachmeier <no spam.net> writes:
On Monday, 12 March 2018 at 05:02:31 UTC, Jonathan M Davis wrote:

 Now, I actually understand ranges and am very glad that they're 
 there, but as a D newbie, they were annoying, because they were 
 unfamiliar.


Ranges are D's monads. The only thing missing is the burrito 
tutorials.
Mar 12 2018
parent reply Void-995 <void995 gmail.com> writes:
On Monday, 12 March 2018 at 10:38:57 UTC, bachmeier wrote:

 On Monday, 12 March 2018 at 05:02:31 UTC, Jonathan M Davis 
 wrote:

 Now, I actually understand ranges and am very glad that 
 they're there, but as a D newbie, they were annoying, because 
 they were unfamiliar.


 Ranges are D's monads. The only thing missing is the burrito 
 tutorials.


I always thought the best spice in D is UFCS. If only there would 
be one for local symbols (but that needs either foundation's 
decision or I need to write my first DIP and do something instead 
of just crying silently into my sleeve). I really found few 
usages for that, like using methods of class on data types that 
stored inside ranges inside that class. Image data being glued to 
each other in different lists like data in SQL among tables. Not 
like an show stopper, but after I rewrote part of my application 
into D - a lot of stuff become so much more elegant and easy to 
read and maintain. UFCS would help with readability in cases like 
I had tons.
Mar 12 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 3/12/18 10:57 AM, Void-995 wrote:

 On Monday, 12 March 2018 at 10:38:57 UTC, bachmeier wrote:

 On Monday, 12 March 2018 at 05:02:31 UTC, Jonathan M Davis wrote:

 Now, I actually understand ranges and am very glad that they're 
 there, but as a D newbie, they were annoying, because they were 
 unfamiliar.


 Ranges are D's monads. The only thing missing is the burrito tutorials.


 
 I always thought the best spice in D is UFCS. If only there would be one 
 for local symbols (but that needs either foundation's decision or I need 
 to write my first DIP and do something instead of just crying silently 
 into my sleeve).


alias I(alias X) = X;

void main()
{
    int y = 5;
    int bar(int x) { return y * x; }
    // auto z = 6.bar; // error
    auto z = 6.I!bar; // OK
}

https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/

-Steve
Mar 16 2018
parent reply Void-995 <void995 gmail.com> writes:
On Friday, 16 March 2018 at 15:58:25 UTC, Steven Schveighoffer 
wrote:

 On 3/12/18 10:57 AM, Void-995 wrote:

 On Monday, 12 March 2018 at 10:38:57 UTC, bachmeier wrote:

 On Monday, 12 March 2018 at 05:02:31 UTC, Jonathan M Davis 
 wrote:

 Now, I actually understand ranges and am very glad that 
 they're there, but as a D newbie, they were annoying, 
 because they were unfamiliar.


 Ranges are D's monads. The only thing missing is the burrito 
 tutorials.


 
 I always thought the best spice in D is UFCS. If only there 
 would be one for local symbols (but that needs either 
 foundation's decision or I need to write my first DIP and do 
 something instead of just crying silently into my sleeve).


 alias I(alias X) = X;

 void main()
 {
    int y = 5;
    int bar(int x) { return y * x; }
    // auto z = 6.bar; // error
    auto z = 6.I!bar; // OK
 }

 https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/

 -Steve


Every time I'm thinking that something is impossible to be 
elegantly and/or easily done even in D - someone proves me wrong.

And common, I just had that little spark of motivation to look 
into DMD, what is my purpose in life now?
Mar 16 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, March 16, 2018 21:37:44 Void-995 via Digitalmars-d-announce 
wrote:

 Every time I'm thinking that something is impossible to be
 elegantly and/or easily done even in D - someone proves me wrong.

 And common, I just had that little spark of motivation to look
 into DMD, what is my purpose in life now?


Fan it into flames and go learn it so that you can fix or improve other
stuff that might come up? ;)

Of course, depending on what you know and are interested in, doing stuff
like writing useful libraries and putting them up on code.dlang.org can be
of huge benefit even if you never do anything for dmd, druntime, or Phobos.
In some ways, that's probably our biggest need. But regardless, if you're
interested in helping out the D ecosystem, there are plenty of options.

- Jonathan M Davis
Mar 16 2018
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/11/2018 11:31 PM, Laeeth Isharc wrote:

 



I wonder if that might open the door for D on the CLR. I know that was 
attempted once a long way back, but was deemed infeasible and abandoned. 
IIRC, inability to implement slices was the main blocker.
Mar 13 2018
parent reply rumbu <rumbu rumbu.ro> writes:
On Tuesday, 13 March 2018 at 23:20:22 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 03/11/2018 11:31 PM, Laeeth Isharc wrote:

 



 I wonder if that might open the door for D on the CLR. I know 
 that was attempted once a long way back, but was deemed 
 infeasible and abandoned. IIRC, inability to implement slices 
 was the main blocker.



since .net framework 2.0 (2006), which is exactly a slice, but 
doesn't have the syntactic sugar for it.


(using ":" instead of "..") and extends the concept to stack 
arrays, because ArraySegment was limited to managed arrays.

As I remember one of the main blockers was in fact the module
Mar 13 2018
parent reply flamencofantasy <flamencofantasy gmail.com> writes:
On Wednesday, 14 March 2018 at 05:22:53 UTC, rumbu wrote:



 ArraySegment<T> since .net framework 2.0 (2006), which is 
 exactly a slice, but doesn't have the syntactic sugar for it.


If it doesn't have the syntactic sugar how is it "exactly a 
slice"?



 D (using ":" instead of "..") and extends the concept to stack 
 arrays, because ArraySegment was limited to managed arrays.


If it's limited to managed arrays how is it "exactly a slice"?

Please stop repeating this fallacy, I have already corrected you 
once in another thread where you made the same claim about 

ArraySegment<T> has very little in common with a D slice.
It is a segment of an array of type T only! That's it!
You can't construct it from stack, static, native, memory-mapped 
or any other memory, and you can't coerce the type. Because it 
doesn't have the 'syntactic sugar' it is unusable for all 
practical purposes!
Mar 15 2018
parent rumbu <rumbu rumbu.ro> writes:
On Thursday, 15 March 2018 at 21:10:47 UTC, flamencofantasy wrote:

 On Wednesday, 14 March 2018 at 05:22:53 UTC, rumbu wrote:



 ArraySegment<T> since .net framework 2.0 (2006), which is 
 exactly a slice, but doesn't have the syntactic sugar for it.


 If it doesn't have the syntactic sugar how is it "exactly a 
 slice"?


This was about the fact that slices were a stopper for a D .net 
implementation.

The direct translation of the code here 
(https://dlang.org/articles/d-array-article.html#introducing-slices) is:

int[] a = new int[5];
var b = new ArraySegment<int>(a, 0, 2);
var c = new ArraySegment<int>(a, 3, 2);
c[0] = 4;
c[1] = 5;
c.CopyTo(b);

Surprise, the a content is the same as in D - [4,5,0,4,5].

I will stop my fallacy here, I promise this is the last post 
bragging about array segments, I feel some tension piling up on D 
forums and I don't want to contribute to it. My mistake was the 
use of the word "exactly".
Mar 15 2018
prev sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 12 March 2018 at 03:31:36 UTC, Laeeth Isharc wrote:





could get stuff done 20 years ago already, ugly slices and native 
compilation won't add anything to it.






No, FWIW phobos uses more or less the same programming solutions 
as .net framework, the claim that they are different is an 
uninformed opinion.
Mar 15 2018
parent reply rumbu <rumbu rumbu.ro> writes:
On Thursday, 15 March 2018 at 12:23:19 UTC, Kagamin wrote:

 No, FWIW phobos uses more or less the same programming 
 solutions as .net framework, the claim that they are different 
 is an uninformed opinion.


Are you sure that you are talking about phobos and not tango? :)
I'm eager to find how I'm uninformed.
Mar 15 2018
parent reply Kagamin <spam here.lot> writes:
On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:

 Are you sure that you are talking about phobos and not tango? :)
 I'm eager to find how I'm uninformed.


Tango doesn't use UFCS, while phobos and .net framework are big 
on extension methods. Also tango uses object oriented console IO, 
while phobos and .net framework use procedural style for it.
Mar 16 2018
next sibling parent reply Tony <tonytdominguez aol.com> writes:
On Friday, 16 March 2018 at 15:04:21 UTC, Kagamin wrote:

 On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:

 Are you sure that you are talking about phobos and not tango? 
 :)
 I'm eager to find how I'm uninformed.


 Tango doesn't use UFCS, while phobos and .net framework are big 
 on extension methods. Also tango uses object oriented console 
 IO, while phobos and .net framework use procedural style for it.
Mar 16 2018
next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/16/2018 02:35 PM, Tony wrote:

 On Friday, 16 March 2018 at 15:04:21 UTC, Kagamin wrote:

 On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:

 Are you sure that you are talking about phobos and not tango? :)
 I'm eager to find how I'm uninformed.


 Tango doesn't use UFCS, while phobos and .net framework are big on 
 extension methods. Also tango uses object oriented console IO, while 
 phobos and .net framework use procedural style for it.


 


 


It doesn't (last I used it), buy you CAN mark individual member 
functions to be usable UFCS-like. IIRC, I think it might have to be 
static member function.

It's been awhile, so I don't remember it exactly, but it's something 
like this:

class Bar {}

class Foo {
     static void SomeFunc(extention Bar bar, int num) {...}
}

class MyApp {
     static void Run() {
         Bar bar = new Bar();
         bar.SomeFunc(2);
     }
}
Mar 16 2018
parent bauss <jj_1337 live.dk> writes:
On Friday, 16 March 2018 at 19:08:47 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 03/16/2018 02:35 PM, Tony wrote:

 On Friday, 16 March 2018 at 15:04:21 UTC, Kagamin wrote:

 On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:

 Are you sure that you are talking about phobos and not 
 tango? :)
 I'm eager to find how I'm uninformed.


 Tango doesn't use UFCS, while phobos and .net framework are 
 big on extension methods. Also tango uses object oriented 
 console IO, while phobos and .net framework use procedural 
 style for it.


 


 


 It doesn't (last I used it), buy you CAN mark individual member 
 functions to be usable UFCS-like. IIRC, I think it might have 
 to be static member function.

 It's been awhile, so I don't remember it exactly, but it's 
 something like this:

 class Bar {}

 class Foo {
     static void SomeFunc(extention Bar bar, int num) {...}
 }

 class MyApp {
     static void Run() {
         Bar bar = new Bar();
         bar.SomeFunc(2);
     }
 }


Actually it's like:

static void SomeFunc(this Bar bar, int num) { ... }
Mar 17 2018
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 16 March 2018 at 18:35:14 UTC, Tony wrote:





Well, this is not IO, but:

public struct DivInt
{   public int quot;
     public int rem;
}

public static class Utility
{   public static DivInt Div(this int dividee, int divisor)
     {   int quot;
         int rem;
         quot = Math.DivRem(dividee, divisor, out rem);

         //always round down
         if(rem < 0)
         {   quot--;
             rem += divisor;
         }
         return new DivInt{quot = quot, rem = rem};
     }
}

Could be used in some way like:
     int quotient;
     int remainder;
     if (true)
     {   var divResult = (x + y).Div(ASlowFunction());
         quotient = divResult.quot;
         remainder = divResult.rem;
     }


If you say it sucks that one has to declare an utility class just 
to be nominally object-oriented, I agree.
Mar 16 2018
prev sibling parent Kagamin <spam here.lot> writes:
On Friday, 16 March 2018 at 18:35:14 UTC, Tony wrote:





All methods of Console class.
Mar 19 2018
prev sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Friday, 16 March 2018 at 15:04:21 UTC, Kagamin wrote:

 On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:

 Are you sure that you are talking about phobos and not tango? 
 :)
 I'm eager to find how I'm uninformed.


 Tango doesn't use UFCS, while phobos and .net framework are big 
 on extension methods. Also tango uses object oriented console 
 IO, while phobos and .net framework use procedural style for it.



Do you know anything else in the .net library than LINQ where 
extension methods (somehow equivalent to UFCS) are abused? I 
thought that something happened in the .net world while I was 
asleep, that's why I just searched my local copy of .net core and 
there are exactly 198 extension methods. I would not call these 
"big".

The Tango remark was just a pun (R.I.P.), since it looked 90% 
similar to .net. And what would make Tango unusable with UFCS? Is 
it not written in D?

Last time I checked, .net Console was an enormous static class 
with three Stream objects behind the scenes.

When I said that phobos looks like a mess compared to .net lib I 
referred especially to the poor choice of names (eg. RedBlackTree 
vs SortedDictionary) and lack of essential stuff (eg. happy to 
have levenshteinDistance built in, but I cannot sort correctly 
two strings in any other language than English).
Mar 16 2018
parent Kagamin <spam here.lot> writes:
On Friday, 16 March 2018 at 21:38:30 UTC, rumbu wrote:

 Do you know anything else in the .net library than LINQ where 
 extension methods (somehow equivalent to UFCS) are abused? I 
 thought that something happened in the .net world while I was 
 asleep, that's why I just searched my local copy of .net core 
 and there are exactly 198 extension methods. I would not call 
 these "big".


It's big because linq is perceptionally big in itself similar to 

want a complex interface method with simplified overloads, you 
don't declare interface with many overloads, you declare one 
interface method that takes all parameters and a number of 
simplified extension methods that forward to interface, Unity 
container and Rhino mocks are designed this way.


 Last time I checked, .net Console was an enormous static class 
 with three Stream objects behind the scenes.


That's also how D console IO works.


 When I said that phobos looks like a mess compared to .net lib 
 I referred especially to the poor choice of names (eg. 
 RedBlackTree vs SortedDictionary) and lack of essential stuff 
 (eg. happy to have levenshteinDistance built in, but I cannot 
 sort correctly two strings in any other language than English).


That's true, naming is a little complex.
Mar 19 2018
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:



 instantly.



feeling: The day D will easily compile to Javascript and be able 


D!

It can already compile to Javascript using LDC/Emscripten, which 
is impressive, but you cannot interface with its strings and 
classes without glue code, except perhaps with some trickery. I 
have already tried doing some but so far for no avail.


hesistate to pick it over writing Javascript directly, and I 
don't think Java or Python would be superior for my tastes 
either. But it still isn't even a close match against D.


wants to maintain an ivory tower illusion. It's very hard, if 
possible at all, to control memory management. Libraries often 
feel like they're dependant on IDE (Visual Studio), not just the 
language.


but it still is like Phobos with only forward ranges, strange 
names and no thought put on avoiding needless heap allocations. 
And it's foreach loop can't iterate by ref, which means I often 
tend to iterate as if I was using C.

Third, expressive power suffers alot from lack of powerful 
templates, Voldemort types and var keyword being much more 
constrained in use than auto.
Mar 15 2018
parent reply rumbu <rumbu rumbu.ro> writes:
On Thursday, 15 March 2018 at 17:17:47 UTC, Dukc wrote:

 On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:



 instantly.



 feeling: The day D will easily compile to Javascript and be 


 -BetterC D!

 It can already compile to Javascript using LDC/Emscripten, 
 which is impressive, but you cannot interface with its strings 
 and classes without glue code, except perhaps with some 
 trickery. I have already tried doing some but so far for no 
 avail.


 hesistate to pick it over writing Javascript directly, and I 
 don't think Java or Python would be superior for my tastes 
 either. But it still isn't even a close match against D.


 wants to maintain an ivory tower illusion. It's very hard, if 
 possible at all, to control memory management. Libraries often 
 feel like they're dependant on IDE (Visual Studio), not just 
 the language.


 LINQ, but it still is like Phobos with only forward ranges, 
 strange names and no thought put on avoiding needless heap 
 allocations. And it's foreach loop can't iterate by ref, which 
 means I often tend to iterate as if I was using C.

 Third, expressive power suffers alot from lack of powerful 
 templates, Voldemort types and var keyword being much more 
 constrained in use than auto.




this is the main reason: native compilation (and this includes 

implementing D specific ideas in each new version, so don't be 
surprised if your list of D exclusive features becomes smaller 

drops features or push them into library solutions.
Mar 15 2018
parent reply psychoticRabbit <meagain meagain.com> writes:
On Thursday, 15 March 2018 at 18:39:08 UTC, rumbu wrote:



 this is the main reason: native compilation (and this includes 

 keep implementing D specific ideas in each new version, so 
 don't be surprised if your list of D exclusive features becomes 

 that D drops features or push them into library solutions.


That was me ;-)

Yeah..native compilation is so nice..it's hard to resist.
And so is a good GC implementation (does D have one of those ??)


essentially native compiled anyway. When I run some of my java 
programs, I still don't know how 'native compilation' would make 

apps..they just fly...native compilation wouldn't add much.


forklift or two - as opposed to taking it off the nearby shelf.

-------------
using System;
using System.IO;

public class Program
{
     public static int Main()
     {
         int[] arr = { 1, 2, 3, 4, 5 };
         int[] sliceOfArr = arr.Slice(2, 3);

         Console.WriteLine(string.Join(", ", arr));
         Console.WriteLine(string.Join(", ", sliceOfArr));

         return 0;
     }
}

public static class Utils
{
     public static T[] Slice<T>(this T[] arr, int start, int len)
     {
         T[] slice  = new T[len];
         Array.Copy(arr, start, slice, 0, len);
         return slice;
     }
}
------------
Mar 15 2018
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Friday, 16 March 2018 at 01:45:57 UTC, psychoticRabbit wrote:

 On Thursday, 15 March 2018 at 18:39:08

 public static class Utils
 {
     public static T[] Slice<T>(this T[] arr, int start, int len)
     {
         T[] slice  = new T[len];
         Array.Copy(arr, start, slice, 0, len);
         return slice;
     }
 }


Playing captain the obvious but this is COPY not slice. Slices in 

as special Span<T> class that may point to GC heap or off-heap 
memory.

D had slices since 2000s, pointing to any kind of memory.
Mar 16 2018
parent psychoticRabbit <meagain meagain.com> writes:
On Friday, 16 March 2018 at 07:58:33 UTC, Dmitry Olshansky wrote:

 Playing captain the obvious but this is COPY not slice.


Shh. Don't tell my customers that.



 D had slices since 2000s, pointing to any kind of memory.


Mmm..D showing off.. as always ;-)
Mar 16 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/10/2018 05:47 AM, Dylan Graham wrote:

 On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:

 According to the State of D Survey, 71% of the respondents don't care 
 about betterC. Why is betterC on the priority list?


 
 Yeah. Why should D worry about tying itself into C when it can't even 
 interface with itself through DLLs?


First of all, betterC is about far more than interfacing with C. In 
fact, interop with C isn't really what betterC is about at all - that's 
a separate aspect of the language. (And those C/C++ users who still 
haven't come to D - for many of them the holdout is *because* of the 
issues betterC aims to address. Make no mistake, for all the stockholm 
syndrome in the C and C++ worlds, there *are* a lot people openly 
wanting to jump ship but don't have a sufficient option yet. Heck, *I'm* 
a C/C++ -> D convert.)

But more importantly:

The D language itself is specifically designed and intended to be 
multi-purpose. Because of that, D users (and potential D users) are 
*highly* diverse. Everybody here has their own use-cases, their own 
needs and priorities, and their own list of things they want fixed 
yesterday.

In a group this diverse, there just simply *isn't* much on the D 
wishlist that's crucially important to a *majority*, because we all need 
completely different things.

Personally, better DLL support have little to no impact on me. Obviously 
it does for you, and I sympathise. Some of the things most important to 
me for D to improve you probably wouldn't care one bit about - and 
that's ok. We work on different sorts of things.

Improved betterC is something I would find very nice if I ever have time 
or opportunity to get back into embedded software. But outside of that, 
yea, it doesn't impact me much more than it does for you.

But here's the rub: In this crowd here, probably far more than most 
languages, we all have such wildly varying needs that 29% *is* what 
qualifies as significant around here. Most wishlist items are going to 
have similarly non-majority numbers. And they have to pick *something* 
to focus on. Luckily, as the vision document clearly states, there are 
*several* such "somethings" the dlang foundation is committing to 
working on.
Mar 10 2018
next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
IMO this should be the priority:

1. blockers (things that can't be worked around at all or not without
jumping through a lot of hoops)
2. everything else

dmd still doesn't support shared libraries on OSX (cf
https://issues.dlang.org/show_bug.cgi?id=12190)

That prevents a whole category of use cases (eg D plugins called from
C++ or from D)





On Sat, Mar 10, 2018 at 8:06 PM, Nick Sabalausky (Abscissa) via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On 03/10/2018 05:47 AM, Dylan Graham wrote:

 On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:

 According to the State of D Survey, 71% of the respondents don't care
 about betterC. Why is betterC on the priority list?



 Yeah. Why should D worry about tying itself into C when it can't even
 interface with itself through DLLs?



 First of all, betterC is about far more than interfacing with C. In fact,
 interop with C isn't really what betterC is about at all - that's a separate
 aspect of the language. (And those C/C++ users who still haven't come to D -
 for many of them the holdout is *because* of the issues betterC aims to
 address. Make no mistake, for all the stockholm syndrome in the C and C++
 worlds, there *are* a lot people openly wanting to jump ship but don't have
 a sufficient option yet. Heck, *I'm* a C/C++ -> D convert.)

 But more importantly:

 The D language itself is specifically designed and intended to be
 multi-purpose. Because of that, D users (and potential D users) are *highly*
 diverse. Everybody here has their own use-cases, their own needs and
 priorities, and their own list of things they want fixed yesterday.

 In a group this diverse, there just simply *isn't* much on the D wishlist
 that's crucially important to a *majority*, because we all need completely
 different things.

 Personally, better DLL support have little to no impact on me. Obviously it
 does for you, and I sympathise. Some of the things most important to me for
 D to improve you probably wouldn't care one bit about - and that's ok. We
 work on different sorts of things.

 Improved betterC is something I would find very nice if I ever have time or
 opportunity to get back into embedded software. But outside of that, yea, it
 doesn't impact me much more than it does for you.

 But here's the rub: In this crowd here, probably far more than most
 languages, we all have such wildly varying needs that 29% *is* what
 qualifies as significant around here. Most wishlist items are going to have
 similarly non-majority numbers. And they have to pick *something* to focus
 on. Luckily, as the vision document clearly states, there are *several* such
 "somethings" the dlang foundation is committing to working on.
Mar 10 2018
prev sibling next sibling parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 03/10/2018 05:47 AM, Dylan Graham wrote:

 On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:

 According to the State of D Survey, 71% of the respondents 
 don't care about betterC. Why is betterC on the priority list?


 
 Yeah. Why should D worry about tying itself into C when it 
 can't even interface with itself through DLLs?


 First of all, betterC is about far more than interfacing with 
 C. In fact, interop with C isn't really what betterC is about 
 at all - that's a separate aspect of the language. (And those 
 C/C++ users who still haven't come to D - for many of them the 
 holdout is *because* of the issues betterC aims to address. 
 Make no mistake, for all the stockholm syndrome in the C and 
 C++ worlds, there *are* a lot people openly wanting to jump 
 ship but don't have a sufficient option yet. Heck, *I'm* a 
 C/C++ -> D convert.)

 But more importantly:

 The D language itself is specifically designed and intended to 
 be multi-purpose. Because of that, D users (and potential D 
 users) are *highly* diverse. Everybody here has their own 
 use-cases, their own needs and priorities, and their own list 
 of things they want fixed yesterday.

 In a group this diverse, there just simply *isn't* much on the 
 D wishlist that's crucially important to a *majority*, because 
 we all need completely different things.

 Personally, better DLL support have little to no impact on me. 
 Obviously it does for you, and I sympathise. Some of the things 
 most important to me for D to improve you probably wouldn't 
 care one bit about - and that's ok. We work on different sorts 
 of things.

 Improved betterC is something I would find very nice if I ever 
 have time or opportunity to get back into embedded software. 
 But outside of that, yea, it doesn't impact me much more than 
 it does for you.

 But here's the rub: In this crowd here, probably far more than 
 most languages, we all have such wildly varying needs that 29% 
 *is* what qualifies as significant around here. Most wishlist 
 items are going to have similarly non-majority numbers. And 
 they have to pick *something* to focus on. Luckily, as the 
 vision document clearly states, there are *several* such 
 "somethings" the dlang foundation is committing to working on.


You do have a good point. One of my likes for D was its 
flexibility, so it was very hypocritical of me to argue for what 
I did.

I regret some of things I said. I'm sorry for any offence caused, 
specifically towards members of the DLF.

I wish that DLL support was referenced in the vision document. I 
actually like most of what's been said in it, especially the 
 safe,  nogc and editor support. I also see Benjamin Thaut (if 
you're reading this - awesome work!) making progress on DLL 
support, I just wish the foundation could help him out a bit.
Mar 10 2018
parent psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 05:41:02 UTC, Dylan Graham wrote:

 I regret some of things I said. I'm sorry for any offence 
 caused, specifically towards members of the DLF.


I don't think you need to regret saying anything. You've 
demonstrated a willingness to engage in a conversation that we 
can *all* learn from.

I also doubt anyone actually got offended ;-)

.. we're all pretty strong minded here.

But I get back to my point about "programmer" portability.

Other developers of newer languages just don't seem to get that.

And it's hardly surprising that D would be focused in some way, 
on languages used by the vast majority of programmers 


That is D's great strength. (and betterc is just a part of it - 
and not one that particulary interests me).

Because D resources are rather contstrained, betterc gets more 
push back than it really should. But the main take away point I 
get from that vision statement, is a greater focus on increasing 
contributions - which is really what D needs more than anything 
(apart from a correct and complete language specification).
Mar 10 2018
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
(Abscissa) wrote:

 First of all, betterC is about far more than interfacing with 
 C. In fact, interop with C isn't really what betterC is about 
 at all - that's a separate aspect of the language. (And those 
 C/C++ users who still haven't come to D - for many of them the 
 holdout is *because* of the issues betterC aims to address.


What is that issue? Runtime? It can be solved with minimal 
runtime that one can write in an evening, compare it to betterC 
effort that has no end in sight.


 Make no mistake, for all the stockholm syndrome in the C and 
 C++ worlds, there *are* a lot people openly wanting to jump 
 ship but don't have a sufficient option yet.


I'm afraid a sufficient option for them is proper C++ superset, 
betterC is only the first excuse, but not last.


 Personally, better DLL support have little to no impact on me. 
 Obviously it does for you, and I sympathise.


FWIW DLL support was always good enough for me.
Mar 15 2018
next sibling parent timotheecour <timothee.cour2 gmail.com> writes:
On Thursday, 15 March 2018 at 09:05:52 UTC, Kagamin wrote:

 On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
 (Abscissa) wrote:

 First of all, betterC is about far more than interfacing with 
 C. In fact, interop with C isn't really what betterC is about 
 at all - that's a separate aspect of the language. (And those 
 C/C++ users who still haven't come to D - for many of them the 
 holdout is *because* of the issues betterC aims to address.


 What is that issue? Runtime? It can be solved with minimal 
 runtime that one can write in an evening, compare it to betterC 
 effort that has no end in sight.


 Make no mistake, for all the stockholm syndrome in the C and 
 C++ worlds, there *are* a lot people openly wanting to jump 
 ship but don't have a sufficient option yet.


 I'm afraid a sufficient option for them is proper C++ superset, 
 betterC is only the first excuse, but not last.


 Personally, better DLL support have little to no impact on me. 
 Obviously it does for you, and I sympathise.


 FWIW DLL support was always good enough for me.


indeed, fixing DLL support (eg on OSX, where they're broken) is 
arguably more important (and less effort, given the larger scope 
of betterC) than betterC, as you can integrate D and C (or C++) 
projects via DLL's.
Whereas betterC does solve integrating C/C++ with D (eg requires 
C++ code to be ported to D which betterC doesn't magically do)
Mar 15 2018
prev sibling parent reply Radu <void null.pt> writes:
On Thursday, 15 March 2018 at 09:05:52 UTC, Kagamin wrote:

 On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
 (Abscissa) wrote:

 First of all, betterC is about far more than interfacing with 
 C. In fact, interop with C isn't really what betterC is about 
 at all - that's a separate aspect of the language. (And those 
 C/C++ users who still haven't come to D - for many of them the 
 holdout is *because* of the issues betterC aims to address.


 What is that issue? Runtime? It can be solved with minimal 
 runtime that one can write in an evening, compare it to betterC 
 effort that has no end in sight.


 Make no mistake, for all the stockholm syndrome in the C and 
 C++ worlds, there *are* a lot people openly wanting to jump 
 ship but don't have a sufficient option yet.


 I'm afraid a sufficient option for them is proper C++ superset, 
 betterC is only the first excuse, but not last.


 Personally, better DLL support have little to no impact on me. 
 Obviously it does for you, and I sympathise.


 FWIW DLL support was always good enough for me.


It is much more than runtime or no runtime.

First of all, that goal (better interoperability) has been on the 
foundation priority list for several years, it is about time to 
"finish it up".

You have to remember that the really big first client of 
betterC(++) was DMD, porting DMD from C++ was a big undertaking. 
Right now both DMD and LDC use a form of betterC, so it is 
critical to have it finalized.

Second, it is a really good tool for validating a constraint 
environment, running D code with minimal runtime and compiler 
guarantees is very good thing to have in a system level 
programming language.

Third, since it was introduced, it really helped better 
abstracting compiler internals and removing dependencies between 
compiler and runtime. People don't solve problems they don't 
have, hence introducing a new restriction added some stress that 
shaped a better version of D. As stated, D is a *system level 
programming language*, this means that ultimately needs to offer 
tools for embedded developers and OS kernel driver writers. 
betterC is one of those tools, and ultimately is part of the 
philosophy of pay-as-you-go, or a driving force to be better at 
it. Also, I think it fits nicely into "turtles all the way down" 
approach, as it makes the language orthogonal and more glued 
together vs. offering some vague advice on how to approach 
constraint systems, it provides rules and methods of enforcement.

Lastly, the objective is a bit vague - there is no scope attached 
to it, maybe this needs clarifications. Even if it means fixing 
all the logged bugs related to it, it is a great step, at least 
for me.
Mar 15 2018
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/15/2018 3:48 AM, Radu wrote:

 Lastly, the objective is a bit vague - there is no scope attached to it, maybe 
 this needs clarifications. Even if it means fixing all the logged bugs related 
 to it, it is a great step, at least for me.


For reference, here are all the betterC bugs:

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=betterC%2C%20&keywords_type=allwords&list_id=220294&query_format=advanced

If there are any betterC bugs filed in Bugzilla and not listed there, please
tak 
them with the "betterC" keyword so they will be. Any unfiled bugs => file them, 
of course!
Mar 16 2018
prev sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote:

 You have to remember that the really big first client of 
 betterC(++) was DMD, porting DMD from C++ was a big 
 undertaking. Right now both DMD and LDC use a form of betterC, 
 so it is critical to have it finalized.


This is entirely wrong. DMD and LDC rely extern(C++), but this 
has nothing to do with -betterC whatsoever.

Both compilers link and initialise the runtime as normal (and 
then disable the GC at runtime).

  — David
Mar 16 2018
parent reply Radu <void null.pt> writes:
On Friday, 16 March 2018 at 18:15:02 UTC, David Nadlinger wrote:

 On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote:

 You have to remember that the really big first client of 
 betterC(++) was DMD, porting DMD from C++ was a big 
 undertaking. Right now both DMD and LDC use a form of betterC, 
 so it is critical to have it finalized.


 This is entirely wrong. DMD and LDC rely extern(C++), but this 
 has nothing to do with -betterC whatsoever.

 Both compilers link and initialise the runtime as normal (and 
 then disable the GC at runtime).

  — David


I stand corrected. I remembered something about druntime being 
used but last time I checked front end code was filled with 
strcpm and strlen, wrongly assumed that druntime was not used. Oh 
well...

Still, probably D compilers will benefit from fixing mangling 
bugs and allow more integration with C++ std, right?
Mar 18 2018
parent Joakim <dlang joakim.fea.st> writes:
On Sunday, 18 March 2018 at 10:28:58 UTC, Radu wrote:

 On Friday, 16 March 2018 at 18:15:02 UTC, David Nadlinger wrote:

 On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote:

 You have to remember that the really big first client of 
 betterC(++) was DMD, porting DMD from C++ was a big 
 undertaking. Right now both DMD and LDC use a form of 
 betterC, so it is critical to have it finalized.


 This is entirely wrong. DMD and LDC rely extern(C++), but this 
 has nothing to do with -betterC whatsoever.

 Both compilers link and initialise the runtime as normal (and 
 then disable the GC at runtime).

  — David


 I stand corrected. I remembered something about druntime being 
 used but last time I checked front end code was filled with 
 strcpm and strlen, wrongly assumed that druntime was not used. 
 Oh well...


You're not completely wrong about this: the dmd frontend uses 
almost nothing from druntime, not counting extern(C) declarations 
that are really from the local libc, and nothing from Phobos. 
However, I think it still requires druntime to be linked against 
because of some compiler-generated symbols and the like.  Also, 
LDC using the D frontend has allowed a few Phobos dependencies to 
creep in.

So where you were wrong is in saying dmd/ldc use betterC, which 
is an extreme that precludes linking against druntime or Phobos 
at all, though you could still use extern(C) declarations alone 
from the stdlib. What you may have been thinking of is Walter's 
plan to move the dmd backend to D written with betterC, because 
he'd like to use that same D backend with his C/C++ compiler 
frontends written in C/C++ and he wants to dogfood betterC there.

You weren't wrong that the dmd frontend is very much written in a 
betterC style, it just isn't fully usable with betterC yet.


 Still, probably D compilers will benefit from fixing mangling 
 bugs and allow more integration with C++ std, right?


Sure, David was simply pointing out that the betterC and 
extern(C++) efforts are orthogonal and that one doesn't imply the 
other: the ddmd frontend is an example of this, extensively using 
extern(C++) but not enabling betterC.
Mar 18 2018
prev sibling parent Greatsam4sure <greatsamsure gmail.com> writes:
On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 03/10/2018 05:47 AM, Dylan Graham wrote:

 On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:

 According to the State of D Survey, 71% of the respondents 
 don't care about betterC. Why is betterC on the priority list?


 
 Yeah. Why should D worry about tying itself into C when it 
 can't even interface with itself through DLLs?


 First of all, betterC is about far more than interfacing with 
 C. In fact, interop with C isn't really what betterC is about 
 at all - that's a separate aspect of the language. (And those 
 C/C++ users who still haven't come to D - for many of them the 
 holdout is *because* of the issues betterC aims to address. 
 Make no mistake, for all the stockholm syndrome in the C and 
 C++ worlds, there *are* a lot people openly wanting to jump 
 ship but don't have a sufficient option yet. Heck, *I'm* a 
 C/C++ -> D convert.)

 But more importantly:

 The D language itself is specifically designed and intended to 
 be multi-purpose. Because of that, D users (and potential D 
 users) are *highly* diverse. Everybody here has their own 
 use-cases, their own needs and priorities, and their own list 
 of things they want fixed yesterday.

 In a group this diverse, there just simply *isn't* much on the 
 D wishlist that's crucially important to a *majority*, because 
 we all need completely different things.

 Personally, better DLL support have little to no impact on me. 
 Obviously it does for you, and I sympathise. Some of the things 
 most important to me for D to improve you probably wouldn't 
 care one bit about - and that's ok. We work on different sorts 
 of things.

 Improved betterC is something I would find very nice if I ever 
 have time or opportunity to get back into embedded software. 
 But outside of that, yea, it doesn't impact me much more than 
 it does for you.

 But here's the rub: In this crowd here, probably far more than 
 most languages, we all have such wildly varying needs that 29% 
 *is* what qualifies as significant around here. Most wishlist 
 items are going to have similarly non-majority numbers. And 
 they have to pick *something* to focus on. Luckily, as the 
 vision document clearly states, there are *several* such 
 "somethings" the dlang foundation is committing to working on.




The D language is a marvel. It just nice using it. It is a 
superior language.
It is pure joy programming in D. D language is mature enough to 
write up to 90% of all form of application. The problem I have 
seen thus far is the tools. The tools don't work especially on 
Windows.


The only working ide on Windows is visual-D but tied to visual 
studio. Personally don't like visual studio, it look to old for 
my likely. The plugin for eclipse,visual studio code and intellij 
are really lacking behind.


I having trying to setup code-d up in vs code for more than six 
months now to get auto completion but to no success. I have spent 
countless hours on the internet search for a solution but did not 
find any. I just get all kinds of errors. My next plane is to by 
a Linux system. So to me D is a beautiful language with no 
beautiful tools so not usable to me yet.

All you need to set up dmd on Windows is to download it and 
install.it is less than 2mins, you are good to go. Running your 
code in command line is painless with dub. But who want to write 
a millions of lines of code using plan text editors without code 
hinting, auto complete and superior debuging?

I love D language so much. The language is true mature now. Fix 
the following problem

* Get the plugin for intellij, eclipse and vs code working 
especially on Windows
* Proper documentation for the various packages and library
*Make installation process as easy as installing dmd
*Books that touch all capability of the D langauge with real like 
application. Programming in D is good but it must be enchance 
further


D language must be easy to program on all pupular ide. All you 


in vs code? I have no reason. Good language with good tools- 
anybody will give it a trier


Walter and all the team have done a good job. But give me more 
pride to sell D to all my colleagues. Programmers are known to be 
proud of their language, they must have very good reasons to 
switch. People switch from one languge to another because the new 
language just easy their pain.

All the members of the D community must come together and face 
really and work together to move the language further to make D 
the number one langauge which is what D supposed to be.


Working individually have move us here but working collectively 
will definitely make us the best. We must give people on all 
platform- windows, Mac, Linux,intellij,exclipse, netbeam,vs code, 
visual studio etc good reasons to use D besides the beaulty and 
power of the language.

Love D and all involves
Mar 17 2018
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


 According to the State of D Survey, 71% of the respondents 
 don't care about betterC. Why is betterC on the priority list?


1. The vision document was started before the survey and the 
survey isn't closed, so the survey results don't factor into it 
yet.

2. The survey results will serve as a set of guidelines for 
future directions, not as a set of absolute directives. It wasn't 
a controlled survey and it doesn't reflect the entire D community.

3. Work on BetterC was started a long time ago and isn't going to 
be abandoned over night.

If something shows up as high priority in the survey, then it 
makes sense to evaluate its impact and see how we can devote more 
resources to it going forward. If something shows up as low 
priority, then we have to take a number of factors into account, 
(e.g. Is it being worked on already? Are there commercial 
interests who *do* consider it a priority? Etc.).

In other words, when setting goals post-survey, the results will 
factor into the decisions, but they won't necessarily be the 
deciding factor. The survey is a means of getting community input 
in one place, as opposed to scattered across the forums and 
reddit comments.
Mar 10 2018
prev sibling next sibling parent psychoticRabbit <meagain meagain.com> writes:
On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:

 According to the State of D Survey, 71% of the respondents 
 don't care about betterC. Why is betterC on the priority list?


who cares what 'the majority' want... I mean really.

stuff em!

(ohh... that was in jest.. don't take that seriously)
Mar 10 2018
prev sibling next sibling parent =?UTF-8?B?QXVyw6lsaWVu?= Plazzotta <azerty protonmail.com> writes:
On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:

 On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
 wrote:

 Hello, the vision document of the Founation for the first six 
 months of 2018 is here:

 https://wiki.dlang.org/Vision/2018H1


 According to the State of D Survey, 71% of the respondents 
 don't care about betterC. Why is betterC on the priority list?


Just ignore it. And don't forget the primary betterC's goal.
It was never designed to please some C developers to take profit 
from D without dealing with D full runtime but to help migrating 
from historical C/C++ compiler backend to a fully D native 
compiler backend.

The objective is to obtain bootstraping and get rid of all other 
language's dependencies, which will be a huge advantage and 
advertising for D use and in extenso, D community and 
penetration-market.

Convincing C developpers to try out betterC is "just" a temporary 
(and positive) side-effect.
Mar 10 2018
prev sibling parent nkm1 <t4nk074 openmailbox.org> writes:
On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:

 On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
 wrote:

 Hello, the vision document of the Founation for the first six 
 months of 2018 is here:

 https://wiki.dlang.org/Vision/2018H1


 According to the State of D Survey, 71% of the respondents 
 don't care about betterC. Why is betterC on the priority list?


BetterC is probably mostly useful for writing libraries (that can 
be used from D
or other languages). So these 29% of respondents are perhaps more 
important
than just their percentage suggests.
Mar 11 2018
prev sibling next sibling parent Meta <jared771 gmail.com> writes:
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:

 Hello, the vision document of the Founation for the first six 
 months of 2018 is here:

 https://wiki.dlang.org/Vision/2018H1

 In addition to the expected items, we have a new top-level 
 priority - locking down the language definition. This is in 
 recognition of the fact that we need a precise definition of 
 the language going forward.


 Thanks,

 Andrei



 Establish the DIP as a clear, solid means to get a language 
 enhancement going


Very excited about this one. Hopefully some faith can be restored 
in the process.
Mar 10 2018
prev sibling parent Ali <fakeemail example.com> writes:
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu 
wrote:

 Hello, the vision document of the Founation for the first six 
 months of 2018 is here:

 https://wiki.dlang.org/Vision/2018H1

 In addition to the expected items, we have a new top-level 
 priority - locking down the language definition. This is in 
 recognition of the fact that we need a precise definition of 
 the language going forward.


 Thanks,

 Andrei


If I compare 2018H1 vision, to 2017H2 vision
I see that 3 out of 6 objectives are carry over from 2017

I think this needs more explanation, and maybe the vision 
document, should becomes more of a road map document

A vision by some definitions in management, is the organization 
dream, it doesn't have to be completely realistic

A road map, is more like a plan, that is realistically achievable

Again, I think, if 3 out 6 items are from last year, it seems 
unlikely all 6 will complete this year, and it seems more likely 
most of those will carry over to next year, and it becomes 
unclear which of those 6 will actually be implemented this year
Mar 19 2018