www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is there an intention to 'finish' D2?

reply Abdulhaq <alynch4047 gmail.com> writes:
Is there a set of features that, when fully working, will mean 
that D2 is now finished? Or will it forever be in a state of 
ongoing feature development?

We all know that properly finishing and polishing the last 10% of 
a software project takes 90% of the time. Is there a timescale 
for that? What platforms will it support?
Nov 16 2021
next sibling parent zjh <fqbqrr 163.com> writes:
On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:


 timescale for that? What platforms will it support?


There are too few major developers.
Nov 16 2021
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean 
 that D2 is now finished? Or will it forever be in a state of 
 ongoing feature development?

 We all know that properly finishing and polishing the last 10% 
 of a software project takes 90% of the time. Is there a 
 timescale for that? What platforms will it support?


No, but mark my words there will be 15 new attributes before any 
of it is finished.
Nov 16 2021
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean 
 that D2 is now finished? Or will it forever be in a state of 
 ongoing feature development?

 We all know that properly finishing and polishing the last 10% 
 of a software project takes 90% of the time. Is there a 
 timescale for that? What platforms will it support?


As the ongoing threads to reboot the language memory model prove, 
it is doomed to be in a state of ongoing feature development.
Nov 16 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 16 November 2021 at 12:25:19 UTC, Paulo Pinto wrote:

 As the ongoing threads to reboot the language memory model 
 prove, it is doomed to be in a state of ongoing feature 
 development.


Maybe, but D doesn't really have a memory model. So it is more 
about getting one than rebooting…
Nov 16 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean 
 that D2 is now finished? Or will it forever be in a state of 
 ongoing feature development?

 We all know that properly finishing and polishing the last 10% 
 of a software project takes 90% of the time. Is there a 
 timescale for that? What platforms will it support?


Time will tell.

Currently pretty much is happening and with the stdv2 etc. So my 
sense it that D2 will be in pretty stable soon. And I don't know 
if the stdv2 will in the long run enable D3 or not but it's 
interesting that we're starting at least.
Nov 16 2021
parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Tuesday, 16 November 2021 at 13:18:54 UTC, Imperatorn wrote:

 On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean 
 that D2 is now finished? Or will it forever be in a state of 
 ongoing feature development?





 Time will tell.


I have a feeling that half the people in this forum are thinking 
'Are you trolling me, D2 was finished a decade ago', and the 
other half are thinking it's a non-question. Allow me to 
elaborate. I'm an occasional user of D since may years ago, a D 
supporter. I'd love to see it become more well known and used.

I have now reached a stage in my career where I have a 
significant influence on what languages are being used in a 
commercial environment - and sometimes for large corporates. I 
understand what it takes to make a large commercial application 
succeed, to be maintainable, to have a sustainable future.

With that user base in mind, probably the largest constituency of 
developers that D could hope to reach, there are some 
requirements, that I see D currently falling down on. I've just 
been an observer of D for the last few years but that is the case 
for nearly everyone in my position. I'm waiting for these major 
DIPs and -preview this and that to settle back down to Earth. I 
don't want to be having to work around **any** half baked 
features, I don't have time. E.g. I want it to be clearly defined 
how to implement and use ranges (from an observers POV it feels 
like this question has never been properly answered, I asked it 
many years ago and still it seems to be in motion).

'Finishing' D2 doesn't mean that feature development stops. It 
means that the community makes a concerted attempt to make 
**everything** work well that is claimed to work well, at least 
make it work to a spec. Pin this fully working feature set to a 
named long term supported version.

It feels to this observer that there is not even a known list of 
features that will one day work fully, and on which platforms 
that will be done for. Until that is the case, I cannot base my 
plans on D in a commercial environment.

I believe that Walter et al. don't think that the user base I am 
talking about, corporate application developers, are their target 
audience. They have some other 'system' developers in mind. 
That's fine with me! This post simply serves to point out to the 
rest of the community why this particular group remain waiting in 
the wings.
Nov 18 2021
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 18 November 2021 at 08:44:57 UTC, Abdulhaq wrote:

 On Tuesday, 16 November 2021 at 13:18:54 UTC, Imperatorn wrote:

 On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will 
 mean that D2 is now finished? Or will it forever be in a 
 state of ongoing feature development?





 Time will tell.


 I have a feeling that half the people in this forum are 
 thinking 'Are you trolling me, D2 was finished a decade ago', 
 and the other half are thinking it's a non-question. Allow me 
 to elaborate. I'm an occasional user of D since may years ago, 
 a D supporter. I'd love to see it become more well known and 
 used.

 I have now reached a stage in my career where I have a 
 significant influence on what languages are being used in a 
 commercial environment - and sometimes for large corporates. I 
 understand what it takes to make a large commercial application 
 succeed, to be maintainable, to have a sustainable future.

 With that user base in mind, probably the largest constituency 
 of developers that D could hope to reach, there are some 
 requirements, that I see D currently falling down on. I've just 
 been an observer of D for the last few years but that is the 
 case for nearly everyone in my position. I'm waiting for these 
 major DIPs and -preview this and that to settle back down to 
 Earth. I don't want to be having to work around **any** half 
 baked features, I don't have time. E.g. I want it to be clearly 
 defined how to implement and use ranges (from an observers POV 
 it feels like this question has never been properly answered, I 
 asked it many years ago and still it seems to be in motion).

 'Finishing' D2 doesn't mean that feature development stops. It 
 means that the community makes a concerted attempt to make 
 **everything** work well that is claimed to work well, at least 
 make it work to a spec. Pin this fully working feature set to a 
 named long term supported version.

 It feels to this observer that there is not even a known list 
 of features that will one day work fully, and on which 
 platforms that will be done for. Until that is the case, I 
 cannot base my plans on D in a commercial environment.

 I believe that Walter et al. don't think that the user base I 
 am talking about, corporate application developers, are their 
 target audience. They have some other 'system' developers in 
 mind. That's fine with me! This post simply serves to point out 
 to the rest of the community why this particular group remain 
 waiting in the wings.


Disclaimer: Despite saying 'we' a few times, I do *not* speak for 
Funkwerk. All opinions are my own.

Offering a different take, that may be compatible with yours:

At Funkwerk, we use D in production, doing high-throughput 
backend work. (By cycle mostly JSON encoding/decoding, to be 
honest.) I want to be clear that if we ever switch to another 
language, it will almost certainly *not* be because D changes too 
fast or is too unstable, but because it changes too *slow* and is 
too set in its ways.

Barring breaking issues, we roll out compiler updates maybe every 
three major versions or so. This then takes a few months to 
propagate through all our services. However, especially in the 
last few versions, we've rarely had regression issues from DMD 
upgrades. I'd estimate the time spent on reporting or fixing 
compiler regressions as one or two developer-weeks in total 
across, uh, *checks* ~400kloc just for services that are at DMD 
2.09*, ie. reasonably recent and actively maintained. Time to get 
rid of deprecations is about that high again. In comparison, 
whenever we stumble on a novel compiler bug, that eats away 
another half-day or so from dustmiting. And it's not like we 
don't use the language to its fullest - as pointed out in 
previous dconfs, we use ranges very heavily (almost to the 
exclusion of imperative code) to enable a functional style, and 
boilerplate/serialized on github demonstrate that we aren't 
afraid of templates either. And yet, every time we upgrade, we 
maybe get a few instances of deprecations per service, that are 
easily fixed (maybe that we even pushed for), a few instances of 
regressions across the entire codebase, usually resulting in 
compile errors, extremely rarely in code errors, and not much 
change otherwise.

However, there is also time taken to work around language 
deficiencies. This is mostly not a big issue, and it's hard to 
quantify, but purely as a feeling I wouldn't put it as much lower 
than the previous issues. And there are things that should work 
but that we don't even attempt anymore, or only with great 
trepidation, such as marking data structures as immutable, due to 
language limitations with reassignment. (At least I got 
rebindable deployed internally, fingers crossed.)

I once said to a colleague that the process of learning D 
consists almost entirely, by time, of what *not* to do - what 
sort of things the language is happy about, what it only lets you 
get away with grudgingly, and what it will punish you for. Though 
some of the most severe gotchas have gotten fixed, I stand by 
this still.

All our issues with the language are documented and well-known in 
the community. D is efficient and we're all comfortable with it, 
but it's not like we're married to it; our microservice 
architecture does allow us to experiment with different 
frameworks for service development. As such, if we ever switch 
away from D, it will be because we've found something better - 
ie. because D was moving too slow to keep up with language 
improvements, not because it was moving so fast that it 
overwhelmed us. At present, I do not see that as a credible 
risk.On Thursday, 18 November 2021 at 08:44:57 UTC, Abdulhaq 
wrote:

 On Tuesday, 16 November 2021 at 13:18:54 UTC, Imperatorn wrote:

 On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will 
 mean that D2 is now finished? Or will it forever be in a 
 state of ongoing feature development?





 Time will tell.


 I have a feeling that half the people in this forum are 
 thinking 'Are you trolling me, D2 was finished a decade ago', 
 and the other half are thinking it's a non-question. Allow me 
 to elaborate. I'm an occasional user of D since may years ago, 
 a D supporter. I'd love to see it become more well known and 
 used.

 I have now reached a stage in my career where I have a 
 significant influence on what languages are being used in a 
 commercial environment - and sometimes for large corporates. I 
 understand what it takes to make a large commercial application 
 succeed, to be maintainable, to have a sustainable future.

 With that user base in mind, probably the largest constituency 
 of developers that D could hope to reach, there are some 
 requirements, that I see D currently falling down on. I've just 
 been an observer of D for the last few years but that is the 
 case for nearly everyone in my position. I'm waiting for these 
 major DIPs and -preview this and that to settle back down to 
 Earth. I don't want to be having to work around **any** half 
 baked features, I don't have time. E.g. I want it to be clearly 
 defined how to implement and use ranges (from an observers POV 
 it feels like this question has never been properly answered, I 
 asked it many years ago and still it seems to be in motion).

 'Finishing' D2 doesn't mean that feature development stops. It 
 means that the community makes a concerted attempt to make 
 **everything** work well that is claimed to work well, at least 
 make it work to a spec. Pin this fully working feature set to a 
 named long term supported version.

 It feels to this observer that there is not even a known list 
 of features that will one day work fully, and on which 
 platforms that will be done for. Until that is the case, I 
 cannot base my plans on D in a commercial environment.

 I believe that Walter et al. don't think that the user base I 
 am talking about, corporate application developers, are their 
 target audience. They have some other 'system' developers in 
 mind. That's fine with me! This post simply serves to point out 
 to the rest of the community why this particular group remain 
 waiting in the wings.


Offering a different take, that may be compatible with yours:

At Funkwerk, we use D in production, doing high-throughput 
backend work. (By cycle mostly JSON encoding/decoding, to be 
honest.) I want to be clear that if we ever switch to another 
language, it will almost certainly *not* be because D changes too 
fast or is too unstable, but because it changes too *slow* and is 
too set in its ways.

Barring breaking issues, we roll out compiler updates maybe every 
three major versions or so. This then takes a few months to 
propagate through all our services. However, especially in the 
last few versions, we've rarely had regression issues from DMD 
upgrades. I'd estimate the time spent on reporting or fixing 
compiler regressions as one or two developer-weeks in total 
across, uh, *checks* ~400kloc just for services that are at DMD 
2.09*, ie. reasonably recent and actively maintained. Time to get 
rid of deprecations is about that high again. In comparison, 
whenever we stumble on a novel compiler bug, that eats away 
another half-day or so from dustmiting. And it's not like we 
don't use the language to its fullest - as pointed out in 
previous dconfs, we use ranges very heavily (almost to the 
exclusion of imperative code) to enable a functional style, and 
boilerplate/serialized on github demonstrate that we aren't 
afraid of templates either. And yet, every time we upgrade, we 
maybe get a few instances of deprecations per service, that are 
easily fixed (maybe that we even pushed for), a few instances of 
regressions across the entire codebase, usually resulting in 
compile errors, extremely rarely in code errors, and not much 
change otherwise.

However, there is also time taken to work around language 
deficiencies. This is mostly not a big issue, and it's hard to 
quantify, but purely as a feeling I wouldn't put it as much lower 
than the previous issues. And there are things that should work 
but that we don't even attempt anymore, or only with great 
trepidation, such as marking data structures as immutable, due to 
language limitations with reassignment. (At least I got 
rebindable deployed internally, fingers crossed.)

I once said to a colleague that the process of learning D 
consists almost entirely, by time, of what *not* to do - what 
sort of things the language is happy about, what it only lets you 
get away with grudgingly, and what it will punish you for. Though 
some of the most severe gotchas have gotten fixed, I stand by 
this still.

All our issues with the language are documented and well-known in 
the community. D is efficient and we're all comfortable with it, 
but it's not like we're married to it; our microservice 
architecture does allow us to experiment with different 
frameworks for service development. As such, if we ever switch 
away from D, it will be because we've found something better - 
ie. because D was moving too slow to keep up with language 
improvements, not because it was moving so fast that it 
overwhelmed us. At present, I do not see that as a credible risk.

*On the other hand,* we also don't really use DIP features. I 
think maybe this is a communications problem. In my experience, 
the parts of D that are released and have been used for a few 
major versions tend to be very stable and hard to change. So 
people see all the cool new things,  live, DIP1000, ImportC, and 
think that the language is still in flux. But the core 
functionality of the language, ranges, templates, constness etc. 
is and has been incredibly stable even since D1, so if you just 
ignore the rapidly mutating fringe you'll get exactly what you 
want - a stable, even too stable, subset.

*On the other hand,* we also don't really use DIP features. I 
think maybe this is a communications problem. In my experience, 
the parts of D that are released and have been used for a few 
major versions tend to be very stable and hard to change. So 
people see all the cool new things,  live, DIP1000, ImportC, and 
think that the language is still in flux. But the core 
functionality of the language, ranges, templates, constness etc. 
is and has been incredibly stable even since D1, so if you just 
ignore the rapidly mutating fringe you'll get exactly what you 
want - a stable, even too stable, subset.
Nov 18 2021
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 18 November 2021 at 09:38:09 UTC, FeepingCreature 
wrote:

 Messed up double message


Er, please ignore the top part of that, somehow I got a previous 
revision of the message copypasted on top. What the heck. Mods, 
if you delete that I can repost it better?
Nov 18 2021
prev sibling parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Thursday, 18 November 2021 at 09:38:09 UTC, FeepingCreature 
wrote:

 On Thursday, 18 November 2021 at 08:44:57 UTC, Abdulhaq wrote:

 On Tuesday, 16 November 2021 at 13:18:54 UTC, Imperatorn wrote:




Thanks for your detailed reply! It provides a useful counterpoint.


 I once said to a colleague that the process of learning D 
 consists almost entirely, by time, of what *not* to do - what 
 sort of things the language is happy about, what it only lets 
 you get away with grudgingly, and what it will punish you for. 
 Though some of the most severe gotchas have gotten fixed, I 
 stand by this still.


This is exactly what I mean by not wanting to learn workarounds. 
I find battling with 'suprising' behaviour and/or bugs in any 
development environment extremely frustrating these days. For 
developers coming fresh to D they have to manage to break through 
this pain barrier to get to the point of productivity. It's a 
personal thing of mine but I've just had enough of this 
particular fight. I just want it to work without needing to pull 
out what remains of my hair while I learn the foibles and 
failings of the tool.  I suspect that the body of D developers at 
any one time falls into those who are fairly new and haven't yet 
faced many frustrations, and those who are now experts and 
instinctively avoid problem areas. I suspect there is a great 
deal of 'wastage' i.e. developers leaving, between those two 
levels. Just a suspicion.


 *On the other hand,* we also don't really use DIP features. I 
 think maybe this is a communications problem. In my experience, 
 the parts of D that are released and have been used for a few 
 major versions tend to be very stable and hard to change. So 
 people see all the cool new things,  live, DIP1000, ImportC, 
 and think that the language is still in flux. But the core 
 functionality of the language, ranges, templates, constness 
 etc. is and has been incredibly stable even since D1, so if you 
 just ignore the rapidly mutating fringe you'll get exactly what 
 you want - a stable, even too stable, subset.


Yes, it's likely a communications problem. I don't have the heart 
or time to come back and try again, so I have to infer the 
current status of D from the forums. The impression that I have 
gained, and I suspect the same for other observers, is the one I 
have recounted.

I don't know why I do it, but I read pretty much all the messages 
in General and have done for many years. This is the impression I 
have got.
Nov 18 2021
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 18 November 2021 at 11:05:12 UTC, Abdulhaq wrote:

 On Thursday, 18 November 2021 at 09:38:09 UTC, FeepingCreature 
 wrote:

 *On the other hand,* we also don't really use DIP features. I 
 think maybe this is a communications problem. In my 
 experience, the parts of D that are released and have been 
 used for a few major versions tend to be very stable and hard 
 to change. So people see all the cool new things,  live, 
 DIP1000, ImportC, and think that the language is still in 
 flux. But the core functionality of the language, ranges, 
 templates, constness etc. is and has been incredibly stable 
 even since D1, so if you just ignore the rapidly mutating 
 fringe you'll get exactly what you want - a stable, even too 
 stable, subset.


 Yes, it's likely a communications problem. I don't have the 
 heart or time to come back and try again, so I have to infer 
 the current status of D from the forums. The impression that I 
 have gained, and I suspect the same for other observers, is the 
 one I have recounted.

 I don't know why I do it, but I read pretty much all the 
 messages in General and have done for many years. This is the 
 impression I have got.


Yeah that makes sense. I think this is more an issue with General 
than the language though; the debate tends to be centered on 
controversial new features because that's what attracts 
attention. I think that's part of why the DLF has dedicated 
feedback talks with industry users, because otherwise it's very 
easy for that signal to get lost in the noise.
Nov 18 2021
parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Thursday, 18 November 2021 at 11:11:20 UTC, FeepingCreature 
wrote:


 Yeah that makes sense. I think this is more an issue with 
 General than the language though; the debate tends to be 
 centered on controversial new features because that's what 
 attracts attention. I think that's part of why the DLF has 
 dedicated feedback talks with industry users, because otherwise 
 it's very easy for that signal to get lost in the noise.


Well it's great that they are doing that, but ATM the number of 
corporates using D and attending DLF meetings is tiny compared to 
the number that could potentially use D but are holding back due 
to perceived problems.

Going back to my original question at the top of the thread, do 
you have an answer to my questions? Is the answer actually well 
known but it has slipped me by? I think you're saying it's 
already polished and done, and features tend to work well. So 
what about the perennial issues, memory management, DLL support, 
Android/iOS support? Shared? They keep coming up, do I have to 
spend a few months digging in to D again to see if my experience 
is now one of 'it just works' on Windows, Linux, Mac? Mobile?
Nov 18 2021
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 18 November 2021 at 11:32:15 UTC, Abdulhaq wrote:

 Going back to my original question at the top of the thread, do 
 you have an answer to my questions? Is the answer actually well 
 known but it has slipped me by? I think you're saying it's 
 already polished and done, and features tend to work well. So 
 what about the perennial issues, memory management, DLL 
 support, Android/iOS support? Shared? They keep coming up, do I 
 have to spend a few months digging in to D again to see if my 
 experience is now one of 'it just works' on Windows, Linux, 
 Mac? Mobile?


I mean, I guess the answer for us is that we just don't need any 
of those.

I don't think D is ready to be used by everyone for every 
purpose. But I think it's ready to be used by some for some 
purposes, and has been for a long time. Even by many for many 
purposes. I think the set of "customers that D is ready for" is 
badly communicated at the moment, but it is definitely non-empty. 
(Evidence one.)

PS: I concur with the GC. I think this is one case where D 
majorly falls down, because it advertises as "you don't need to 
think about memory management" and if you take that seriously, 
you *will* get punished for it as you scale up input. You can't 
write D like Java, because D's GC is significantly less 
forgiving, but this is not communicated anywhere.

PPS: 'shared' is one of those features that we've just elected to 
not touch with a ten foot pole. It does nothing useful for us; I 
believe I've had rants on the topic. :) Luckily, it's easy to 
pretend it doesn't exist.
Nov 18 2021
parent Abdulhaq <alynch4047 gmail.com> writes:
On Thursday, 18 November 2021 at 12:31:43 UTC, FeepingCreature 
wrote:


 I don't think D is ready to be used by everyone for every 
 purpose. But I think it's ready to be used by some for some 
 purposes, and has been for a long time. Even by many for many 
 purposes. I think the set of "customers that D is ready for" is 
 badly communicated at the moment, but it is definitely 
 non-empty. (Evidence one.)

 PS: I concur with the GC. I think this is one case where D 
 majorly falls down, because it advertises as "you don't need to 
 think about memory management" and if you take that seriously, 
 you *will* get punished for it as you scale up input. You can't 
 write D like Java, because D's GC is significantly less 
 forgiving, but this is not communicated anywhere.

 PPS: 'shared' is one of those features that we've just elected 
 to not touch with a ten foot pole. It does nothing useful for 
 us; I believe I've had rants on the topic. :) Luckily, it's 
 easy to pretend it doesn't exist.



This answer has improved my understanding of where D is at, thank 
you. It's this information that is not coming over loud and clear 
to me.

Personally, I don't have a strong opinion on GC vs nogc etc., 
etc. I do think that if the community could agree to differ on 
these issues, state clearly what is fully supported and what 
platforms it works **excellently** on, and commits to maintain 
those features on those platforms at that level of excellence, 
then numbers will pick up faster than they otherwise would.

Off the top of my head I'd also even consider making an LTS 
release that had no preview options. Again just an observer's 
perspective but it feels like with the various DIPs and previews 
available that this causes an interoperability problem between 
libraries. I'm happy to be corrected if that is not the case.
Nov 18 2021
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 08:44:57 UTC, Abdulhaq wrote:

 With that user base in mind, probably the largest constituency 
 of developers that D could hope to reach, there are some 
 requirements, that I see D currently falling down on.


I dont think having many users that have no real interest in the 
language is an advantage at this point, to be honest. It makes 
changes more difficult.


 I believe that Walter et al. don't think that the user base I 
 am talking about, corporate application developers, are their 
 target audience. They have some other 'system' developers in 
 mind.


I feel the opposite, but I am happy if you are right.
Nov 18 2021
parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Thursday, 18 November 2021 at 10:11:46 UTC, Ola Fosheim 
Grøstad wrote:


 I dont think having many users that have no real interest in 
 the language is an advantage at this point, to be honest. It 
 makes changes more difficult.


I don't understand you, no-one will pick up D if they have no 
prior interest. I have a lot of interest in using D because of 
its expressivity, but won't use it in a commercial environment 
for the reasons given. It's nothing to do with lack of interest.


 I believe that Walter et al. don't think that the user base I 
 am talking about, corporate application developers, are their 
 target audience. They have some other 'system' developers in 
 mind.


 I feel the opposite, but I am happy if you are right.


It's very illuminating that the two of us, both long term readers 
of the forums, have opposite opinions of what Walter thinks 
regarding the direction he is 'heading' to. It says to me that 
the direction has not been well communicated - which is perhaps 
one of my main points.
Nov 18 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 11:13:05 UTC, Abdulhaq wrote:

 I don't understand you, no-one will pick up D if they have no 
 prior interest. I have a lot of interest in using D because of 
 its expressivity, but won't use it in a commercial environment 
 for the reasons given. It's nothing to do with lack of interest.


No, I didn't mean you. Nothing wrong with commercial developers 
in small teams. But if Big Business start making D mandatory, 
then that would not necessarily mean improvements for the 
existing users.

Being nimble and passionate is an advantage D has over C++. I 
like that C++ is improving by adding stuff, but the overall 
cognitive burden is quite large even for highly skilled 
developers. Unfortunately the leaders of D view C++'s model as 
successful. Well, it isn't. C++ has had momentum since early 90s. 
That is the source for C++'s success. It does not confirm their 
development process!

D1 had one big advantage over C++: lower cognitive burden. I 
agree with you, D2 needs to be better at that. I think that is in 
effect what you feel uncertain about  regarding bringing it into 
your workplace?



 It's very illuminating that the two of us, both long term 
 readers of the forums, have opposite opinions of what Walter 
 thinks regarding the direction he is 'heading' to. It says to 
 me that the direction has not been well communicated - which is 
 perhaps one of my main points.


Or… there is no focus on concrete use cases, so there is no 
direction to communicate?

I also think you already know the answer to your own doubts. If 
we look at history, I'd say D2 is stable in 10 years if ever. 
Because big new features are added while the count of weird 
deficiencies isn't really changing. So that count will not reach 
zero…

Someone from the outside with a background in usability, software 
engineering and software process improvement probably has to 
enter the scene and break the patterns before you get the focus 
and clear direction communicated.

I think D could benefit immensely from some outside consulting… 
:-)
Nov 18 2021
next sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Thursday, 18 November 2021 at 11:48:28 UTC, Ola Fosheim 
Grøstad wrote:


 Or… there is no focus on concrete use cases, so there is no 
 direction to communicate?

 I also think you already know the answer to your own doubts.


Yes, and yes.... but it's worth laying it out so that it is more 
visible.
Nov 18 2021
prev sibling parent reply forkit <forkit gmail.com> writes:
On Thursday, 18 November 2021 at 11:48:28 UTC, Ola Fosheim 
Grøstad wrote:

 ...
 ....Unfortunately the leaders of D view C++'s model as 
 successful.


Yes, this certainly appears to be the case.

I personally believe, that this view is what will bring about D's 
demise, sooner rather than later.

In the end, I see D (and I expect the outide world see's D), as 
an experiment in language design. Usuable ..yes. 
Interesting..yes. Leading edge features... yes.

But ultimately centered around the same mistakes that C++ made:

- trying to be compatible with C
- trying to replace C
- refusing to break things
- and in addition to all of the above, adding as much as possible.

Having said that, I kinda like D ;-)
Nov 20 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 21 November 2021 at 00:40:23 UTC, forkit wrote:

 But ultimately centered around the same mistakes that C++ made:

 - trying to be compatible with C
 - trying to replace C
 - refusing to break things
 - and in addition to all of the above, adding as much as 
 possible.


It wasn't a mistake for C++ to be compatible with C, but their 
users also don't crave automatic memory management.

For D the most problematic C feature is badly typed unions.

What is annoying is that there isn't all that much wrong with D, 
you just need to do adjustments to get more shiny than C++. But 
many adjustments:

- make type unification work so that an alias is an alias (or has 
that been fixed?)

- make integers non-modular so that you get better optimization 
and can do overflow checks

- clean up some syntax

- add ref counting optimizations

and so on.

If D focused on adjusting what is in the language rather than 
adding new stuff it could do well.


 Having said that, I kinda like D ;-)


Sure.
Nov 22 2021
parent reply forkit <forkit gmail.com> writes:
On Monday, 22 November 2021 at 08:55:42 UTC, Ola Fosheim Grøstad 
wrote:

 It wasn't a mistake for C++ to be compatible with C, but their 
 users also don't crave automatic memory management.


For the time, perhaps not. But in hindsight, all C++ did, was to 
'add onto' a language that provided very little in terms of 
safety guarantees.

D is inheriting all of that too, while adding on to it.

A lot of the code in the future, will need formal safety 
guarantees, and at some point, I wouldn't be surprised if 
countries start passing legislation to mandate this (well, they 
already do this in some industries anyway).

D cannot provide such guarantees.. and will never be in a 
position to do so.

I suppose what I'm getting at, is D really a language I'd 
recommend to the CIO?

Or is it just nice to play around with.

I'd say that latter, in which case.. (to get back on topic).. who 
really cares when D2 is finished ;-)
Nov 22 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 22 November 2021 at 21:38:57 UTC, forkit wrote:

 For the time, perhaps not. But in hindsight, all C++ did, was 
 to 'add onto' a language that provided very little in terms of 
 safety guarantees.


Yes. Bjarne Stroustrup missed the modelling features of Simula 
(OOP and coroutines) and added those to C. Of course, C++ became 
the black bastardized sheep of OOP and academics frowned... Then 
Java was inspired by OOP and more or less reimplemented Simula 
(semantically close), and Bjarne got a prize for his OOP efforts. 
:-D



 A lot of the code in the future, will need formal safety 
 guarantees, and at some point, I wouldn't be surprised if 
 countries start passing legislation to mandate this (well, they 
 already do this in some industries anyway).

 D cannot provide such guarantees.. and will never be in a 
 position to do so.


D could become interesting for small businesses or individuals 
that create commercial interactive desktop products. Clean up the 
semantics, syntax, memory management and build an application 
framework for D.

I guess Swift is workable, to some extent, but very Mac centric 
and requires some C. D could be a cross platform replacement for 
Swift + C.

But it takes a lot of focus on polish (semantics + syntax). And 
well, "focus" and "polish" requires disciplined planning.



 Or is it just nice to play around with.

 I'd say that latter, in which case.. (to get back on topic).. 
 who really cares when D2 is finished ;-)


I'd care, if it was polished and suitable for effectively 
creating highly interactive software.

But then we come back to disciplined planning. Which seems to be 
an unsurmountable challenge.
Nov 22 2021
parent reply forkit <forkit gmail.com> writes:
On Monday, 22 November 2021 at 22:14:46 UTC, Ola Fosheim Grøstad 
wrote:

 But then we come back to disciplined planning. Which seems to 
 be an unsurmountable challenge.


Creativity and 'disciplined planning' don't combine well .. and 
never will.
Nov 22 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 22 November 2021 at 22:21:37 UTC, forkit wrote:

 On Monday, 22 November 2021 at 22:14:46 UTC, Ola Fosheim 
 Grøstad wrote:

 But then we come back to disciplined planning. Which seems to 
 be an unsurmountable challenge.


 Creativity and 'disciplined planning' don't combine well .. and 
 never will.


I don't necessarily agree. Regardless, PL design is 5% creativity 
95% engineering.
Nov 22 2021
parent reply forkit <forkit gmail.com> writes:
On Monday, 22 November 2021 at 22:26:41 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 22 November 2021 at 22:21:37 UTC, forkit wrote:

 On Monday, 22 November 2021 at 22:14:46 UTC, Ola Fosheim 
 Grøstad wrote:

 But then we come back to disciplined planning. Which seems to 
 be an unsurmountable challenge.


 Creativity and 'disciplined planning' don't combine well .. 
 and never will.


 I don't necessarily agree. Regardless, PL design is 5% 
 creativity 95% engineering.


Plenty of psychologists would disagree, with your disagreement.

Creativity (by it's very nature) allows you to go in all kinds of 
directions.

Disciplined planning (by it's very nature) moves you towards a 
specific direction.

Sure, you can make tradeoffs towards one end of the spectrum or 
the other.

But I would be shocked, if I ever came across a creative 
personality (someone who is creative by nature) that willingly 
embraces disciplined planning.

What you're asking for, seems more directed towards developing a 
culture of 'controlled creativity'. Good luck with that ;-)

Creativity is not an algorithm.
Nov 22 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 22 November 2021 at 22:59:49 UTC, forkit wrote:

 But I would be shocked, if I ever came across a creative 
 personality (someone who is creative by nature) that willingly 
 embraces disciplined planning.


Architects don’t exist?
Industrial designers dont exist?

Lets not confuse hobbyism with professionalism.

Humans are not unidimensional.

There are even techniques for being more creative...
Nov 22 2021
prev sibling next sibling parent reply user1234 <user1234 12.de> writes:
On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean 
 that D2 is now finished? Or will it forever be in a state of 
 ongoing feature development?


(Assuming you talk about D2 new features compared to D1)

A problem is that D1 to D2 was a major change with several 
objectives.

The current approach that is to introduce changes, incrementally 
"DIP driven"-ly,
is more likely to result in finished features. To me, unfisnished 
D2 "new" features (e.g shared) are more a symptom of the poor 
managment and the poor methodology that drove D development 10 
years ago.
Nov 18 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 12:45:16 UTC, user1234 wrote:

 The current approach that is to introduce changes, 
 incrementally "DIP driven"-ly,
 is more likely to result in finished features. To me, 
 unfisnished D2 "new" features (e.g shared) are more a symptom 
 of the poor managment and the poor methodology that drove D 
 development 10 years ago.


I don't think DIPs constitute a method. It also doesn't work all 
that great for other languages in my opinion. I think even Python 
is aggregating bloat and complexity now that Guido took the hand 
of the breaks. Bloat destroys good languages, over time.

You need some kind of structured loop(s), very sketchy:

1. gather information related to key use cases
2. analyse
3. rank and select key problem to be addressed
4. describe problem, ask for solution propositions (many)
5. analyse, evaluate, select
6. make experimental implementations
7. analyse, evaluate, go back to 3-6 if needed
8. make a release strategy (minor/major release)
9. implement, test
10. collect feedback from end users
11. analyse, evaluate, go back to 3-10 if needed
12. polish, deploy, go to 1

That is just for addressing pressing issues, and does not cover 
strategic planning or quality assurance.
Nov 18 2021
parent reply user1234 <user1234 12.de> writes:
On Thursday, 18 November 2021 at 13:27:56 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 18 November 2021 at 12:45:16 UTC, user1234 wrote:

 [...]


 I don't think DIPs constitute a method. It also doesn't work 
 all that great for other languages in my opinion. I think even 
 Python is aggregating bloat and complexity now that Guido took 
 the hand of the breaks. Bloat destroys good languages, over 
 time.

 You need some kind of structured loop(s), very sketchy:

 1. gather information related to key use cases
 2. analyse
 3. rank and select key problem to be addressed
 4. describe problem, ask for solution propositions (many)
 5. analyse, evaluate, select
 6. make experimental implementations
 7. analyse, evaluate, go back to 3-6 if needed
 8. make a release strategy (minor/major release)
 9. implement, test
 10. collect feedback from end users
 11. analyse, evaluate, go back to 3-10 if needed
 12. polish, deploy, go to 1

 That is just for addressing pressing issues, and does not cover 
 strategic planning or quality assurance.


In the sense that a DIP is a specification, the way to implement 
a new feature should be more straight than by implementing 
without previous serious reflection on "what's gonna be done".
Nov 20 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 20 November 2021 at 16:47:38 UTC, user1234 wrote:

 In the sense that a DIP is a specification, the way to 
 implement a new feature should be more straight than by 
 implementing without previous serious reflection on "what's 
 gonna be done".


I think I understand what you mean.

The problem with DIPs is that they invite people to propose a 
series of additions that has nothing to do with what should be 
top priority. Python is adding new features with every release… 
at some point it will loose the essential quality of being "a 
simple language".


designed by teams of experts, not by the most enthusiastic users 
of a language?
Nov 21 2021
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 18 November 2021 at 12:45:16 UTC, user1234 wrote:

 A problem is that D1 to D2 was a major change with several 
 objectives.


The truth is really we're in the most stagnant part of D's 
history right now.

What really happened with the D1 to D2 thing is that D has always 
been on an evolutionary path and would add and change things as 
needed. "D1" was not really much of a thing - it was just an 
arbitrarily selected maintenance branch while D's existing 
evolution kept going but was rebranded D2.

It isn't like D1 was some stable target and D2 was a radical 
change in development. No, D1 came out only 6 months before D2.
Nov 18 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 13:29:59 UTC, Adam D Ruppe wrote:

 It isn't like D1 was some stable target and D2 was a radical 
 change in development. No, D1 came out only 6 months before D2.


Well, IIRC, the old D1 website made a point of D1 being a 
simplified C++ family language, and having no templates was 
essential to that simplicity philosophy. That is the impression I 
got.

I felt that Walter tried to collect the most common patterns he 
felt people used in C++ (right or wrong) and tried to make those 
patterns simpler in D1 than in C++.

D2 was a pretty radical change in philosophy in my opinion.
Nov 18 2021
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 18 November 2021 at 14:05:37 UTC, Ola Fosheim 
Grøstad wrote:

 Well, IIRC, the old D1 website made a point of D1 being a 
 simplified C++ family language, and having no templates was 
 essential to that simplicity philosophy.


D1 has templates its entire life. Remember, D1 was created just a 
few months before D2.

D itself got templates in more-or-less the modern form we have 


It had templates in any form since D 0.40, released Sep 8, 2002. 
So even if you incorrectly pretend "D1" = any D version prior 
making strings immutable (which was D 2.06; Oct 2007. Jan 2007 is 
when D1 came out btw), it is still *almost* accurate to say D has 
always had templates, since D's initial public release was 
December 2001, less than a year before templates were added.

It is true that Walter was skeptical about templates in the olden 
day, but it had nothing to do with D2.


 D2 was a pretty radical change in philosophy in my opinion.


The history is easy to look up, you don't need to have uninformed 
opinions.
Nov 18 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 14:23:35 UTC, Adam D Ruppe wrote:

 2002. So even if you incorrectly pretend "D1" = any D version 
 prior making strings immutable (which was D 2.06; Oct 2007.


So you want me to call it D0.


 It is true that Walter was skeptical about templates in the 
 olden day, but it had nothing to do with D2.


Ok. Call it D1+ then.

I am referring to the initial philosophy of D being much simpler 
than C++. I am referring to why I picked up D initially. And how 
Walter did communicate that simplicity in his messaging on the 
website.


 The history is easy to look up, you don't need to have 
 uninformed opinions.


Ok, but that does not really matter. Does it? D1+ is template 
heavy. There has been a significant change in philosophy and 
complexity.

That is my viewpoint and opinion. You may claim that it is 
uninformed, but my opinion is not about versioning or 
technicalities, it is about how the perception of complexity in 
the D language has changed over time. Basically a usability 
perspective.
Nov 18 2021
prev sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 18 November 2021 at 14:23:35 UTC, Adam D Ruppe wrote:

 On Thursday, 18 November 2021 at 14:05:37 UTC, Ola Fosheim 
 Grøstad wrote:

 [...]


 D1 has templates its entire life. Remember, D1 was created just 
 a few months before D2.

 D itself got templates in more-or-less the modern form we have 


 It had templates in any form since D 0.40, released Sep 8, 
 2002. So even if you incorrectly pretend "D1" = any D version 
 prior making strings immutable (which was D 2.06; Oct 2007. Jan 
 2007 is when D1 came out btw), it is still *almost* accurate to 
 say D has always had templates, since D's initial public 
 release was December 2001, less than a year before templates 
 were added.

 It is true that Walter was skeptical about templates in the 
 olden day, but it had nothing to do with D2.


 [...]


 The history is easy to look up, you don't need to have 
 uninformed opinions.


Adam is right, D2 big shift was all about const/immutable for 
concurrency, as concurrency at that time was the main opportunity 
goal not to be missed.

/P
Nov 18 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 15:13:59 UTC, Paolo Invernizzi 
wrote:

 Adam is right, D2 big shift was all about const/immutable for 
 concurrency, as concurrency at that time was the main 
 opportunity goal not to be missed.


That is probably technically correct. I've always used D1 to 
refer to "simple D" and D2 to refer to modern D maximising 
meta-programming. Never seen "D0" used anywhere before, but if 
that is needed to avoid noise, then so be it. Let me use that 
from now on. (You usually include version 0.x in the first 
version of a language, so this is a very odd thing to require.)

Vision 1: simple language that can compete with C++ in performance

Vision 2: language that can outdo C++ in meta-programming

There is a drastic shift in complexity and development focus. I 
was attracted to "Vision 1", not "Vision 2". The language I 
started to use followed "Vision 1", not "Vision 2". "Vision 1" 
could have reached a polished state if "Vision 2" had not come 
along.

I am perplexed that anyone could disagree with this viewpoint.
Nov 18 2021
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 18 November 2021 at 15:29:24 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 18 November 2021 at 15:13:59 UTC, Paolo Invernizzi 
 wrote:

 Adam is right, D2 big shift was all about const/immutable for 
 concurrency, as concurrency at that time was the main 
 opportunity goal not to be missed.


 That is probably technically correct. I've always used D1 to 
 refer to "simple D" and D2 to refer to modern D maximising 
 meta-programming. Never seen "D0" used anywhere before, but if 
 that is needed to avoid noise, then so be it. Let me use that 
 from now on. (You usually include version 0.x in the first 
 version of a language, so this is a very odd thing to require.)

 Vision 1: simple language that can compete with C++ in 
 performance

 Vision 2: language that can outdo C++ in meta-programming

 There is a drastic shift in complexity and development focus. I 
 was attracted to "Vision 1", not "Vision 2". The language I 
 started to use followed "Vision 1", not "Vision 2". "Vision 1" 
 could have reached a polished state if "Vision 2" had not come 
 along.

 I am perplexed that anyone could disagree with this viewpoint.


I'm here since a LONG time [1] and at that time pre D1 was 
already used in production.

Walter pragmatic way of moving shined in the early stage, but 
early stage is the moment to experiment things. So you are right, 
*that* D was the simple language that could compete with C++, 
given the state of C++ (and processing power) in early 2000.

D2 had a vision, the D Programming Language. Something went wrong 
with it, something went really really well, and I was for a long 
time on the "break the compatibility" bandwagon and "fix the 
language".

Nowadays I agree with Adam, D is in a stagnant history phase, not 
that is bad (see Elm, for example), it's an opportunity, leverage 
it. Just stop experimenting, and go for D2 as LTS as it is.

[1] https://forum.dlang.org/post/40BB3D47.9030007 inwind.it
Nov 18 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 16:05:53 UTC, Paolo Invernizzi 
wrote:

 I'm here since a LONG time [1] and at that time pre D1 was 
 already used in production.


Aye, I didn't look at the forums when I used D first. I am more 
like Abdulhaq, interested, try out, interesting, but cannot use 
it right now, take break, try it again, but cannot use it right 
now... etc. I think this could be a quite common pattern for D 
users (not on the forum).


 Walter pragmatic way of moving shined in the early stage, but 
 early stage is the moment to experiment things. So you are


If you keep complexity in the design low then you can get quite a 
long way by going by intuition based on experience, but once the 
type system is starting to get complex intuition becomes 
insufficient.

The challenge of language design increases in a nonlinear fashion 
with ambition.



 D2 had a vision, the D Programming Language. Something went 
 wrong with it, something went really really well, and I was for 
 a long time on the "break the compatibility" bandwagon and "fix 
 the language".

 Nowadays I agree with Adam, D is in a stagnant history phase, 
 not that is bad (see Elm, for example), it's an opportunity, 
 leverage it. Just stop experimenting, and go for D2 as LTS as 
 it is.


Fair enough. I guess that is what Abdulhaq asked for.

For me personally, a language optimized for WASM would be nice, 
but that might end up being another language than D. WASM will be 
more important now that Safari also supports WebGL2, I think. 
(online games etc)
Nov 18 2021
prev sibling parent reply forkit <forkit gmail.com> writes:
On Thursday, 18 November 2021 at 13:29:59 UTC, Adam D Ruppe wrote:

...
 The truth is really we're in the most stagnant part of D's 
 history right now.
....


This is why D needs a new motto. I mean, one that actually 
motivates.

'Fast code, fast'.... I wanna puke.
Nov 18 2021
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 18, 2021 at 10:20:49PM +0000, forkit via Digitalmars-d wrote:

 On Thursday, 18 November 2021 at 13:29:59 UTC, Adam D Ruppe wrote:

 ...
 The truth is really we're in the most stagnant part of D's history
 right now.
 ....


 
 This is why D needs a new motto. I mean, one that actually motivates.
 
 'Fast code, fast'.... I wanna puke.


[...]

Wow, so I'm not the only one?  I've been saying this for, oh, years now?
And nobody ever paid any attention.  Every time I see that motto I
cringe and feel the creepycrawlies.


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!
Nov 18 2021
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 22:20:49 UTC, forkit wrote:

 On Thursday, 18 November 2021 at 13:29:59 UTC, Adam D Ruppe 
 wrote:

...
 The truth is really we're in the most stagnant part of D's 
 history right now.
....


 This is why D needs a new motto. I mean, one that actually 
 motivates.

 'Fast code, fast'.... I wanna puke.


I vote for:

«We came from Mars to conquer the world!»
Nov 18 2021
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 18 November 2021 at 22:20:49 UTC, forkit wrote:

 On Thursday, 18 November 2021 at 13:29:59 UTC, Adam D Ruppe 
 wrote:

...
 The truth is really we're in the most stagnant part of D's 
 history right now.
....


 This is why D needs a new motto. I mean, one that actually 
 motivates.

 'Fast code, fast'.... I wanna puke.


I vote for that "From prototype to production"
Nov 18 2021
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean 
 that D2 is now finished? Or will it forever be in a state of 
 ongoing feature development?

 We all know that properly finishing and polishing the last 10% 
 of a software project takes 90% of the time. Is there a 
 timescale for that? What platforms will it support?


What is an example of a successful language that would stop 
feature development?

If D would stop feature development, it wouldn't solve the 
"billion posts" problem of people not vested in D complaining 
loudly in the D forums.
Nov 18 2021
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 18, 2021 at 05:21:40PM +0000, Guillaume Piolat via Digitalmars-d
wrote:

 On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean that
 D2 is now finished? Or will it forever be in a state of ongoing
 feature development?
 
 We all know that properly finishing and polishing the last 10% of a
 software project takes 90% of the time. Is there a timescale for
 that?  What platforms will it support?




Even C has not stopped evolving. And C++.  Why should we stop now?  The
time when D stops evolving is the time it's dead.



 What is an example of a successful language that would stop feature
 development?
 
 If D would stop feature development, it wouldn't solve the "billion
 posts" problem of people not vested in D complaining loudly in the D
 forums.


I suspect these are just the vocal minority. The rest of the happy D
users are too busy actually writing code than debating on the forums.


T

-- 
Meat: euphemism for dead animal. -- Flora
Nov 18 2021
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 18 November 2021 at 17:31:24 UTC, H. S. Teoh wrote:


 Even C has not stopped evolving. And C++.  Why should we stop 
 now?  The time when D stops evolving is the time it's dead.


I am not convinced D has figured out how to evolve. More 
honestly, I am convinced D is not capable of evolving, and will 
in ten years look pretty close to what it is now. Whether that is 
good or bad is up to each programmer to decide. Perl 5 (renamed 
to Perl 7, but that was only for marketing purposes) is still 
widely used and provides a solid platform after 27 years. The 
innovative changes are now in the barely-used Raku.
Nov 18 2021
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 18, 2021 at 05:46:52PM +0000, bachmeier via Digitalmars-d wrote:

 On Thursday, 18 November 2021 at 17:31:24 UTC, H. S. Teoh wrote:
 

 Even C has not stopped evolving. And C++.  Why should we stop now?
 The time when D stops evolving is the time it's dead.


 
 I am not convinced D has figured out how to evolve. More honestly, I
 am convinced D is not capable of evolving, and will in ten years look
 pretty close to what it is now. Whether that is good or bad is up to
 each programmer to decide.


That depends.  It's good in the sense that code I have today will likely
still compile then, modulo some small changes to upgrade the syntax
perhaps.  It's not so good in the sense that design decisions that were
in hindsight the wrong ones will remain and never be corrected.

I'm seriously hoping Andrei pulls off stdv2, because that's the only way
I see to move forward with Phobos.  Otherwise Phobos is just stuck in a
stagnant state and there's no way to move forward.



 Perl 5 (renamed to Perl 7, but that was only for marketing purposes)
 is still widely used and provides a solid platform after 27 years. The
 innovative changes are now in the barely-used Raku.


Yeah, I even forgot it was called Raku once and had to look it up.  :-D
I didn't see anything particular inspiring about it that would motivate
me to spend the effort to learn it.


T

-- 
This sentence is false.
Nov 18 2021
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 18 November 2021 at 17:59:06 UTC, H. S. Teoh wrote:

 I'm seriously hoping Andrei pulls off stdv2, because that's the 
 only way I see to move forward with Phobos.


It's that or we fork the language and seize control then just 
start actually fixing things.
Nov 18 2021
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 18, 2021 at 06:03:07PM +0000, Adam D Ruppe via Digitalmars-d wrote:

 On Thursday, 18 November 2021 at 17:59:06 UTC, H. S. Teoh wrote:

 I'm seriously hoping Andrei pulls off stdv2, because that's the only
 way I see to move forward with Phobos.


 
 It's that or we fork the language and seize control then just start
 actually fixing things.


I have to say, the thought has crossed my mind a few times.  Only thing
is, this community is already so tiny, splitting it would probably mean
death to both resulting dialects.

Though on 2nd thoughts, forking *Phobos* could actually be viable...
Even put it up on dub as a Phobos alternative and let the two compete,
see which one survives.


T

-- 
"The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts." -- Bertrand
Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
Nov 18 2021
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 18 November 2021 at 18:20:18 UTC, H. S. Teoh wrote:

 On Thu, Nov 18, 2021 at 06:03:07PM +0000, Adam D Ruppe via 
 Digitalmars-d wrote:

 On Thursday, 18 November 2021 at 17:59:06 UTC, H. S. Teoh 
 wrote:

 I'm seriously hoping Andrei pulls off stdv2, because that's 
 the only way I see to move forward with Phobos.


 
 It's that or we fork the language and seize control then just 
 start actually fixing things.


 I have to say, the thought has crossed my mind a few times.  
 Only thing is, this community is already so tiny, splitting it 
 would probably mean death to both resulting dialects.

 Though on 2nd thoughts, forking *Phobos* could actually be 
 viable... Even put it up on dub as a Phobos alternative and let 
 the two compete, see which one survives.


 T


Dlang is not alone [1], but at least Evan has strong motivations 
behind that [2].

Forking, well ... Sociomantic tsunami (well, it was a *way* 
different time period) or Weka mekka ...

I still think that the first thing to do is push for a language 
cleanup, prior to start taking care of Phobos. Walter wandered 
what happened with copyctor, aren't they supposed to solve some 
critic low level problem paving the way to ...? The impression is 
that nobody have the complete and sound design in mind (no pun), 
but if such a case, removing complexity is better than adding. I 
would rather fork the frontend, and start removing things, like 
class alias this, shared, and (why not) start thinking if the 
whole const/immutable things as it is worths the complexity it 
brings in the codebase.

Again, my 2c ...

[1] 
https://discourse.elm-lang.org/t/a-process-for-core-library-fixes-and-improvements/7916/17
[2] https://youtu.be/o_4EX4dPppA
Nov 18 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 18:43:57 UTC, Paolo Invernizzi 
wrote:

 adding. I would rather fork the frontend, and start removing 
 things, like class alias this, shared, and (why not) start 
 thinking if the whole const/immutable things as it is worths 
 the complexity it brings in the codebase.


Simplicity is good, but don't throw out the baby with the 
bathwater. Just remove atomic access from shared.

Shared is needed for dealing properly with memory management 
improvements.
Nov 18 2021
prev sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 18 November 2021 at 18:20:18 UTC, H. S. Teoh wrote:

 On Thu, Nov 18, 2021 at 06:03:07PM +0000, Adam D Ruppe via 
 Digitalmars-d wrote:

 On Thursday, 18 November 2021 at 17:59:06 UTC, H. S. Teoh 
 wrote:

 I'm seriously hoping Andrei pulls off stdv2, because that's 
 the only way I see to move forward with Phobos.






Yes, that is my hope. An updated Phobos would change the culture 
of this project and make it exciting to contribute as part of the 
community, whether that's core development or libraries, blog 
posts, whatever.


 It's that or we fork the language and seize control then just 
 start actually fixing things.


 I have to say, the thought has crossed my mind a few times.  
 Only thing is, this community is already so tiny, splitting it 
 would probably mean death to both resulting dialects.


The main reason to fork the language would be to make changes 
that should happen but aren't, or to do things that wouldn't be 
practical in the current language. That should bring in more 
users. On the other hand, if you don't have a *completed* 
language fork, the new won't be doing anything but taking 
manpower from the current. I honestly don't see anything other 
than the GC that would motivate a fork at this time.
Nov 18 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 20:18:43 UTC, bachmeier wrote:

 The main reason to fork the language would be to make changes 
 that should happen but aren't, or to do things that wouldn't be 
 practical in the current language. That should bring in more 
 users. On the other hand, if you don't have a *completed* 
 language fork, the new won't be doing anything but taking 
 manpower from the current. I honestly don't see anything other 
 than the GC that would motivate a fork at this time.


The experiments I did last year with a LDC fork convinced me that 
a lot can be done at the parser and runtime level.

That also has the advantage that the compiler stays compatible in 
a nonbreaking way with the mainline.

I just duplicated the parser and tied it to files ending with 
```.dex```. That way you can mix standard and experimental D code 
with no hiccups.

It is also very easy to do. I started added full unicode support 
to the lexer, added new tokens and went on from there. You can 
gradually do more and more with few bugs since it is mostly 
syntactical.
Nov 18 2021
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 18 November 2021 at 20:18:43 UTC, bachmeier wrote:

 On Thursday, 18 November 2021 at 18:20:18 UTC, H. S. Teoh wrote:

 It's that or we fork the language and seize control then just 
 start actually fixing things.


 I have to say, the thought has crossed my mind a few times.  
 Only thing is, this community is already so tiny, splitting it 
 would probably mean death to both resulting dialects.


 The main reason to fork the language would be to make changes 
 that should happen but aren't, or to do things that wouldn't be 
 practical in the current language.


Think of a fork not as a competing company, but rather as a labor 
strike. The goal isn't actually to coexist with nor to vanquish D 
as we know it today, but rather to save it.

We'd get together and start a fork with the *goal* of getting the 
changes merged back upstream and fixing our broken governance 
model so it never has to happen this way again. Just like how 
labor unions go on strike to negotiate a better (binding) 
contract with the company - they aren't leaving their jobs, they 
are trying to work with the bosses to make their jobs better.

That's what D needs to get on track. Enough people to force some 
positive change to actually get going, then after that, we can 
negotiate on the specifics to merge back in.
Nov 18 2021
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 18, 2021 at 08:36:52PM +0000, Adam D Ruppe via Digitalmars-d wrote:
[...]

 Think of a fork not as a competing company, but rather as a labor
 strike.  The goal isn't actually to coexist with nor to vanquish D as
 we know it today, but rather to save it.
 
 We'd get together and start a fork with the *goal* of getting the
 changes merged back upstream and fixing our broken governance model so
 it never has to happen this way again. Just like how labor unions go
 on strike to negotiate a better (binding) contract with the company -
 they aren't leaving their jobs, they are trying to work with the
 bosses to make their jobs better.


[...]

OK, so the big question: who's "we"?

And who are "we" negotiating with, and what specific result(s) are we
after?


T

-- 
All problems are easy in retrospect.
Nov 18 2021
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 18 November 2021 at 23:19:20 UTC, H. S. Teoh wrote:

 OK, so the big question: who's "we"?


The international proletariat.


 And who are "we" negotiating with


The bourgeois class.


 and what specific result(s) are we after?


The dissolution of all class distinctions.


Duh.


ok fine really it is anyone who wants to see real change in the 
language vs the leadership. And what want to see is the 
aforementioned change. Personally what I want is a new leadership 
structure, a steering group of probably seven, maybe eleven, 
selected by D stakeholders on some term basis, probably annually, 
who have authority to make whatever changes they see fit. From 
there, they guide the language.

Now, what I'd like to see from the steering group is:

1) A new DIP policy that dispenses with the pretensions of 
grandeur and focuses on getting things done. These aren't Ph.D. 
theses, they're ways to solicit use cases and associated feature 
requests and technical analyses from the community. The process I 
propose is letting the steering committee deliberate on them in a 
private forum thread, which is then made public (but read only) 
after the decision is locked. This decision can thus be reviewed 
without being bikeshedded to hell.

I would vote for steering committee members who weigh changes 
with a cost/benefit eye. Some breaking changes are short term 
pain for long term gain. That's worth it.

2) A radically different approach to Phobos development that is 
significantly more open than it is now. Phobos is currently where 
code goes to die. It should be where code goes to thrive among 
the community. Breaking changes are discouraged, but made when 
necessary.

I've heard people say the package manager renders the standard 
library obsolete, but this isn't really true. In fact, I think it 
might be the opposite: a strong stdlib gives a solid foundation 
for reliable and interoperable third party packages.

What I'd do is to curate things from the community that can be 
tested and adopted if need be. Then if there's multiple options, 
work with the authors to abstract out some common interface into 
Phobos and get the others to use them. Then other packages can 
depend on the Phobos interface as users swap out implementations.

But again, the steering group would have the final say. I'd just 
want them to create a process that can be reliably delegated so 
it isn't using any particular bottleneck; a decentralized 
development model of a centralized library. They'd say what they 
want then they can pull from community work if/when it pops up.

3) The steering group would also have access to the foundation 
budget for hiring outside consultants when necessary. While this 
might be programming work sometimes we'd more likely need outside 
help for things like marketing since we have significant in-house 
code talent.


But what I'd push for is the steering group reform specifically 
as a condition to stop the fork. The other details can be worked 
out once we have that formed. The steering group must have 
binding authority - if they decide a change is going to happen, 
it gets merged in and no individual can overrule that.
Nov 18 2021
next sibling parent forkit <forkit gmail.com> writes:
On Friday, 19 November 2021 at 03:00:14 UTC, Adam D Ruppe wrote:

 ..

 But what I'd push for is the steering group reform specifically 
 as a condition to stop the fork. The other details can be 
 worked out once we have that formed. The steering group must 
 have binding authority - if they decide a change is going to 
 happen, it gets merged in and no individual can overrule that.


A steering group needs members who are permanent, and members who 
are rotated (on a fixed term). Otherwise it will lead to rot.

Getting a permanent seat on the steering group needs to be 
something that is hard fought.

There is only one person I know of, that deserves that position, 
at the moment (possibly two, but I'll stick with one for now).
Nov 18 2021
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 November 2021 at 03:00:14 UTC, Adam D Ruppe wrote:

 aforementioned change. Personally what I want is a new 
 leadership structure, a steering group of probably seven, maybe 
 eleven, selected by D stakeholders on some term basis, probably 
 annually, who have authority to make whatever changes they see 
 fit. From there, they guide the language.


You need representation (diversity) otherwise you will end up 
with many of the same issues.

You also need a shared vision. Simpler or more features?

You also need to restructure compiler internals to get more 
people interested. So a merge is not realistic.


  The process I propose is letting the steering committee 
 deliberate on them in a private forum thread, which is then 
 made public (but read only) after the decision is locked. This 
 decision can thus be reviewed without being bikeshedded to hell.


Look up Group Think. The road to hell is paved with good 
intensions.
Nov 19 2021
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Friday, 19 November 2021 at 08:07:11 UTC, Ola Fosheim Grøstad 
wrote:

 Look up Group Think. The road to hell is paved with good 
 intensions.


(To be fair, look up design by committee and analysis paralysis 
as well.)
Nov 19 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 November 2021 at 08:08:38 UTC, FeepingCreature 
wrote:

 On Friday, 19 November 2021 at 08:07:11 UTC, Ola Fosheim 
 Grøstad wrote:

 Look up Group Think. The road to hell is paved with good 
 intensions.


 (To be fair, look up design by committee and analysis paralysis 
 as well.)


"Analysis paralysis" in PL design is a sign that the chosen 
approach does not lead to the goal, like having an unsound 
typesystem. Start over from scratch is often the better solution.
Nov 19 2021
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 19 November 2021 at 08:07:11 UTC, Ola Fosheim Grøstad 
wrote:

 Look up Group Think. The road to hell is paved with good 
 intensions.


No one pretends that democracy is perfect or all-wise. Indeed it 
has been said that democracy is the worst form of Government 
except for all those other forms that have been tried from time 
to time.…
Nov 19 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 November 2021 at 13:59:04 UTC, Adam D Ruppe wrote:

 On Friday, 19 November 2021 at 08:07:11 UTC, Ola Fosheim 
 Grøstad wrote:

 Look up Group Think. The road to hell is paved with good 
 intensions.


 No one pretends that democracy is perfect or all-wise. Indeed 
 it has been said that democracy is the worst form of Government 
 except for all those other forms that have been tried from time 
 to time.…



I wish you well with your democratic endeavour. It will be 
interesting to see what you achieve!

There are techniques to avoid Group Think, but one has to be 
aware of the phenomenon and take the appropriate steps. You can 
do that.
Nov 19 2021
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 November 2021 at 13:59:04 UTC, Adam D Ruppe wrote:

 On Friday, 19 November 2021 at 08:07:11 UTC, Ola Fosheim 
 Grøstad wrote:

 Look up Group Think. The road to hell is paved with good 
 intensions.


 No one pretends that democracy is perfect or all-wise. Indeed 
 it has been said that democracy is the worst form of Government 
 except for all those other forms that have been tried from time 
 to time.…


Also, if you haven't already read this book, consider borrowing 
it from a library:

Forsyth, *Group Dynamics*

It gives perspectives on dynamics in groups that can be useful, 
based on research. I've seen it used in psychology and software 
process improvement classes. It won't give you answers, but if 
you haven't read a similar book before you might view dynamics in 
groups differently after reading it.

I hope you take no offence at this suggestion, but setting up a 
group for the purpose you suggest is challenging. For instance, 
if you have only one member with a computer science background in 
the group, then that member might get undue influence (for good 
or worse).

I totally believe you can do this, but you have to think ahead 
about what can happen, I think.
Nov 19 2021
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 17:59:06 UTC, H. S. Teoh wrote:

 I'm seriously hoping Andrei pulls off stdv2, because that's the 
 only way I see to move forward with Phobos.  Otherwise Phobos 
 is just stuck in a stagnant state and there's no way to move 
 forward.


I'll never understand why people put any emphasis on Phobos! 
Anyone can create their own, the only blocker is if language 
features makes it hard (like RC).
Nov 18 2021
prev sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Thursday, 18 November 2021 at 17:31:24 UTC, H. S. Teoh wrote:

 On Thu, Nov 18, 2021 at 05:21:40PM +0000, Guillaume Piolat via 
 Digitalmars-d wrote:

 On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will 
 mean that D2 is now finished? Or will it forever be in a 
 state of ongoing feature development?
 
 We all know that properly finishing and polishing the last 
 10% of a software project takes 90% of the time. Is there a 
 timescale for that?  What platforms will it support?




 Even C has not stopped evolving. And C++.  Why should we stop 
 now?  The time when D stops evolving is the time it's dead.



 What is an example of a successful language that would stop 
 feature development?
 
 If D would stop feature development, it wouldn't solve the 
 "billion posts" problem of people not vested in D complaining 
 loudly in the D forums.


 I suspect these are just the vocal minority. The rest of the 
 happy D users are too busy actually writing code than debating 
 on the forums.


 T


I'm not suggesting, as I made explicitly clear in a previous 
post, to stop new feature development.

I think some D users would like to see increased user numbers and 
are happy to get good practical suggestions as to how to do that. 
Andrei for one. It would help the hobbyists too because there 
would be more hands to do more work.
Nov 18 2021
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 18 November 2021 at 17:21:40 UTC, Guillaume Piolat 
wrote:

 What is an example of a successful language that would stop 
 feature development?


I think it is a more fair question to ask for an example of a 
successful system level language without a polished stable branch?

I mean modern C++ compilers are pretty polished. It may take a 
year to get there after the ISO standard is published, but when 
it is done, the compiler is shiny with bells and whistles (more 
compiler options than you wish for).
Nov 18 2021
prev sibling parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Thursday, 18 November 2021 at 17:21:40 UTC, Guillaume Piolat 
wrote:

 On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean 
 that D2 is now finished? Or will it forever be in a state of 
 ongoing feature development?

 We all know that properly finishing and polishing the last 10% 
 of a software project takes 90% of the time. Is there a 
 timescale for that? What platforms will it support?


 What is an example of a successful language that would stop 
 feature development?


I specifically explained in a follow-up post, previous to yours, 
that I'm not suggesting that new feature development be stopped. 
I am simply and genuinely asking a simple question. Check my 
previous posts if you think I'm trolling - I'm not.


 If D would stop feature development, it wouldn't solve the 
 "billion posts" problem of people not vested in D complaining 
 loudly in the D forums.


I'm not complaining, I'm explaining why I think that corporate 
users are not using D. I'm hoping to help those people who *do* 
care about why D remains relatively unknown and unused, and I'm 
doing it politely. I don't feel the tiniest emotion about it, I 
just want to give a POV that I think can help lift the number of 
users.
Nov 18 2021
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 18 November 2021 at 18:05:38 UTC, Abdulhaq wrote:

 I just want to give a POV that I think can help lift the number 
 of users.


_Doing things with D_ help lift the number of users.

Constant, harsh, unsubstantiated criticism on the main 
communication channel (these very forums) for D doesn't help 
getting more users. No language has an anti-themselves campaign 
going on for years on their main communication channels.

Imagine you child is bullied at school. Would your idea of 
helping him is to _make public criticism of the many ways he 
would have to change in order to have friends_?
No, this is just bullying, by people who enjoy doing just that.
Nov 19 2021
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat 
wrote:

 Imagine you child is bullied at school. Would your idea of 
 helping him is to _make public criticism of the many ways he 
 would have to change in order to have friends_?
 No, this is just bullying, by people who enjoy doing just that.


We should collect criticism,
If you want to criticize, please see whether the opinion has been 
put forward.
Nov 19 2021
next sibling parent zjh <fqbqrr 163.com> writes:
On Friday, 19 November 2021 at 11:36:48 UTC, zjh wrote:


 We should collect criticism,


`Posts` should also be classified.
Such as `opinion/question/`..., etc.
Our problem is organization.
Excellent posts should also be scored,And reward.
etc...
Nov 19 2021
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 19 November 2021 at 11:36:48 UTC, zjh wrote:

 On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat 
 wrote:

 Imagine you child is bullied at school. Would your idea of 
 helping him is to _make public criticism of the many ways he 
 would have to change in order to have friends_?
 No, this is just bullying, by people who enjoy doing just that.


 We should collect criticism,
 If you want to criticize, please see whether the opinion has 
 been put forward.


Yeah, I wouldn't want the forums to be a place like "we do not 
tolerate dissent". It's just that unrelenting criticism that 
repeats the same things over and over again gets a little boring 
to read...
Nov 19 2021
next sibling parent zjh <fqbqrr 163.com> writes:
On Friday, 19 November 2021 at 13:07:04 UTC, jmh530 wrote:


 Yeah, I wouldn't want the forums to be a place like "we do not 
 tolerate dissent". It's just that unrelenting criticism that 
 repeats the same things over and over again gets a little 
 boring to read...


D should make good use of the forum.
Now the forum resources are not well utilized.
Many people repeat his opinion over and over again.
But others still don't know your point of view.
Nov 19 2021
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 19 November 2021 at 13:07:04 UTC, jmh530 wrote:

 On Friday, 19 November 2021 at 11:36:48 UTC, zjh wrote:

 On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat 
 wrote:

 Imagine you child is bullied at school. Would your idea of 
 helping him is to _make public criticism of the many ways he 
 would have to change in order to have friends_?
 No, this is just bullying, by people who enjoy doing just 
 that.


 We should collect criticism,
 If you want to criticize, please see whether the opinion has 
 been put forward.


 Yeah, I wouldn't want the forums to be a place like "we do not 
 tolerate dissent". It's just that unrelenting criticism that 
 repeats the same things over and over again gets a little 
 boring to read...


Part of the problem here, I think, is that people are more 
strongly motivated to speak up about their opinions when there is 
something they are unsatisfied with. So discussions like this 
will be biased towards the things people don't like about D, even 
if they are relatively happy with the language overall.
Nov 19 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 November 2021 at 14:05:17 UTC, Paul Backus wrote:

 Part of the problem here, I think, is that people are more 
 strongly motivated to speak up about their opinions when there 
 is something they are unsatisfied with. So discussions like 
 this will be biased towards the things people don't like about 
 D, even if they are relatively happy with the language overall.


Actually, the *biggest* problem for the decision makers of D is 
that the average person who does use D from time to time never 
speaks up about what they are happy/unhappy with. So there is a 
big silent majority.

I didn't read the D forums for years. Random incident that I did. 
I only started to write here because Manu tried to argue for a 
direction that would make D better for systems development. So I 
wanted to back him. If Manu had not been persistent in his quest, 
then I'd probably would have put D back in the drawer for good.

It is of course possible to continue to make decisions based on 
the tiny hardcore that populate the forums, but then you won't 
have an ecosystem. And well, what is the point of having powerful 
meta-programming if there are no frameworks (except vibe.d) that 
are built with it?
Nov 19 2021
parent reply BoraxMan <rotflol2 hotmail.com> writes:
On Friday, 19 November 2021 at 15:06:28 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 19 November 2021 at 14:05:17 UTC, Paul Backus wrote:

 Part of the problem here, I think, is that people are more 
 strongly motivated to speak up about their opinions when there 
 is something they are unsatisfied with. So discussions like 
 this will be biased towards the things people don't like about 
 D, even if they are relatively happy with the language overall.


 Actually, the *biggest* problem for the decision makers of D is 
 that the average person who does use D from time to time never 
 speaks up about what they are happy/unhappy with. So there is a 
 big silent majority.

 I didn't read the D forums for years. Random incident that I 
 did. I only started to write here because Manu tried to argue 
 for a direction that would make D better for systems 
 development. So I wanted to back him. If Manu had not been 
 persistent in his quest, then I'd probably would have put D 
 back in the drawer for good.

 It is of course possible to continue to make decisions based on 
 the tiny hardcore that populate the forums, but then you won't 
 have an ecosystem. And well, what is the point of having 
 powerful meta-programming if there are no frameworks (except 
 vibe.d) that are built with it?


Another "silent majority" here.  I do some hobby programming, and 
while I like D the main barrier isn't the language but the way 
the language fits in with the OS (for me its Linux).

For D, there is this guide to packaging for Fedora
https://docs.fedoraproject.org/en-US/packaging-guidelines/D/
but it said that D doesn't support shared libraries and as an 
exception, static linking is OK.  Is this even correct?  It does 
answer my other question, should I link using GDC or LDC.  Also, 
if I use DUB, how does that work?  What is the process then?

This link implies you can create shared libraries
https://dlang.org/articles/dll-linux.html

Aside from the actual language, people are looking to see how the 
use of that language, the tools, fit in with the systems they are 
developing for.  My choice of language isn't simply about the 
language, but how it builds actual distributed software.  Best 
practices for how to create software.

For example, I've looked at Tilix, and noted that it uses libgtkd 
and LDC, and a dub.json file.  It would be good to know the ins 
and outs, what you should do, what you shouldn't do, to say, make 
a Linux software package that can be built into a .DEB and .RPM.  
Can it be done if dub has to download dependencies?  How to 
package?

It might seem trivial, but there are the little things that I 
think make a difference.  I might write posts about this myself 
when I know that advice I'm giving is good advice.
Nov 26 2021
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 27/11/2021 2:12 PM, BoraxMan wrote:

 For D, there is this guide to packaging for Fedora
 https://docs.fedoraproject.org/en-US/packaging-guidelines/D/
 but it said that D doesn't support shared libraries and as an exception, 
 static linking is OK.  Is this even correct?  It does answer my other 
 question, should I link using GDC or LDC.  Also, if I use DUB, how does 
 that work?  What is the process then?


It is completely out of date.
Nov 26 2021
parent bachmeier <no spam.net> writes:
On Saturday, 27 November 2021 at 01:41:07 UTC, rikki cattermole 
wrote:

 On 27/11/2021 2:12 PM, BoraxMan wrote:

 For D, there is this guide to packaging for Fedora
 https://docs.fedoraproject.org/en-US/packaging-guidelines/D/
 but it said that D doesn't support shared libraries and as an 
 exception, static linking is OK.  Is this even correct?  It 
 does answer my other question, should I link using GDC or 
 LDC.  Also, if I use DUB, how does that work?  What is the 
 process then?


 It is completely out of date.


Yeah, it's dated 2010 and the package requires tango, so just a 
tad out of date.
Nov 26 2021
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat 
wrote:

 On Thursday, 18 November 2021 at 18:05:38 UTC, Abdulhaq wrote:

 I just want to give a POV that I think can help lift the 
 number of users.


 _Doing things with D_ help lift the number of users.


D has enough users, but I project most of them are like Abdulhaq 
and myself. They write D code occasionally in their hobbyspace 
and would like to see a situation where you would choose D 
because it is objectively the best choice. Right now D is not the 
most rational choice, unless you do exactly what you do: write 
your own foundation and extend the compiler with what you need 
(like SIMD support). That is a lot to demand of others… So you 
are very demanding in your attitude!

I've come to the conclusion that for me D will never move out of 
hobbyspace (well, maybe if I write an audioplugin). That 
conclusion made me happier about D!

Abdulhaq still dreams of using D outside his hobbyspace, but he 
clearly cannot make a salespitch at his workplace by appealing to 
emotions, he has to make a rational argument for it.



 No, this is just bullying, by people who enjoy doing just that.


You've bullied me repeatedly. I never bullied you. :-P Bullying a 
technical construct and a development process is not a concept… 
Hurting the compiler's self confidence or something?

For instance, let us return to the introduction of ``` nogc```. 
If you read the DIP thread on that you'll see that Manu, Mike and 
other low level coders were not enthusiastic. Manu wanted ARC at 
the time. You know, a solid compiler backed memory management 
solution. The survey from 2010 shows that nobody wanted 
```-nogc``` as an option. The conclusion is that everybody that 
use D wants managed memory backed by the compiler (some kind of 
automatic memory management). ``` nogc``` does not satisfy that 
need, it is more like an escape-hatch.

At the end of the day it comes down to wanting to write code that 
is and looks beautiful.

You want this yourself. You want to get rid of the " " in front 
of attributes.

Aesthetics matter.

Aesthetics in memory management.
Aesthetics in semantics.
Aesthetics in syntax.

So when you go to bed you can go to sleep knowing that you 
created something beautiful that day.

People want this from D. I think you do too.
Nov 19 2021
next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Friday, 19 November 2021 at 11:49:40 UTC, Ola Fosheim Grøstad 
wrote:


 You want this yourself. You want to get rid of the " " in front 
 of attributes.

 Aesthetics matter.


They are also highly subjetive and context-dependent. I find " " 
to be weirdly cute.
Nov 19 2021
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Friday, 19 November 2021 at 12:15:02 UTC, Max Samukha wrote:

 On Friday, 19 November 2021 at 11:49:40 UTC, Ola Fosheim 
 Grøstad wrote:


 You want this yourself. You want to get rid of the " " in 
 front of attributes.

 Aesthetics matter.


 They are also highly subjetive and context-dependent. I find 
 " " to be weirdly cute.


*subjective
Nov 19 2021
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 November 2021 at 12:15:02 UTC, Max Samukha wrote:

 On Friday, 19 November 2021 at 11:49:40 UTC, Ola Fosheim 
 Grøstad wrote:


 You want this yourself. You want to get rid of the " " in 
 front of attributes.

 Aesthetics matter.


 They are also highly subjetive and context-dependent. I find 
 " " to be weirdly cute.


Yes, this is where usability studies with real programmers can 
help. :-)

Probably never been done with D.
Nov 19 2021
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
Nim forums are moderated: https://forum.nim-lang.org/
Rust forums are moderated: https://users.rust-lang.org/
Go forums are moderated: https://forum.golangbridge.org/
If you browse them, I doubt you will find the kind of systematic 
negativity one can find here.

If you enjoy reading HN and Reddit, it's also because they are 
heavily moderated.

This is just my opinion, but I think the moderation on the D 
forums should be a bit more ban-happy.
Nov 19 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 November 2021 at 16:30:14 UTC, Guillaume Piolat 
wrote:

 This is just my opinion, but I think the moderation on the D 
 forums should be a bit more ban-happy.


The best moderation is done by moderators that are actively 
participating and diffusing conflict. Or just close threads that 
have become unproductive. Or move threads to an off-topic forum.

Flamewars tend to arise from misinterpretation or just two people 
being tired after work, divorce or whatever… But there aren't 
actually many flamewars in the D forums. Just strategic 
disagreement, passionate disagreement.

You have many people being passionate because they want to write 
beautiful code. And well, a simpler language than C++ allows your 
write more beautiful code. Maybe that is also why you use D 
daily. Maybe most of those that you would ban actually are in 
agreement with you if you sat down around a coffee table? Maybe 
they get frustrated after several years, because they cannot do 
like you, write beautiful code every day?

I don't know.

The only thing I know is that I appreciate that D now is on track 
to become what I was looking for many years ago. Despite it 
happening in slow motion.

I am not unhappy with that. I would be much more happy with a D3, 
because then things would not move in slow motion.

But I don't depend on D and totally understand that you and 
others have more reasons to feel passionate about D2 as it is 
today than those of use that only have D as a hobby.

Anyway, I am pretty sure that if you, I and the OP sat down 
around a coffee-table, then we would agree on *most* things if we 
shared our perspectives face to face. Maybe we can do that one 
day.

Cheers!
Nov 19 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Friday, 19 November 2021 at 16:47:33 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 19 November 2021 at 16:30:14 UTC, Guillaume Piolat 
 wrote:

 [...]


 The best moderation is done by moderators that are actively 
 participating and diffusing conflict. Or just close threads 
 that have become unproductive. Or move threads to an off-topic 
 forum.

 [...]


Maybe you just have to wait until Dconf can be held physically 
again :P
Nov 19 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 November 2021 at 17:50:36 UTC, Tejas wrote:

 Maybe you just have to wait until Dconf can be held physically 
 again :P


Maybe, but I don't think those that go to conferences represent 
the majority. C++ conference presentations often show more high 
level code than people usually write... A distorted reality.

What people in the D-forums don't get is that people who come to 
complain on the forums and are perceived as detractors actually 
represent that silent majority that never visit the forums, but 
who want a completed system level development language solution, 
not a glorified scripting language for scientific computing. 
There is no future for D in that (too many competing solutions 
backed by arrays of GPUs in the cloud).

The regulars on language forums tend to be die-hard-fans, which 
leads to a distorted picture of reality. You can of course ban 
the signal of frustration, and create an echo chamber, but then 
there is no reality check feedback in the loop. And the language 
fades away and becomes a relic of the past. Like most languages. 
It is not unusual, it is typical.
Nov 20 2021
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 20 November 2021 at 10:49:08 UTC, Ola Fosheim 
Grøstad wrote:

Anyway, I like `D`.
I hope `D` can solve `its own problems`.
Nov 20 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 20 November 2021 at 11:09:35 UTC, zjh wrote:

 I hope `D` can solve `its own problems`.


Yes, if D ranks its own problems on a list and give them high 
priority then they can be solved.

If weaknesses are brushed under the carpet, like having a 
compiler that does not manage memory properly, then they can't 
solve the problems.

But they should never complain that they lack manpower. I and 
others with me warned strongly against not giving the highest 
priority to compiler backed memory management over seven years 
ago, and made it clear that other (then small) languages would 
rob them of users and manpower. It was made very explicit, so 
they knew, but ignored it. It was made clear repeatedly that this 
outcome was easy to predict. People here think that is trolling. 
The reality is that when many independently say it in these 
forums then it is not noise, it is a very strong signal. Because 
most users who feel the same, don't say it. So if 30 people say 
it, then maybe 3000 feel it.

Take care, and have fun with D and other languages! You can use 
as many as you like :-)
Nov 20 2021
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 20 November 2021 at 12:06:35 UTC, Ola Fosheim 
Grøstad wrote:

D's mistake is superstitious `GC`.
Many other small language users used to use `d`. Disappointed and 
left.
`D` should listen to the right opinion. Many people's opinions 
are just misleading.
`D` now should be careful, not to make any `big mistakes`.
Nov 20 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 20 November 2021 at 12:18:49 UTC, zjh wrote:

 On Saturday, 20 November 2021 at 12:06:35 UTC, Ola Fosheim 
 Grøstad wrote:

 D's mistake is superstitious `GC`.
 Many other small language users used to use `d`. Disappointed 
 and left.
 `D` should listen to the right opinion. Many people's opinions 
 are just misleading.
 `D` now should be careful, not to make any `big mistakes`.


Yes, but you should not expect it to change soon. That will make 
you miserable. So, take a break if you feel disappointed. Have 
fun with other languages and come back next year and see if 
things fit you better. :-)
Nov 20 2021
parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 20 November 2021 at 12:27:46 UTC, Ola Fosheim 
Grøstad wrote:


 Have fun with other languages and come back next year and see 
 if things fit you better. :-)


what D needed is `reasonable organization`.
Not only organize `people`, but also organize 
`code/articles/forum informations/links` etc.
With effective organization, combat effectiveness can be doubled.

Other languages don't look good. I'm not used to using them.The 
beauty of language is also `combat effectiveness`.
Nov 20 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 20 November 2021 at 13:01:59 UTC, zjh wrote:

 what D needed is `reasonable organization`.
 Not only organize `people`, but also organize 
 `code/articles/forum informations/links` etc.
 With effective organization, combat effectiveness can be 
 doubled.


Yes, I am sure that everyone would be very happy if you wrote 
such items! Maybe more people in your country would discover the 
language? Such a large country, with many clever people, can make 
a major impact, I think. If you bring more people to the 
language, that think the same way as you do yourself, then that 
can change the direction over time. Just be patient. I had a 
chinese girlfriend a long time ago, and since then I always have 
felt more connected to your country, even though is is far away. 
I would love to see more chinese D programmers! :-D
Nov 20 2021
parent zjh <fqbqrr 163.com> writes:
On Saturday, 20 November 2021 at 13:40:21 UTC, Ola Fosheim 
Grøstad wrote:


 I would love to see more chinese D programmers! :-D.


Me too.
Nov 20 2021
prev sibling next sibling parent reply workman <workman gmail.com> writes:
On Saturday, 20 November 2021 at 12:06:35 UTC, Ola Fosheim 
Grøstad wrote:


 Yes, if D ranks its own problems on a list and give them high 
 priority then they can be solved.

 If weaknesses are brushed under the carpet, like having a 
 compiler that does not manage memory properly, then they can't 
 solve the problems.

 But they should never complain that they lack manpower. I and 
 others with me warned strongly against not giving the highest 
 priority to compiler backed memory management over seven years 
 ago, and made it clear that other (then small) languages would 
 rob them of users and manpower. It was made very explicit, so 
 they knew, but ignored it. It was made clear repeatedly that 
 this outcome was easy to predict. People here think that is 
 trolling. The reality is that when many independently say it in 
 these forums then it is not noise, it is a very strong signal. 
 Because most users who feel the same, don't say it. So if 30 
 people say it, then maybe 3000 feel it.

 Take care, and have fun with D and other languages! You can use 
 as many as you like :-)


I agree with your option.

Few years ago I decide to give up on D runtime and Phobos, at 
that time I believe it will take decade to match the need I want 
to do with D.

One can still build ref count betterC with cross platform app, 
but it is hard and not always get well support from here.  better 
to move on to other language choice.

D want to be betterC, better C++/CLI, better Java.  It is better 
at some point,  but not better if you want to made a product most 
time.

C++/CLI JAVA is replace by GO/Rust in a lot new project/product, 
there is so much companies refactor they product by GO or Rust.

C++/CLI, Java will not go away, but the market is smaller day by 
day. D still try to eat this dying market cake, and not get a 
bite yet.

Rust/GO is product oriented programming, D is NOT.
Nov 20 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 20 November 2021 at 13:55:51 UTC, workman wrote:

 On Saturday, 20 November 2021 at 12:06:35 UTC, Ola Fosheim 
 Grøstad wrote:


 [...]


 I agree with your option.

 [...]


If Rust didn't suck for productivity I would use it. I look at 
someone doing X in Rust and it takes much longer for them to
Nov 20 2021
next sibling parent reply workman <workman gmail.com> writes:
On Saturday, 20 November 2021 at 15:20:21 UTC, Imperatorn wrote:

 If Rust didn't suck for productivity I would use it. I look at 
 someone doing X in Rust and it takes much longer for them to 



Compare (https://github.com/trending/rust 
https://github.com/trending/c%23  
https://github.com/trending/scala) with 
https://github.com/trending/d.


Rust is made into linux/window kernel,  Video compression, 
Digital Coin, distribute Database/store, AI/Scientific Computing, 
  UI/Browser Engine,  Web framework,  WASM,  Terminal tools/shell, 
  Javascript/type script preprocessing tools, microVM and docker 
replacement, TLS/SSL/Crypto.

Google/Microsoft/Amazon/Cloudflare/Dropbox/Uber/Netflix/LinkIn 
has a lot product switch from C/C++ into RUST or GO, and used by 
real custom.


And there is blooming small companies from China build they 
product on GO/RUST, like PingCap TiDB and a lot others.


you know GO/Javascipt/Rust you will find a job more easely.

I dare to say GO vs D job opportunity is like 10000000 vs 1.
Nov 20 2021
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 20 November 2021 at 15:44:50 UTC, workman wrote:

 On Saturday, 20 November 2021 at 15:20:21 UTC, Imperatorn wrote:

 [...]


 Compare (https://github.com/trending/rust 
 https://github.com/trending/c%23  
 https://github.com/trending/scala) with 
 https://github.com/trending/d.

 [...]


Sure.

But I didn't say I was interested in making money. I said I was 
interested in productivity.
Nov 20 2021
parent reply workman <workman gmail.com> writes:
On Saturday, 20 November 2021 at 16:32:43 UTC, Imperatorn wrote:

 Sure.

 But I didn't say I was interested in making money. I said I was 
 interested in productivity.



I am not sure how to quantify productivity, maybe D has more 
productivity, but has much less product.
Nov 20 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 20 November 2021 at 16:40:50 UTC, workman wrote:

 On Saturday, 20 November 2021 at 16:32:43 UTC, Imperatorn wrote:

 Sure.

 But I didn't say I was interested in making money. I said I 
 was interested in productivity.



 I am not sure how to quantify productivity, maybe D has more 
 productivity, but has much less product.


I measure productivity as the number of seconds it takes to get 
from A to B.
Nov 20 2021
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Saturday, 20 November 2021 at 15:44:50 UTC, workman wrote:


 if you know GO/Javascipt/Rust you will find a job more easely.

 I dare to say GO vs D job opportunity is like 10000000 vs 1.


My personal story, might be a bit incidential though: I applied 
at like 50 programming jobs at Finland, that were using common 

every single of them. Granted I think it was a close call in a 

somewhat viable C++ programmer because it's not that different 
from D, and I have also used it a bit.

Then, the _first_ D workplace I applied to, Symmetry Investments, 
accepted me. Of course it might have something to do with that it 
was also the first non-Finnish company I applied to, but still. 
So much from the theory that D can't get you a job.
Nov 20 2021
prev sibling parent workman <workman gmail.com> writes:
On Saturday, 20 November 2021 at 15:20:21 UTC, Imperatorn wrote:

 If Rust didn't suck for productivity I would use it. I look at 
 someone doing X in Rust and it takes much longer for them to 



TiDB is a few people build with Go and Rust few years ago, worth 
0.34 billion today.
Nov 20 2021
prev sibling next sibling parent claptrap <clap trap.com> writes:
On Saturday, 20 November 2021 at 12:06:35 UTC, Ola Fosheim 
Grøstad wrote:

 On Saturday, 20 November 2021 at 11:09:35 UTC, zjh wrote:

 I hope `D` can solve `its own problems`.


 But they should never complain that they lack manpower. I and 
 others with me warned strongly against not giving the highest 
 priority to compiler backed memory management over seven years 
 ago, and made it clear that other (then small) languages would 
 rob them of users and manpower. It was made very explicit, so 
 they knew, but ignored it. It was made clear repeatedly that 
 this outcome was easy to predict. People here think that is 
 trolling. The reality is that when many independently say it in 
 these forums then it is not noise, it is a very strong signal. 
 Because most users who feel the same, don't say it. So if 30 
 people say it, then maybe 3000 feel it.


I think most people ignore your posts mate.
Nov 20 2021
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 20 November 2021 at 12:06:35 UTC, Ola Fosheim 
Grøstad wrote:

 People here think that is trolling. The reality is that when 
 many independently say it in these forums then it is not noise, 
 it is a very strong signal.


Non-sequitur.

Most people don't write at all on Internet forums.
You can't be more representative of the general public than other 
members of this forum while writing about 20% of the words it 
contains total. That makes you the outlier, not the general 
public.
Nov 20 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 20 November 2021 at 15:52:37 UTC, Guillaume Piolat 
wrote:

 Non-sequitur.

 Most people don't write at all on Internet forums.
 You can't be more representative of the general public than 
 other members of this forum


I am of course not a representative of the general D programmer. 
Did you read what I wrote?

If 1 person points out X. Then it might be an aberration.

If 30 people independently point out X. Then it is a strong 
signal.
Nov 21 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 21 November 2021 at 14:43:00 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 20 November 2021 at 15:52:37 UTC, Guillaume Piolat 
 wrote:

 Non-sequitur.

 Most people don't write at all on Internet forums.
 You can't be more representative of the general public than 
 other members of this forum


 I am of course not a representative of the general D 
 programmer. Did you read what I wrote?


In case I was unclear:

1. The typical D user is not a regular on the forums. Only the 
hardcore users are regulars. Fulfilling their wishes does not 
necessarily satisfy the non-hardcore users.

2. The non-hardcore users use D every now and then. This is the 
majority. They are happy about some thing, unhappy about other 
things. Happy enough to dabble. Unhappy enough to not build 
larger things like frameworks.

Then you need to figure out what they are unhappy about and fix 
it. Until then the eco system will not grow. No matter how many 
users you have in category 2.

It is that simple. Yes?
Nov 21 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 20 November 2021 at 10:49:08 UTC, Ola Fosheim 
Grøstad wrote:

 Maybe, but I don't think those that go to conferences represent 
 the majority. C++ conference presentations often show more high 
 level code than people usually write... A distorted reality.

 What people in the D-forums don't get is that people who come 
 to complain on the forums and are perceived as detractors 
 actually represent that silent majority that never visit the 
 forums, but who want [whatever].


Sure, forums don't filter out people who aren't already committed 
like conferences tend to do. But also: sampling forum complainers 
has its own biases, they tend to be those of the inpatient and 
furious nature. Also more or less forum complaining suffers from 
cheapness of talk. Conference people have usually had to consider 
the limits of time/manpower/influence when pushing for changes. 
Forum complainers often have not.

That many people have been whining about the same things does not 
show the forum ranters any less biased. Conference people also 
often bring up same things as each other, yet we accept there is 
a bias in sampling just their opinions.

Do you think listening to the forum complainers paints a less 
distorted picture nonetheless, compared to people one meets at 
conferences? And if, what makes you think so?
Nov 21 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 21 November 2021 at 16:24:58 UTC, Dukc wrote:

 Sure, forums don't filter out people who aren't already 
 committed like conferences tend to do. But also: sampling forum 
 complainers has its own biases, they tend to be those of the 
 inpatient and furious nature.


Absolutely. I agree. You cannot take their anger in itself as a 
need for changing the product. You can try to find out what the 
source of their anger is. It could for instance be a 
communication problem and not a product problem.

But if 30 people independently say that the Boehm-like GC is 
preventing them from becoming enthusiatic about the language, and 
that they therefore are limited to dabbling with it. Then you 
also should think that there is a rather large number of people 
that don't come to the forum and feel the same way. Does this 
mean not having a GC is the right resolution? Of course not. But 
it suggests that you might have greater enthusiasm in a greater 
proportion of your user base if you find a better solution for 
compiler backed memory management. And make that a priority.

People will not build a framework until they feel that the tool 
is solid (for their use case), until then they will dabble with a 
wait-and-see attitude.


 Conference people have usually had to consider the limits of 
 time/manpower/influence when pushing for changes. Forum 
 complainers often have not.


Maybe. You should of course not accept the solution the 
complainers present, since it might cause other problems. But if 
it is a repeating pattern, then you should make it a priority to 
find a solution that create enthusiasm. By collecting many 
solution proposal (not a random DIP from a random user) you can 
get an idea of what options exists and can try to find synergies 
in the design space.

In essence I don't think the users should design the language. I 
think the designers should design the language. I think the 
designers should collect ideas from outside, then design 
something that makes the language become something clean and 
beautiful as a whole (rather than a mix of 100 different 
aesthetics from 100 different users)


 Do you think listening to the forum complainers paints a less 
 distorted picture nonetheless, compared to people one meets at 
 conferences? And if, what makes you think so?


The most enthusiastic users may not be able to lift up those 
issues that make other users less enthusiastic. The most 
enthusiastic users are likely to grow the complexity of the 
language if you were to accept all individual features they 
present. Each feature might be great, but not fit well with 
everything else.

The users that are enthusiastic are already productive. Do you 
want to prioritize that one group more productive? Or do you want 
to increase the number of well supported use cases by covering 
the needs of the less enthusiastic users?

Do you want to evolve the design into a corner that the most 
enthusiastic crowd is in? Or do you want to find a wider sense of 
common ground?

For instance, we now have many non-system-level programmers. We 
need to preserve their use case, absolutely! So we have to look 
for common ground with hardcore system level programmers. That is 
a challenge, but possible (I think). But I don't think that 
resolution will come from any individual user who is scratching 
his own itch. It has to come from a designer (or a user that is 
empathic to many different uses cases) that look for common 
ground and synergies in the design space.

Are we on the same page?
Nov 21 2021
parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 21 November 2021 at 17:00:43 UTC, Ola Fosheim Grøstad 
wrote:

 Absolutely. I agree. You cannot take their anger in itself as a 
 need for changing the product. You can try to find out what the 
 source of their anger is. It could for instance be a 
 communication problem and not a product problem.

 [snip]

 Maybe. You should of course not accept the solution the 
 complainers present, since it might cause other problems. But 
 if it is a repeating pattern, then you should make it a 
 priority to find a solution that create enthusiasm. By 
 collecting many solution proposal (not a random DIP from a 
 random user) you can get an idea of what options exists and can 
 try to find synergies in the design space.

 [snip]

 Are we on the same page?


So you do agree that forum complaining often does not correlate 
with the problems. But still, you were accusing the regulars here 
of ivory tower attitude towards forum ranting.

In my experience, if you bother to write a concrete and accurate 
description of your problem here, it usually gets at least taken 
seriously, if not fixed. So unless you're suggesting we should be 
appeasing non-specific frustation venting, I don't see how we 
could do better in this regard. And the latter would definitely 
not be doable with our manpower.
Nov 24 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 24 November 2021 at 17:04:09 UTC, Dukc wrote:

 So you do agree that forum complaining often does not correlate 
 with the problems. But still, you were accusing the regulars 
 here of ivory tower attitude towards forum ranting.


You are assuming too much now. The complaining do correlate to D 
not fulfilling their use case needs, the solutions they request 
may or may not be a good solution.

Optimizing the design to the regulars do not broaden the appeal 
of the language. In order to broaden the appeal you have to look 
to those that are not yet enthusiastic.


 venting, I don't see how we could do better in this regard. And 
 the latter would definitely not be doable with our manpower.


It is quite possible that no individual person can do better. 
Cooperation around one vision / plan might be necessary. Like 
Robert pointed out.
Nov 24 2021
next sibling parent forkit <forkit gmail.com> writes:
On Wednesday, 24 November 2021 at 17:27:45 UTC, Ola Fosheim 
Grøstad wrote:

 ...
 It is quite possible that no individual person can do better. 
 Cooperation around one vision / plan might be necessary. Like 
 Robert pointed out.


Yes, precisely. This is how you put some controls on creativity. 
It's what architects and engineers in fact, must do.
Nov 24 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 24 November 2021 at 17:27:45 UTC, Ola Fosheim 
Grøstad wrote:

 You are assuming too much now. The complaining do correlate to 
 D not fulfilling their use case needs, the solutions they 
 request may or may not be a good solution.

 Optimizing the design to the regulars do not broaden the appeal 
 of the language. In order to broaden the appeal you have to 
 look to those that are not yet enthusiastic.


 venting, I don't see how we could do better in this regard. 
 And the latter would definitely not be doable with our 
 manpower.


 It is quite possible that no individual person can do better. 
 Cooperation around one vision / plan might be necessary. Like 
 Robert pointed out.


The assumption here appears to be that since the people we're 
trying to attract are not already using D, people already using D 
can't know what would buy them in, but a word from an outside 
complainer is more reliable. People know their own motivations 
best, right?

Sounds reasonable, but Walter has shared personal experiences 
that warn about that attitude. For example:

 Related to me by a friend: X told me that what he really wanted 
 in a C++ compiler was compile speed. It was the most important 
 feature. He went on and on about it. I laughed and said that 
 compile speed was at the bottom of his list. He looked 
 perplexed, and asked how could I say that? I told him that he 
 was using Cfront, a translator, with Microsoft C as the 
 backend, a combination that compiled 4 times slower than 
 Zortech C++, and didn't have critical (for DOS) features like 
 near/far pointers. What he really regarded as the most 
 important feature was being a name brand.


Given that, It does not sound a very good idea to design the 
language around what everyone is lobbying for on the forums. I'd 
much rather concentrate on specific bug reports, questions and 
improvement proposals. With them the designer can at least trust 
they show something that really matters, not just made-up excuses 
for some unacknowledged bias.
Nov 24 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 24 November 2021 at 21:37:58 UTC, Dukc wrote:

 The assumption here appears to be that since the people we're 
 trying to attract are not already using D, people already using 
 D can't know what would buy them in, but a word from an outside 
 complainer is more reliable. People know their own motivations 
 best, right?


I think this overstating the issue. 
Not-yet-enthusiatic-but-interested people may be using D, but not 
for anything that they will commit to long term.

You need more of those to be enthusiastic in order to get 
frameworks built. You cannot make them enthusiastic without 
addressing the issues they have.


 Given that, It does not sound a very good idea to design the 
 language around what everyone is lobbying for on the forums.


Early C++ compilers were buggy. Not a good example. Just a fun 
anecdote. (Even g++ was quite buggy for a very long time.)

As a designer you should ask yourself why N people independently 
point out weakness X, and then ask yourself what the total impact 
of X is.


 I'd much rather concentrate on specific bug reports, questions 
 and improvement proposals. With them the designer can at least 
 trust they show something that really matters, not just made-up 
 excuses for some unacknowledged bias.


You should of course polish your product!

However, it is generally negative to add a long series of 
"improvements" to scratch some enthusiastic individual's itch and 
become slightly better at something you already have covered. You 
gain more from extending into areas that you do not cover well.


were given the freedom to add new cool features? The languages 
would eventually fail to appeal to any other group than the most 
enthusiastic ones.
Nov 24 2021
parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 24 November 2021 at 21:59:59 UTC, Ola Fosheim 
Grøstad wrote:

 I think this overstating the issue. 
 Not-yet-enthusiatic-but-interested people may be using D, but 
 not for anything that they will commit to long term.

 You need more of those to be enthusiastic in order to get 
 frameworks built. You cannot make them enthusiastic without 
 addressing the issues they have.


And the issue is, how do we know what REALLY makes then 
enthusiastic. You have been saying we pay too little attention to 
not-that-specific complaining. And I strongly doubt that claim.


 Early C++ compilers were buggy. Not a good example. Just a fun 
 anecdote. (Even g++ was quite buggy for a very long time.)


That isn't his only anecdote on the subject. The post in full: 
https://forum.dlang.org/post/pmktna$1hgo$1 digitalmars.com . Also 
he is quoting Laeeth who is saying just the same.

Now, it's still anecdotal experience so perhaps you can show them 
both wrong, if you have something real credible to back that up. 
If.


 You should of course polish your product!

 However, it is generally negative to add a long series of 
 "improvements" to scratch some enthusiastic individual's itch 
 and become slightly better at something you already have 
 covered. You gain more from extending into areas that you do 
 not cover well.


 users were given the freedom to add new cool features? The 
 languages would eventually fail to appeal to any other group 
 than the most enthusiastic ones.


We're talking about attitude towards non-specific, unactionable 
or nearly unactionable forum ranting. It's not like only 
die-hards would be specific when they raise issues.
Nov 25 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 25 November 2021 at 08:41:55 UTC, Dukc wrote:

 Now, it's still anecdotal experience so perhaps you can show 
 them both wrong, if you have something real credible to back 
 that up. If.


They are both wrong. This is how big companies fold. IBM. SGI. 
SUN. Etc.


 We're talking about attitude towards non-specific, unactionable 
 or nearly unactionable forum ranting.


Huh? Most of the requests are very much "actionable".
Nov 25 2021
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 25 November 2021 at 08:50:19 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 25 November 2021 at 08:41:55 UTC, Dukc wrote:

 Now, it's still anecdotal experience so perhaps you can show 
 them both wrong, if you have something real credible to back 
 that up. If.


 They are both wrong. This is how big companies fold. IBM. SGI. 
 SUN. Etc.


The irony to see IBM on the list, given how much they move around 
the global computing economy, own one of the biggest Linux 
vendors and the second biggest JVM implementation.
Nov 25 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 25 November 2021 at 10:07:22 UTC, Paulo Pinto wrote:

 The irony to see IBM on the list, given how much they move 
 around the global computing economy, own one of the biggest 
 Linux vendors and the second biggest JVM implementation.


They were forced to change their business model, because they did 
not give enough priority to emerging markets. We could add Apple 
to the list too, which was saved by a thin margin. Not to mention 
Commodore, Atari, 3DO etc etc… We could also start to list 
languages, but most here would not know them, so no point really.
Nov 25 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 25 November 2021 at 10:21:52 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 25 November 2021 at 10:07:22 UTC, Paulo Pinto 
 wrote:

 The irony to see IBM on the list, given how much they move 
 around the global computing economy, own one of the biggest 
 Linux vendors and the second biggest JVM implementation.


 They were forced to change their business model, because they 
 did not give enough priority to emerging markets. We could add 
 Apple to the list too, which was saved by a thin margin. Not to 
 mention Commodore, Atari, 3DO etc etc… We could also start to 
 list languages, but most here would not know them, so no point 
 really.


Except Apple and IBM are around and quite relevant in this 
industry, including the backends that D depends on, GCC and LLVM.

While others on the list are long gone.

So you are mixing apples with oranges there.
Nov 25 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 25 November 2021 at 11:55:22 UTC, Paulo Pinto wrote:

 Except Apple and IBM are around and quite relevant in this 
 industry


They are around, but missed the mark for a long time because they 
saw no need to change when they had the opportunity. They had (or 
was given) stamina to survive, but that is another issue.
Nov 25 2021
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Thursday, 25 November 2021 at 08:50:19 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 25 November 2021 at 08:41:55 UTC, Dukc wrote:

 Now, it's still anecdotal experience so perhaps you can show 
 them both wrong, if you have something real credible to back 
 that up. If.


 They are both wrong. This is how big companies fold. IBM. SGI. 
 SUN. Etc.


I'm definitely far from convinced, but at least this explains why 
you're so often contrarian. Yeah, if I thought that Walter's and 
Laeeth's business experience has been misleading them and that 
for some reason I knew better, I'd question the direction of the 
language too.

You have a lot to do if you're going to convince the rest of us 
you know this stuff better than Walter and Laeeth do, though.
Nov 26 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 25 November 2021 at 08:50:19 UTC, Ola Fosheim 
Grøstad wrote:

 We're talking about attitude towards non-specific, 
 unactionable or nearly unactionable forum ranting.


 Huh? Most of the requests are very much "actionable".


Perhaps I used a bad word there. My point was that you're 
painting it as if only committed long-time users would give 
specific, helpful feedback and everyone else who bothers to give 
feedback would just be demanding changing everything at once. A 

better GC and D can't do that so D should drop GC".

No. Even occasional D users can and often do better than that. 
Even an inexperienced user ought to recognize that the language 
isn't written just for them and the language maintainers can't 
satisfy everyone, but they have better chances to satisfy small, 
realistic requests.
Nov 26 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 26 November 2021 at 10:54:46 UTC, Dukc wrote:

 Perhaps I used a bad word there. My point was that you're 
 painting it as if only committed long-time users would give 
 specific, helpful feedback and everyone else who bothers to 
 give feedback would just be demanding changing everything at 
 once.


Did I?



 has better GC and D can't do that so D should drop GC".


I think I've said that one should listen to what issues people 
have that make them reluctant to use D as a tool for their use 
case, but not necessarily adopt the solution they propose.

D's ecosystem is suffering because people are reluctant to go all 
in. They have fun with it for projects that are small in scope, 
but hesitate to do large things with it.

For instance, I started yesterday to fool around with Skia in 
order to make a simple application framework for my own use. I 
hold the option open for making it work with D, but it won't be a 
priority as long as there is no vision for D as a solution that 
is better than C++ across the board (for that use case).


 Even an inexperienced user ought to recognize that the language 
 isn't written just for them and the language maintainers can't 
 satisfy everyone, but they have better chances to satisfy 
 small, realistic requests.


It is possible for D to be an alternative for C++ for more users, 
but then adjustments have to be made on many issues. Not *big* 
changes, but adjustments to make it a clear improvement across 
the board over C++. Without that, D is perceived as somewhat 
different, and that is not enough.
Nov 26 2021
prev sibling next sibling parent Tejas <notrealemail gmail.com> writes:
On Friday, 19 November 2021 at 16:30:14 UTC, Guillaume Piolat 
wrote:

 Nim forums are moderated: https://forum.nim-lang.org/
 Rust forums are moderated: https://users.rust-lang.org/
 Go forums are moderated: https://forum.golangbridge.org/
 If you browse them, I doubt you will find the kind of 
 systematic negativity one can find here.

 If you enjoy reading HN and Reddit, it's also because they are 
 heavily moderated.

 This is just my opinion, but I think the moderation on the D 
 forums should be a bit more ban-happy.


That Nim moderation thread... That one guy is a little too 
insane, yikes   D:
Nov 19 2021
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 19 November 2021 at 16:30:14 UTC, Guillaume Piolat 
wrote:

 Nim forums are moderated: https://forum.nim-lang.org/
 Rust forums are moderated: https://users.rust-lang.org/
 Go forums are moderated: https://forum.golangbridge.org/
 If you browse them, I doubt you will find the kind of 
 systematic negativity one can find here.

 If you enjoy reading HN and Reddit, it's also because they are 
 heavily moderated.

 This is just my opinion, but I think the moderation on the D 
 forums should be a bit more ban-happy.


Hacker news reporting all of Rust's mods just resigned.

https://news.ycombinator.com/item?id=29306845
Nov 22 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 22 November 2021 at 15:28:20 UTC, jmh530 wrote:

 On Friday, 19 November 2021 at 16:30:14 UTC, Guillaume Piolat 
 wrote:

 Nim forums are moderated: https://forum.nim-lang.org/
 Rust forums are moderated: https://users.rust-lang.org/
 Go forums are moderated: https://forum.golangbridge.org/
 If you browse them, I doubt you will find the kind of 
 systematic negativity one can find here.

 If you enjoy reading HN and Reddit, it's also because they are 
 heavily moderated.

 This is just my opinion, but I think the moderation on the D 
 forums should be a bit more ban-happy.


 Hacker news reporting all of Rust's mods just resigned.

 https://news.ycombinator.com/item?id=29306845


Yeah just saw that drama. I wonder what that's all about

https://github.com/rust-lang/team/pull/671
Nov 22 2021
next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 22 November 2021 at 18:05:45 UTC, Imperatorn wrote:

 On Monday, 22 November 2021 at 15:28:20 UTC, jmh530 wrote:

 On Friday, 19 November 2021 at 16:30:14 UTC, Guillaume Piolat 
 wrote:

 Nim forums are moderated: https://forum.nim-lang.org/
 Rust forums are moderated: https://users.rust-lang.org/
 Go forums are moderated: https://forum.golangbridge.org/
 If you browse them, I doubt you will find the kind of 
 systematic negativity one can find here.

 If you enjoy reading HN and Reddit, it's also because they 
 are heavily moderated.

 This is just my opinion, but I think the moderation on the D 
 forums should be a bit more ban-happy.


 Hacker news reporting all of Rust's mods just resigned.

 https://news.ycombinator.com/item?id=29306845


 Yeah just saw that drama. I wonder what that's all about

 https://github.com/rust-lang/team/pull/671


Prediction: It's the same stuff all large projects and 
organizations encounter. Including this project.
Nov 22 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 22 November 2021 at 18:27:31 UTC, bachmeier wrote:

 On Monday, 22 November 2021 at 18:05:45 UTC, Imperatorn wrote:

 On Monday, 22 November 2021 at 15:28:20 UTC, jmh530 wrote:

 On Friday, 19 November 2021 at 16:30:14 UTC, Guillaume Piolat 
 wrote:

 [...]


 Hacker news reporting all of Rust's mods just resigned.

 https://news.ycombinator.com/item?id=29306845


 Yeah just saw that drama. I wonder what that's all about

 https://github.com/rust-lang/team/pull/671


 Prediction: It's the same stuff all large projects and 
 organizations encounter. Including this project.


What is it they encounter?
Nov 22 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 22 November 2021 at 20:56:21 UTC, Imperatorn wrote:

 What is it they encounter?


Disagreements about direction, and personal conflicts in the core 
team.
Nov 22 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 22 November 2021 at 21:02:51 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 22 November 2021 at 20:56:21 UTC, Imperatorn wrote:

 What is it they encounter?


 Disagreements about direction, and personal conflicts in the 
 core team.


I understand, I was more curious of what exactly

Anyone got inside info? 😎
Nov 22 2021
parent reply forkit <forkit gmail.com> writes:
On Monday, 22 November 2021 at 21:15:53 UTC, Imperatorn wrote:

 On Monday, 22 November 2021 at 21:02:51 UTC, Ola Fosheim 
 Grøstad wrote:

 On Monday, 22 November 2021 at 20:56:21 UTC, Imperatorn wrote:

 What is it they encounter?


 Disagreements about direction, and personal conflicts in the 
 core team.


 I understand, I was more curious of what exactly

 Anyone got inside info? 😎


No. But it's clearly related to 'the moderators' trying (and 
failing) to enforce a code of conduct upon the core team.

Their code of conduct is like a religion to them (to the 
moderators that is).

So really...nothing to see here... this kinda thing is inevitable.

btw. Who moderates the moderators?
Nov 22 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 22 November 2021 at 21:53:08 UTC, forkit wrote:

 btw. Who moderates the moderators?


They did. They fired themselves.
Nov 22 2021
prev sibling parent zjh <fqbqrr 163.com> writes:
On Monday, 22 November 2021 at 18:05:45 UTC, Imperatorn wrote:


 https://github.com/rust-lang/team/pull/671


Big news.Probably a dictatorship.
Nov 22 2021
prev sibling next sibling parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat 
wrote:

 On Thursday, 18 November 2021 at 18:05:38 UTC, Abdulhaq wrote:

 I just want to give a POV that I think can help lift the 
 number of users.


 _Doing things with D_ help lift the number of users.

 Constant, harsh, unsubstantiated criticism on the main 
 communication channel (these very forums) for D doesn't help 
 getting more users. No language has an anti-themselves campaign 
 going on for years on their main communication channels.

 Imagine you child is bullied at school. Would your idea of 
 helping him is to _make public criticism of the many ways he 
 would have to change in order to have friends_?
 No, this is just bullying, by people who enjoy doing just that.


Sorry but you've totally misunderstood me. I hate bullying and I 
certainly don't feel as if I'm bullying anyone. Who am I 
bullying? You can't bully a language so I guess you mean the 
community. From time to time I explain why I'm not using D 
myself, even though I'm attracted to it. I'm sorry if it hurts, 
if I was wrong would it hurt as much? If I'm right, is it better 
to carry on not knowing, so that you can feel good?

Say you have a store, way out of town. There is no parking there 
for cars, so the few customers there have come by bicycle. I live 
in town and know that thousands of people would like the store 
and use it, if it had parking. Is it wrong of me to drive out to 
the store, park up quickly on the road, pop in and say to the 
owners, hey, if you had more parking then I think you'd get many 
more customers? Is that bullying?

You're lumping me in with the drive-by attention seekers. I guess 
that's understandable that from your POV I fit the pattern. I get 
no pleasure from my comment but I do think it's a worthwhile 
observation to be aware of. The internet is a poor medium for 
seeing inside other people's heads, and you've definitely 
msisunderstood what's in mine. At one time, years ago, I put 
months of my spare time into writing a D wrapper for Qt, you can 
search my comment history and check on GitHub.

Anyway I don't take it personally, sorry if I hurt you somehow. 
You shouldn't take it personally either.
Nov 19 2021
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 19 November 2021 at 11:52:04 UTC, Abdulhaq wrote:

 On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat 
 wrote:

 [...]


 Sorry but you've totally misunderstood me. I hate bullying and 
 I certainly don't feel as if I'm bullying anyone. Who am I 
 bullying? You can't bully a language so I guess you mean the 
 community. From time to time I explain why I'm not using D 
 myself, even though I'm attracted to it. I'm sorry if it hurts, 
 if I was wrong would it hurt as much? If I'm right, is it 
 better to carry on not knowing, so that you can feel good?

 [...]


It's not about you, but the pattern.

It gets tiresome in the long run.
Nov 19 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 19 November 2021 at 12:11:48 UTC, Imperatorn wrote:

 It's not about you, but the pattern.


The pattern is the result of not having a software development 
process at the core of the project, not a result of users having 
expectations.

You raise those expectations in the users by how you present 
yourself.

Users are the environment.

You have to adapt and change your own behaviour if you are a 
developer, service provider, foundation.

You cannot change the users. Only changes to the product, the 
process, the communication can change the pattern.
Nov 19 2021
prev sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Friday, 19 November 2021 at 12:11:48 UTC, Imperatorn wrote:

 On Friday, 19 November 2021 at 11:52:04 UTC, Abdulhaq wrote:

 On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat 
 wrote:

 [...]


 Sorry but you've totally misunderstood me. I hate bullying and 
 I certainly don't feel as if I'm bullying anyone. Who am I 
 bullying? You can't bully a language so I guess you mean the 
 community. From time to time I explain why I'm not using D 
 myself, even though I'm attracted to it. I'm sorry if it 
 hurts, if I was wrong would it hurt as much? If I'm right, is 
 it better to carry on not knowing, so that you can feel good?

 [...]


 It's not about you, but the pattern.

 It gets tiresome in the long run.


Yes I understand.
Nov 19 2021
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 19 November 2021 at 11:52:04 UTC, Abdulhaq wrote:

 Anyway I don't take it personally, sorry if I hurt you somehow. 
 You shouldn't take it personally either.


I'm not specifically talking about you, or your posts, or this 
thread, more as an overview of the similar threads going on.
Nov 19 2021
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat 
wrote:

 On Thursday, 18 November 2021 at 18:05:38 UTC, Abdulhaq wrote:

 I just want to give a POV that I think can help lift the 
 number of users.


 _Doing things with D_ help lift the number of users.

 Constant, harsh, unsubstantiated criticism on the main 
 communication channel (these very forums) for D doesn't help 
 getting more users. No language has an anti-themselves campaign 
 going on for years on their main communication channels.

 Imagine you child is bullied at school. Would your idea of 
 helping him is to _make public criticism of the many ways he 
 would have to change in order to have friends_?
 No, this is just bullying, by people who enjoy doing just that.


+1
Nov 19 2021
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat 
wrote:

 On Thursday, 18 November 2021 at 18:05:38 UTC, Abdulhaq wrote:

 I just want to give a POV that I think can help lift the 
 number of users.


 _Doing things with D_ help lift the number of users.

 Constant, harsh, unsubstantiated criticism on the main 
 communication channel (these very forums) for D doesn't help 
 getting more users. No language has an anti-themselves campaign 
 going on for years on their main communication channels.

 Imagine you child is bullied at school. Would your idea of 
 helping him is to _make public criticism of the many ways he 
 would have to change in order to have friends_?
 No, this is just bullying, by people who enjoy doing just that.


Amen. This is exactly what happens here.
Nov 19 2021
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 19 November 2021 at 14:37:51 UTC, Patrick Schluter 
wrote:

 On Friday, 19 November 2021 at 11:24:15 UTC, Guillaume Piolat 
 wrote:

 On Thursday, 18 November 2021 at 18:05:38 UTC, Abdulhaq wrote:

 [...]


 _Doing things with D_ help lift the number of users.

 Constant, harsh, unsubstantiated criticism on the main 
 communication channel (these very forums) for D doesn't help 
 getting more users. No language has an anti-themselves 
 campaign going on for years on their main communication 
 channels.

 Imagine you child is bullied at school. Would your idea of 
 helping him is to _make public criticism of the many ways he 
 would have to change in order to have friends_?
 No, this is just bullying, by people who enjoy doing just that.


 Amen. This is exactly what happens here.


You are really sure about that?

https://philosophy.lander.edu/oriental/charity.html
Nov 19 2021
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/16/2021 12:55 AM, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean that D2 is now 
 finished? Or will it forever be in a state of ongoing feature development?
 
 We all know that properly finishing and polishing the last 10% of a software 
 project takes 90% of the time. Is there a timescale for that? What platforms 
 will it support?


No software development is ever done as long as people are still using it.
Nov 18 2021
parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Friday, 19 November 2021 at 01:14:47 UTC, Walter Bright wrote:

 On 11/16/2021 12:55 AM, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean 
 that D2 is now finished? Or will it forever be in a state of 
 ongoing feature development?
 
 We all know that properly finishing and polishing the last 10% 
 of a software project takes 90% of the time. Is there a 
 timescale for that? What platforms will it support?


 No software development is ever done as long as people are 
 still using it.


That's true, of course. What I mean is, nail all those boring 
I-know-I-should-fix-those-small-to-medium-size-problems-but-I'm-not-sure-how
and park, for now, the interesting DIPs etc. Finalise the feature set for an
LTS version and really polish it to make it the best experience it can be for a
developer, within the bounds of what is actually possible of course. Make it
the focus of the community. Commit to supporting that release for bugs and
security issues, on a nominated set of platforms, for a nominated period of
time.

This is my proposal if you want to grow the number of corporate 
developers using D. Maybe you don't, that's your call obviously.

If I'm barking up the wrong tree then set me straight and make it 
clear what the vision actually is. Personally I'm also curious, 
do you have a particular set of developers in mind as users, or 
are you just scratching your own itch and hoping that it will 
also be good for others? Both answers are perfectly reasonable, 
but it would be nice to know the answer.
Nov 19 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 19 November 2021 at 08:41:05 UTC, Abdulhaq wrote:


 That's true, of course. What I mean is, nail all those boring 
 I-know-I-should-fix-those-small-to-medium-size-problems-but-I'm-not-sure-how
and park, for now, the interesting DIPs etc. Finalise the feature set for an
LTS version and really polish it to make it the best experience it can be for a
developer, within the bounds of what is actually possible of course. Make it
the focus of the community. Commit to supporting that release for bugs and
security issues, on a nominated set of platforms, for a nominated period of
time.


I recommend you watch Atila's upcoming DConf Online talk:

https://youtu.be/UqW42_8kn0s

That will cover part of what you're asking about. And I expect 
that the revised governance proposal Mathias Lang is preparing to 
put forward in the coming weeks will create the framework where 
we'll be able to marshal and direct community resources 
(volunteered and paid) toward specific tasks to enhance the 
ecosystem. That includes the finalization/polishing of troubled 
language features and any potential changes to the release 
process.

See the following meeting summary for background:

https://forum.dlang.org/thread/fnzuguuewsvzswpwiwar forum.dlang.org
Nov 19 2021
parent Abdulhaq <alynch4047 gmail.com> writes:
On Friday, 19 November 2021 at 09:15:21 UTC, Mike Parker wrote:


 I recommend you watch Atila's upcoming DConf Online talk:

 https://youtu.be/UqW42_8kn0s



 See the following meeting summary for background:

 https://forum.dlang.org/thread/fnzuguuewsvzswpwiwar forum.dlang.org


Thanks Mike, I will certainly do that. I do enjoy the DConf 
videos and and I follow the DLF meetings.
Nov 19 2021
prev sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

 Is there a set of features that, when fully working, will mean 
 that D2 is now finished? Or will it forever be in a state of 
 ongoing feature development?

 We all know that properly finishing and polishing the last 10% 
 of a software project takes 90% of the time. Is there a 
 timescale for that? What platforms will it support?


I'd say lets not finish it and start on D3 instead.
Nov 24 2021
parent reply forkit <forkit gmail.com> writes:
On Wednesday, 24 November 2021 at 17:14:56 UTC, IGotD- wrote:

 ..
 I'd say lets not finish it and start on D3 instead.


No. D2 needs to first come to a design halt. It seems far from 
that at the moment.

D3 is inevitable, of course. The only question is what design 
decisions will 'force' that move to the next version of D?

I'd be more interested to hear in detail, about that aspect of 
moving D forward, rather just the call to dump D2 and create a D3.

No fluffy 'vision'.. I wanna see the details.
Nov 24 2021
parent reply Greg Strong <mageofmaple protonmail.com> writes:
On Wednesday, 24 November 2021 at 21:41:10 UTC, forkit wrote:

 On Wednesday, 24 November 2021 at 17:14:56 UTC, IGotD- wrote:

 ..
 I'd say lets not finish it and start on D3 instead.


 No. D2 needs to first come to a design halt. It seems far from 
 that at the moment.


Agreed.  I think we *need* a stable D2 before we can hope for 
widespread adoption.  This could mean either finishing the 
incomplete things or backing them out, but it's got to go one way 
or the other on all significant outstanding things.  Making a 
list of these things and deciding if they are "in" or "out" of 

clear that there will, indeed, be an LTS release upcoming.  
Without that clearly stated no one should use D for anything 
other than hobby programming.  To do so would be irresponsible.


 D3 is inevitable, of course. The only question is what design 
 decisions will 'force' that move to the next version of D?

 I'd be more interested to hear in detail, about that aspect of 
 moving D forward, rather just the call to dump D2 and create a 
 D3.

 No fluffy 'vision'.. I wanna see the details.


Well, I think first having a general vision is a prerequisite 
before details can be worked out...  No one person can work out 
all the details, and multiple people need to adopt some shared 
vision in order to move things forward.  Lack of shared vision is 
one of our biggest problems.
Nov 24 2021
parent reply zjh <fqbqrr 163.com> writes:
On Wednesday, 24 November 2021 at 21:55:46 UTC, Greg Strong wrote:

 Lack of shared vision is one of our biggest problems.


D's vision can be summed up as `better, faster, safer and more 
elegant`.
As long as we stick to that goal, you can attract your `target 
user`.
Nov 24 2021
next sibling parent reply forkit <forkit gmail.com> writes:
On Thursday, 25 November 2021 at 00:56:07 UTC, zjh wrote:

 On Wednesday, 24 November 2021 at 21:55:46 UTC, Greg Strong 
 wrote:

 Lack of shared vision is one of our biggest problems.


 D's vision can be summed up as `better, faster, safer and more 
 elegant`.
 As long as we stick to that goal, you can attract your `target 
 user`.


better than what? (than shooting yourself in the foot?)
faster than what? (a speeding train?)
safer than what? (no safety?)
more elegant than what? (the inelegance of C and C++?)

They just fluffy adjectives with no real meaning.
Nov 24 2021
parent zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 01:07:20 UTC, forkit wrote:


 better than what? (than shooting yourself in the foot?)


D just needs to be `faster, safer, more elegant, better` than `D` 
its self.
Nov 24 2021
prev sibling parent reply forkit <forkit gmail.com> writes:
On Thursday, 25 November 2021 at 00:56:07 UTC, zjh wrote:

 On Wednesday, 24 November 2021 at 21:55:46 UTC, Greg Strong 
 wrote:

 Lack of shared vision is one of our biggest problems.


 D's vision can be summed up as `better, faster, safer and more 
 elegant`.
 As long as we stick to that goal, you can attract your `target 
 user`.


The vision, as I see it (at the moment), can be summed up like 
this:

D++

:-(
Nov 24 2021
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 01:19:50 UTC, forkit wrote:


 The vision, as I see it (at the moment), can be summed up like 
 this:
 D++
 :-(


How is `D++` bad?
I like `C++`. It's easy to use.
It would be nice if we had `D++`.
Nov 24 2021
parent reply forkit <forkit gmail.com> writes:
On Thursday, 25 November 2021 at 01:49:37 UTC, zjh wrote:

 On Thursday, 25 November 2021 at 01:19:50 UTC, forkit wrote:


 The vision, as I see it (at the moment), can be summed up like 
 this:
 D++
 :-(


 How is `D++` bad?
 I like `C++`. It's easy to use.
 It would be nice if we had `D++`.


My concern is that a D++ will for 'compatability reasons' bring  
with it, many of the flaws in C++ - just as C++ bought with it 
many of the flaws in C.

This is where I think, Go got it right (although they made some 
design decisions that I simply refuse to accept).

What we really need is a simpler compiler that we can trust 
(through formal verfication and  proofs). That is how one 
implements  safe and  trusted ;-)

D is already a complex beast (just to learn - nevermind 
implementing a compiler for it)!

And D++...well... whoohoo....hold on tight!
Nov 24 2021
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 02:14:34 UTC, forkit wrote:


 And D++...well... whoohoo....hold on tight!


`C++`, so complicated, but so what? Complexity is left to the 
compiler.
As a user, I enjoy it. That's right. Therefore,C++ has a large 
number of users.
`D++` can also be used in this way, things are complicated, you 
have to provide more things. `complexity` is one of the essence 
of language. And `go` now also in the `complex` road, there is no 
basic `template`, which can abstract well, `go` now, has betrayed 
his `simple` concept. It feels like cheating.
Nov 24 2021
parent reply forkit <forkit gmail.com> writes:
On Thursday, 25 November 2021 at 02:31:56 UTC, zjh wrote:

 On Thursday, 25 November 2021 at 02:14:34 UTC, forkit wrote:


 And D++...well... whoohoo....hold on tight!


 `C++`, so complicated, but so what? Complexity is left to the 
 compiler.
 As a user, I enjoy it. That's right. Therefore,C++ has a large 
 number of users.
 `D++` can also be used in this way, things are complicated, you 
 have to provide more things. `complexity` is one of the essence 
 of language. And `go` now also in the `complex` road, there is 
 no basic `template`, which can abstract well, `go` now, has 
 betrayed his `simple` concept. It feels like cheating.


Yes, I agree. Complexity is not inherently bad.

However, to paraphrase a statement from ziglang website...

You do not want to get to the point, where you find yourself 
debugging one's knowledge of the programming language instead of 
debugging the application itself.
Nov 24 2021
parent zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 03:04:47 UTC, forkit wrote:


 debugging one's knowledge of the programming language instead 
 of debugging the application itself.


You're right. I also hope D can `reasonably arrange and organize` 
time, list the problems to be solved according to the importance, 
and solve them one by one.
Appropriate damage, I think, is tolerable.
Freeze `D2` and working on `D3`,It's also Ok.
The key is to organize `time and manpower` reasonably.
I also believe in the ability of `machine verification`.
Don't be afraid of change, what you are afraid of is not change.
Nov 24 2021
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 25 November 2021 at 02:14:34 UTC, forkit wrote:


 What we really need is a simpler compiler that we can trust 
 (through formal verfication and  proofs). That is how one 
 implements  safe and  trusted ;-)



That is an ideal, not a reality.
Nov 24 2021
parent forkit <forkit gmail.com> writes:
On Thursday, 25 November 2021 at 02:39:17 UTC, zjh wrote:

 On Thursday, 25 November 2021 at 02:14:34 UTC, forkit wrote:


 What we really need is a simpler compiler that we can trust 
 (through formal verfication and  proofs). That is how one 
 implements  safe and  trusted ;-)



 That is an ideal, not a reality.


no. it's a reality.

https://compcert.org/compcert-C.html
Nov 24 2021