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
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
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
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
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
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
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
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
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
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
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
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
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 off C/C++? Other languages like Rust and C# only have 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? I came to D from a C# background. I was looking a language 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?
Mar 10
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
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 
 leech off C/C++? Other languages like Rust and C# only have 
 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?

 I came to D from a C# background. I was looking a language 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. 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 languages like C#, Ruby, PHP, Python, ... because too many 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...
Mar 10
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 
 leech off C/C++? Other languages like Rust and C# only have 
 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?

 I came to D from a C# background. I was looking a language 
 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 
 languages like C#, Ruby, PHP, Python, ... because too many 
 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
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 
 languages like C#, Ruby, PHP, Python, ... because too many 
 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
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 
 languages like C#, Ruby, PHP, Python, ... because too many 
 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
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
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
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
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
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
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
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
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
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
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. D's strength, is that most C/C++/Java/C# programmers can just 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. And personally, depending on the problem, C# is better to program in than D. I still don't know why C# programmers are willing to give up C# and prefer to use D. C# is vastly surperior for what it does. 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
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.

 D's strength, is that most C/C++/Java/C# programmers can just 
 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.
 And personally, depending on the problem, C# is better to 
 program in than D. I still don't know why C# programmers are 
 willing to give up C# and prefer to use D.
 C# is vastly surperior for what it does.
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
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.
I mean, cause D is so compatible with C/C++/Java/C# - that you 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. C# became popular cause C/C++/Java programmers could easily use it. D is gradually becoming popular cause C/C++/Java/C# programmers can easily use it.
Mar 10
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.
I mean, cause D is so compatible with C/C++/Java/C# - that you 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. C# became popular cause C/C++/Java programmers could easily use it. D is gradually becoming popular cause C/C++/Java/C# programmers 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
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
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
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:
 And personally, depending on the problem, C# is better to 
 program in than D. I still don't know why C# programmers are 
 willing to give up C# and prefer to use D.
 C# is vastly surperior for what it does.
Because, even the language creators seem to not recognize this, D looks like C# with *native compilation*, the syntax is 95% identical. Basically, if my source code doesn't use any .NET framework function, it will compile successfully with dmd without any (major) change. I suppose that every C# programmer is enthusiastic on the first contact with the D language, but fails to keep his enthusiasm when he sees Phobos. C# programmer's mind is locked in the OOP world and Phobos looks like a mess from his point of view. The problem is that D stagnates and in the same time C# evolves. Sometimes I feel like the C# language team is using D as inspiration for the new features, starting with C# 7.0, a 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 version of C# has on 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. My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly.
Mar 10
next sibling parent psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
 My opinion is that the day when C# will compile to native (on 
 any platform), the C# developer interest in D will drop 
 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
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, 
 D looks like C# with *native compilation*, the syntax is 95% 
 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.
 I suppose that every C# programmer is enthusiastic on the first 
 contact with the D language, but fails to keep his enthusiasm 
 when he sees Phobos. C# programmer's mind is locked in the OOP 
 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 to Go. And C# ... Resources simple are more focused and enhance 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.
 The problem is that D stagnates and in the same time C# evolves.
I am sure that lots of D members will be quick to point out, that C# is run by a commercial company and D has only open source contributors. Now why did you not contribute! /sarcasm
 Sometimes I feel like the C# language team is using D as 
 inspiration for the new features, starting with C# 7.0, a 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 version of C# has 
 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 Blazer = C# code runable in the browser using WebAssembly.
 In the same time, D delegates new features (and sometime 
 existing ones) to library implementation, instead of assume 
 them in the language syntax.

 My opinion is that the day when C# will compile to native (on 
 any platform), the C# developer interest in D will drop 
 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
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
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.
There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is 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.
Mar 11
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.
There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is 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
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.
There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler).
Don't forget that "open source" != non-profit. For the C# 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.
 The difference (at least for me) is that contributing to C# is 
 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
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 necessary easier. But if interested, to contribute to C# compiler, you just need to open roslyn.sln in Visual Studio, make your modification, run the test suite, commit, you're done.
Mar 11
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
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
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
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
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
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
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
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
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
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.
There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is 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. You can't really compare the C# ecosystem to the D ecosystem 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
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
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.
There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is 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 ;-) but I think comparing things in the C# world, to things in the D 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
parent reply rumbu <rumbu rumbu.ro> writes:
On Monday, 12 March 2018 at 04:48:43 UTC, psychoticRabbit wrote:

 but I think comparing things in the C# world, to things in the 
 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
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
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, 
 that C# is run by a commercial company and D has only open 
 source contributors. Now why did you not contribute! /sarcasm
I'd like to point out, that C# is run by a commercial company and 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
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, 
 D looks like C# with *native compilation*, the syntax is 95% 
 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 algorithm from C# to D, and it was a near seamless transition. I'm trying to persuade some of my C# compatriots to try D because of that experience.
Mar 11
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:
 And personally, depending on the problem, C# is better to 
 program in than D. I still don't know why C# programmers are 
 willing to give up C# and prefer to use D.
 C# is vastly surperior for what it does.
Because, even the language creators seem to not recognize this, D looks like C# with *native compilation*, the syntax is 95% identical. Basically, if my source code doesn't use any .NET framework function, it will compile successfully with dmd without any (major) change. I suppose that every C# programmer is enthusiastic on the first contact with the D language, but fails to keep his enthusiasm when he sees Phobos. C# programmer's mind is locked in the OOP world and Phobos looks like a mess from his point of view. The problem is that D stagnates and in the same time C# evolves. Sometimes I feel like the C# language team is using D as inspiration for the new features, starting with C# 7.0, a 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 version of C# has on 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. My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop 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 Hobbesian war of all against all. If C# gets better, that's 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 happens to C# programmer interest in D dies as soon as C# native 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. C# slices look great. I wanted to use them for generating 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. If Phobos looks like a mess to C# programmers, so much the worse for C# programmers. However I doubt they this is true in the general case. It's better in many ways, but different and unfamiliar and everything unfamiliar is disconcerting in the beginning.
Mar 11
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:
 If Phobos looks like a mess to C# programmers, so much the worse
 for C# programmers.  However I doubt they this is true in the
 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 definitely expect it to be somewhat alien to the average C# or Java 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
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
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
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
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
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
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 03/11/2018 11:31 PM, Laeeth Isharc wrote:
 
 C# slices look great.
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
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:
 
 C# slices look great.
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.
I doubt that this was the blocker because C# had ArraySegment<T> since .net framework 2.0 (2006), which is exactly a slice, but doesn't have the syntactic sugar for it. The current C# proposal introduces a syntactic sugar similar to D (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 system which does not map to the namespace concept in C#
Mar 13
parent reply flamencofantasy <flamencofantasy gmail.com> writes:
On Wednesday, 14 March 2018 at 05:22:53 UTC, rumbu wrote:

 I doubt that this was the blocker because C# had 
 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"?
 The current C# proposal introduces a syntactic sugar similar to 
 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. I am also a C# developer and I can assure you that 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
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:

 I doubt that this was the blocker because C# had 
 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
prev sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 12 March 2018 at 03:31:36 UTC, Laeeth Isharc wrote:
 C# slices look great.
Dunno, when I wanted a slice in C#, I wrote a prettier one. C# could get stuff done 20 years ago already, ugly slices and native compilation won't add anything to it.
 If Phobos looks like a mess to C# programmers, so much the 
 worse for C# programmers.
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
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
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
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.
I thought C# was like Java and does not allow free procedures. Can you give an example of C# procedural-style IO?
Mar 16
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.
I thought C# was like Java and does not allow free procedures. Can you give an example of C# procedural-style IO?
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
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.
I thought C# was like Java and does not allow free procedures. Can you give an example of C# procedural-style IO?
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
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 16 March 2018 at 18:35:14 UTC, Tony wrote:
 I thought C# was like Java and does not allow free procedures. 
 Can you give an example of C# procedural-style IO?
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
prev sibling parent Kagamin <spam here.lot> writes:
On Friday, 16 March 2018 at 18:35:14 UTC, Tony wrote:
 I thought C# was like Java and does not allow free procedures. 
 Can you give an example of C# procedural-style IO?
All methods of Console class.
Mar 19
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
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 how std.algorithm is big. It's also design pattern in C#: if you 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
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote:
 My opinion is that the day when C# will compile to native (on 
 any platform), the C# developer interest in D will drop 
 instantly.
I do write a commerical project in C#. But I have an opposite feeling: The day D will easily compile to Javascript and be able to fully interface with it, my wish to use C# will drop pretty much instantly. I'm not even sure I would choose C# over -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. And that's not to say that C# would be a bad language. I didn't 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. First, C# feels like it's hiding details from me, it kind of 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. Second, iterating in C# feels last-century standard. I like 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.
Mar 15
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:
 My opinion is that the day when C# will compile to native (on 
 any platform), the C# developer interest in D will drop 
 instantly.
I do write a commerical project in C#. But I have an opposite feeling: The day D will easily compile to Javascript and be able to fully interface with it, my wish to use C# will drop pretty much instantly. I'm not even sure I would choose C# over -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. And that's not to say that C# would be a bad language. I didn't 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. First, C# feels like it's hiding details from me, it kind of 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. Second, iterating in C# feels last-century standard. I like 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.
My quote is out of context. Somebody asked surprised why C# developers are interested in D. For me (mainly a C# developer), this is the main reason: native compilation (and this includes memory management). I highlighted the fact that the C# team keep implementing D specific ideas in each new version, so don't be surprised if your list of D exclusive features becomes smaller with each new C# iteration. My complaint was the fact that D drops features or push them into library solutions.
Mar 15
parent reply psychoticRabbit <meagain meagain.com> writes:
On Thursday, 15 March 2018 at 18:39:08 UTC, rumbu wrote:
 My quote is out of context. Somebody asked surprised why C# 
 developers are interested in D. For me (mainly a C# developer), 
 this is the main reason: native compilation (and this includes 
 memory management). I highlighted the fact that the C# team 
 keep implementing D specific ideas in each new version, so 
 don't be surprised if your list of D exclusive features becomes 
 smaller with each new C# iteration. My complaint was the fact 
 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 ??) btw. run your C# or Java program for long enough, and it's essentially native compiled anyway. When I run some of my java programs, I still don't know how 'native compilation' would make it go any faster (noticably). Same goes for my C# Windows Forms apps..they just fly...native compilation wouldn't add much. btw C# has had slices since day 1. Just required an extra 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
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 D share underlying array, something that C# recently recognized 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
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
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
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
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
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 (C/C++/Java/C#... and dare I say it..python) 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
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
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
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
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
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
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
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
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 need to write c# code in vs code is just two or three extension. There is code hinting, auto complete etc. Why will I not use C# 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
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
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
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
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
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
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