On 11/16/2018 12:00 PM, Aurélien Plazzotta wrote:

> But my point is, I'm persuaded they believe much more in C++ than they
> believe in a future for D; the latter being rather a technological demo
> for something they would have hope at the beginning of their career.

I don't know any person in the D community that fits that description.

To respond to an earlier comment of yours, I don't know any D person who is a member of the C++ standardization committee either.

Ali

On Fri, Nov 16, 2018 at 08:00:30PM +0000, Aurélien Plazzotta via Digitalmars-d wrote:
> On Friday, 16 November 2018 at 07:20:25 UTC, Laeeth Isharc wrote:
[...]
> > > The creators and the main contributors of D are all C++ full-time developers some of them even members of C++ commities.
> > 
> > Traitors!  We must hunt them down and expel them!  Seriously,how can this be a bad thing?  Some people are even members of non-native code communities also!  Why wouldn't we want to have the benefit of the idea interchange that results ?
> 
> Please, don't turn me into a parody :/ I don't see them as traitors of course, I know they put a lot of effort into the D language and it's a wonderful thing for our community to have several semi-gods among us. But my point is, I'm persuaded they believe much more in C++ than they believe in a future for D; the latter being rather a technological demo for something they would have hope at the beginning of their career.
[...]

You have been grossly misinformed.  Walter works full-time on D, and Andrei *quit* his career at Facebook in order to work full-time on D. What else do you expect them to do to prove their commitment to D??


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson

On Thu, Nov 15, 2018 at 07:49:32PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...]
> Honestly, over time, I've become increasingly convinced that the more radical ideas would be incredibly undesirable (e.g. making const or immutable the default).

Actually, immutable by default would encourage better coding style, as well as potentially provide a small performance benefit by allowing the optimizer to take advantage of more things that don't need to be mutable (can elide certain loads even in the face of aliasing, can infer more loop invariants, etc.).


> shared has some rough edges that need to be sorted out, but I don't think that it's fundamentally broken as things stand. I think that the issue is more that it's misunderstood, and its proper use has not really been messaged well - with the related problem being that the core synchronization components in druntime have not been entirely properly updated to take shared into account like they should have been, mostly because no one wanted to mess with them, because they had the idea that shared was largely unfinished and might change drastically later. So, while shared's implementation needs some tweaks to be sure, I'm not the least bit convinced that it needs a serious overhaul on the language front so much as some work on the library front and an overhaul on the PR front.

Whether or not shared is fundamentally broken or (mostly) working as designed, I can't say, but the documentation problem is very real, because what little of it I have read has scared me off from touching shared with a 10-foot pole thus far.  The fact that you have to cast may have been by design, but it's a scary thing to the under-informed.


> In any case, I think that _most_ of the things that should go in something like D3 can be done in D2 so long as Walter and Andrei can be convinced. For instance, we totally _could_ fix the nonsense about treating bool as an integer type in D2. There's nothing about that that requires D3.

Yes, but cutting the legacy tie with C integer promotion rules would require D3.


> Unfortunately, of course, Walter and Andrei weren't convinced by the DIP that would effectively have fixed that by removing the implicit conversions from integer literals to bool, so that's not happening in D2 unless something drastic changes, and as such, I see no reason to expect that it would happen in D3.

I was very disappointed at the rejection, in fact.  I suppose you have a point that if we were to start over from a blank slate like D3, it will probably still stay that way.  But if I had any say in how D3 would be done, I would definitely say treat bool as a non-numerical type, and require a cast if for whatever reason you decide to treat it as such. It makes intent so much clearer, and IMO leads to better code (just like when pointers stop implicitly converting to bool -- I was initially annoyed, but in retrospect appreciated the much improved readability of:

	if ((p = func()) !is null) ...

over the terse but cryptic:

	if ((p = func())) ...


[...]
> In a large program, it can very much be worth going to the extra effort of making your program work with a lot of extra attributes, but they often just get in the way, and forcing them on all programs by default would easily risk making D miserable to work in by default.

Attribute inference is the way to go.  *Nobody* wants to waste time manually annotating everything.  Boilerplate is evil.  In D2 Walter couldn't pull off across-the-board attribute inference, mainly because of backward compatibility, among other issues.  In D3 we could potentially build this in by default from the beginning, and it would save so many headaches.


> LOL. Walter's comment at dconf this year that he wished D had const as the default definitely makes me that much more leery of D3 ever arriving, since I increasingly avoid const in D.

So you're essentially going back to D1? ;-)


> Honestly, the only thing I can think of where I'd love the opportunity to be able to sit down and start from scratch would be ranges - and not just for auto-decoding. I'd want to rework them so that save wasn't a thing, and I'd want to figure out how to rework them so that the reference and value semantics were cleaner.

Yeah, I think Andrei himself also expressed the wish that ranges could be defined such that input ranges by definition have by-reference semantics, whereas forward ranges have by-value semantics, and would save their current position just by being copied into another variable. IIRC, the reason .save was introduced in the first place was because at the time, the language was still lacking some features that made it easy to determine whether something had by-value or by-reference semantics.


[...]
> In general, the kind of changes that I can think of that I'd like to see are things that can definitely be done in D2 - assuming that Walter and Andrei can be convinced, which is rarely easy, and the question of D2 vs D3 probably wouldn't change that much (some, since backwards compatibility would be less of an issue, but that doesn't mean that they'd then be easy to convince of major changes in general).
[...]

Seeing as the default answer to large-scale language changes these days seem to be "no, because it would break too much code", I think D3 would allow an opportunity to make large-scale changes that we otherwise wouldn't dare to in D2.

One of the warts I'd like to see go the way of the dodo is the whole fiasco with Object.toString, Object.opEquals, etc., specifically how they interact with attributes in class methods.  And also the implicit Monitor object (when it's not needed).  Andrei had proposed ProtoObject as a D2 solution to this impasse, but I've yet to see any further progress since the initial discussion.


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce

On Friday, 16 November 2018 at 20:00:30 UTC, Aurélien Plazzotta wrote:
>>> There are no jobs in D :)
>>
>> I'm pretty sure you are mistaken both on the supply and demand side.
>
> I don't understand, what do you imply?
>
>> And we are still hiring.
>
> Nice but for which tech?

https://forum.dlang.org/post/dseedvywcitpzysxysme@forum.dlang.org

On Friday, 16 November 2018 at 21:40:06 UTC, H. S. Teoh wrote:
>
> You have been grossly misinformed.  Walter works full-time on D, and Andrei *quit* his career at Facebook in order to work full-time on D. What else do you expect them to do to prove their commitment to D??
>
>

It's hard to be critical of Walter and Andrei, it really is... but....

I would suggest, being more open to change, perhaps.

My impression of D at the moment, is that it just wants to remain stable, and that it has become too difficult to get change through the two gatekeepers (Walter and Andrei), and so people are not even bothering to try anymore.

Of course my impression could be wrong, but it is what it is.

But being stable in an environment where change is now 'the norm' for programming languages, could be the death nail for D.

Every other language is on the move...and it looks like it will stay that way for the foreseeable future.

C#/dotnet is (finally) poised to take over the world. Still a little way to go ;-)

The future of programming languages is about safer, more correct code, where the programmer can clearly show their intent - and all by default. You'll have to make the effort to write less safe, more obtuse code - whereas these days, you have to make the effort to create safe, correct code!

(e.g. private state within a module - nope. you have to re-architect just to get private state)

Anyway, as a developer (of anything), no.1 rule is: If you don't listen to your users, then you won't have any users soon enough.

I would like to quote Stroustrup (where he is speaking about the language he initially designed):

"We have two ways of going forward..one is to find a better alternative..and two..is to transform the old crud into the new stuff.. that's where the future is."

D has lots of 'crud' too. It needs transformation (one way or another).

Most importantly, is to remind Walter and Andrei, that D needs to serve it's users (not the other way around). Because there are alternatives to D.

On Friday, November 16, 2018 3:41:10 PM MST H. S. Teoh via Digitalmars-d wrote:
> On Thu, Nov 15, 2018 at 07:49:32PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...]
>
> > Honestly, over time, I've become increasingly convinced that the more radical ideas would be incredibly undesirable (e.g. making const or immutable the default).
>
> Actually, immutable by default would encourage better coding style, as well as potentially provide a small performance benefit by allowing the optimizer to take advantage of more things that don't need to be mutable (can elide certain loads even in the face of aliasing, can infer more loop invariants, etc.).

immutable by default would encourage a functional programming style everywhere. I dispute that that's necessarily better. There are certainly times that that's better, but it's often hell. What we have now allows us to program functionally when we want to without forcing it, whereas having immutable by default would lean heavily towards forcing it. It also would not play well with D being a systems language or with D interacting with C or C++. Honestly, having D3 be const or immutable by default is the sort of choice that would make me seriously consider quitting D.

> > In any case, I think that _most_ of the things that should go in something like D3 can be done in D2 so long as Walter and Andrei can be convinced. For instance, we totally _could_ fix the nonsense about treating bool as an integer type in D2. There's nothing about that that requires D3.
>
> Yes, but cutting the legacy tie with C integer promotion rules would require D3.

It would, but given the insistence on C code being valid D code with the same semantics or not being valid D code, I don't see that ever changing, and that basic rule is critical for being able to easily port C code to D without subtle bugs. So, while we can make some tweaks to the promotion rules, I very much doubt that any version of D will ever be fully divorced from C in that regard.

> > Unfortunately, of course, Walter and Andrei weren't convinced by the DIP that would effectively have fixed that by removing the implicit conversions from integer literals to bool, so that's not happening in D2 unless something drastic changes, and as such, I see no reason to expect that it would happen in D3.
>
> I was very disappointed at the rejection, in fact.  I suppose you have a point that if we were to start over from a blank slate like D3, it will probably still stay that way.  But if I had any say in how D3 would be done, I would definitely say treat bool as a non-numerical type, and require a cast if for whatever reason you decide to treat it as such. It makes intent so much clearer, and IMO leads to better code (just like when pointers stop implicitly converting to bool -- I was initially annoyed, but in retrospect appreciated the much improved readability of:
>
>   if ((p = func()) !is null) ...
>
> over the terse but cryptic:
>
>   if ((p = func())) ...
>
>
> [...]
>

Technically, implicit conversions have nothing to do with if statements anyway. Weird as that may be, that's an implicit, explicit conversion in that the compiler implicitly inserts a cast. So, even types which don't have implicit conversion still work with if statements as long as they have an explicit conversion to bool. In general though, I do agree that being more explicit with conditionals is better.

In any case, the point I was trying to make was that if Walter and Andrei can't be convinced of something like removing the implicit conversion of integer literals to bool for D2, I find it highly unlikely that they'll be convinced of it for D3. It might be that they'll be more open to a change for D3 if the reason that they don't want to make the change in D2 is a concern about code breakage, but aside from that, convincing them to change something for D2 and D3 is probably going to be pretty much the same. In plenty of cases, concerns about code breakage have nothing to do with it.

In general, it's just plain hard to convince Walter and Andrei that a particular feature or language change is a good idea. Whether you're talking about D2 or D3 doesn't really change that. D3 just removes many of the code breakage concerns from the equation. Either way, any DIP is has an uphill battle, and I think that most DIPs that provide real value could make it into D2 and don't require D3. The trick - as always - is convincing Walter and Andrei. So, I don't see how talk of D3 fixes anything really. The kind of stuff that you're unhappy about seems to mostly be stuff that Walter doesn't agree with anyway, so it's not stuff that he'd fix in D3, and a lot of it, he could fix in D2. Ultimately, it comes down to convincing Walter and Andrei. It may eventually come to creating a D3 and fixing some issues that we couldn't fix in D2, but without first convincing Walter and Andrei of various issues, such a version bump would be pointless, and if we convince them first, most of the issues can be resolved even without such a version bump.

> > In a large program, it can very much be worth going to the extra effort of making your program work with a lot of extra attributes, but they often just get in the way, and forcing them on all programs by default would easily risk making D miserable to work in by default.
>
> Attribute inference is the way to go.  *Nobody* wants to waste time manually annotating everything.  Boilerplate is evil.  In D2 Walter couldn't pull off across-the-board attribute inference, mainly because of backward compatibility, among other issues.  In D3 we could potentially build this in by default from the beginning, and it would save so many headaches.
>
> > LOL. Walter's comment at dconf this year that he wished D had const as the default definitely makes me that much more leery of D3 ever arriving, since I increasingly avoid const in D.
>
> So you're essentially going back to D1? ;-)

In terms of const? You read my article on it, so you should know where I stand on it. I don't think that either C++ or D got it right, but I also don't know what const would look like if it were done right. Either way, I sure don't want it to be the default. It's way to restrictive. If it were the default, I'd be forced to mark code with mutable (or whatever the keyword would be) everywhere. The same if immutable were the default. It would not be fun.

> Seeing as the default answer to large-scale language changes these days seem to be "no, because it would break too much code", I think D3 would allow an opportunity to make large-scale changes that we otherwise wouldn't dare to in D2.

It would, but at the same time, we also have to be able to have a language that we can be using in production and continue to use in production. Having it change slowly over time is one thing. Having it change drastically like that is something else entirely. At some point, it may make sense to create a D3, but I think that we should have a much better idea of what we want to change that we can't change now when we get to that point. We really don't have that right now. At most, it seems like D3 is the sort of thing that gets brought up when someone has an individual change that they want that gets shot down. As far as I can tell, there isn't even vaguely a cohesive group of changes that the main group of contributors agree on that they'd like to see happen that can't happen at this point, let alone the community at large. AFAIK, Walter and Andrei don't have a laundry list of things that they'd like to do but can't, because it would break backwards compatibility.

If Walter and Andrei were to say tomorrow that they wanted to create D3, they'd get bombarded with all kinds of stray ideas about how the language should be changed. There wouldn't be anything approaching any kind of agreement on what it should look like. Honestly, we have enough trouble agreeing on what changes should be made to the language when we're restricting ourselves to stuff that can be done transitionally within D2.

And honestly, when you consider that we can't even sort out stuff like treating bool as an integer type, it just seems crazy to talk about jumping off the deep end into D3, much as it would be nice to be able to make some larger tweaks in some cases. I think that we that we first need to figure out how to better fix D2 before we consider anything with D3 - and that's without even considering any of the potential issues of forking the language and community that comes with creating a new language version.

> One of the warts I'd like to see go the way of the dodo is the whole fiasco with Object.toString, Object.opEquals, etc., specifically how they interact with attributes in class methods.  And also the implicit Monitor object (when it's not needed).  Andrei had proposed ProtoObject as a D2 solution to this impasse, but I've yet to see any further progress since the initial discussion.

Yeah, but all of that stuff moves slowly, and technically, it does have to go through the DIP process. It's a DIP that has yet to be approved, even if it's probably a shoe-in. Also, it's at least sort of related to the copy constructor DIP, and at least that is moving along, albeit slowly. If I understand correctly, it's about to move into the next stage.

I think that the biggest question is really who's going to implement the ProtoObject stuff, since Andrei isn't a compiler dev. That's the weakest link in any case like this. Whenever someone comes up with an idea, and they're not set up to be the one to implement it, there's always a risk of it sitting in limbo for a while. But my guess is that at some point, Andrei will stick one of his students on it.

The bigger concern I see is what's been the related hold-up with removing all of that muck from Object for years and that's the AA implementation. I know that Martin did a bunch of work on it, but I don't where any of that stands. However, without it being replaced, there will likely be serious issues when ProtoObject comes into the picture.

- Jonathan M Davis

On Saturday, 17 November 2018 at 00:19:34 UTC, NoMoreBugs wrote:
> On Friday, 16 November 2018 at 21:40:06 UTC, H. S. Teoh wrote:
>>
>> You have been grossly misinformed.  Walter works full-time on D, and Andrei *quit* his career at Facebook in order to work full-time on D. What else do you expect them to do to prove their commitment to D??
>>
>>
>
> It's hard to be critical of Walter and Andrei, it really is... but....
>
> I would suggest, being more open to change, perhaps.
>
> My impression of D at the moment, is that it just wants to remain stable, and that it has become too difficult to get change through the two gatekeepers (Walter and Andrei), and so people are not even bothering to try anymore.
>
> Of course my impression could be wrong, but it is what it is.
>
> But being stable in an environment where change is now 'the norm' for programming languages, could be the death nail for D.
>
> Every other language is on the move...and it looks like it will stay that way for the foreseeable future.
>
> C#/dotnet is (finally) poised to take over the world. Still a little way to go ;-)
>
> The future of programming languages is about safer, more correct code, where the programmer can clearly show their intent - and all by default. You'll have to make the effort to write less safe, more obtuse code - whereas these days, you have to make the effort to create safe, correct code!
>
> (e.g. private state within a module - nope. you have to re-architect just to get private state)
>
> Anyway, as a developer (of anything), no.1 rule is: If you don't listen to your users, then you won't have any users soon enough.
>
> I would like to quote Stroustrup (where he is speaking about the language he initially designed):
>
> "We have two ways of going forward..one is to find a better alternative..and two..is to transform the old crud into the new stuff.. that's where the future is."
>
> D has lots of 'crud' too. It needs transformation (one way or another).
>
> Most importantly, is to remind Walter and Andrei, that D needs to serve it's users (not the other way around). Because there are alternatives to D.

Listening to users may often be a good idea.  Politely doing what you believe to be best whatever users may think may well on occasion be an even better idea.  Not that I see any hint that's how the language leadership think - that's just my personal opinion about the limitations of democracy in a popular sense and the role of leadership in creative endeavours.  It's quite often the case that users don't know what they will want.  Was the introduction of attributes universally welcomed?

More importantly than that I think there's an implicit unexamined assumption in what you wrote that what people on the forum write (it's fascinating on these kinds of threads the number of accounts that pop up who I never recall having posted before, whatever that may mean) is in any way generally representative of committed users of D.

Its a particular subset that post on the forums at all, and plenty of people active on the forums don't express themselves on these kinds of threads.  A subset of a subset.

I know a few people active in the development of the language and library that don't say much on the forums because they feel making pull requests are more productive.

The larger commercial users of D that I have met personally (I am a commercial user myself) barely post at all because they have work to do.

And to return to an old point.  It's much better to focus on people that like what you are doing and already using your product than those who say "if only you would do X, D would be huge".  That's the nature of the innovator's dilemma and also if one is to be persuasive then it's helpful to remember that talk is cheap, whereas making a closely reasoned argument accompanied by skin in the game - now that is much more persuasive.

On Saturday, 17 November 2018 at 02:07:45 UTC, Laeeth Isharc wrote:
>
> And to return to an old point.  It's much better to focus on people that like what you are doing and already using your product than those who say "if only you would do X, D would be huge".

Given D's very small user base, that's probably not the mindset you want the foundation to be in ;-)

That mindset, will ensure your small user base never grows, and will likely get smaller and smaller.

Even the C++ Committee cannot risk being in that mindset - not anymore anyway.

Same is true for the C# and Java gatekeepers.

To grow the user base, you need to listen and respond to *their* needs - ask any streamer ;-)

> That's the nature of the innovator's dilemma and also if one is to be persuasive then it's helpful to remember that talk is cheap, whereas making a closely reasoned argument accompanied by skin in the game - now that is much more persuasive.

As long as I use D, I have 'skin in the game'.

When I stop using D, I'll have no interest in trying to voice my opinion about how it can better serve my needs.

And you don't need to be sending pull requests to have skin in the game.

Also, you seem to be saying that D is more of an incubation language, for creative ideas?

But, it seems to want to strut itself on the world stage as a genuine competitor to industrial strength languages.

Can it be both? (I'd argue, that it cannot be both, and that it needs to choose - soon).

This duality of purpose, is just confusing - and in my opinion, is holding back the language.

A language with only 2 gatekeepers makes sense for a language that wants to be an incubation language for creative ideas - even more so when its for the creative ideas of those 2 gatekeepers.

But a language that wants to compete against industrial strength languages better listen to its users.

I know of no widely used industrial strength language that has only 2 gatekeepers. Because how can only 2 people be representative of its vast number of users? It's not possible.

On Sat, Nov 17, 2018 at 02:07:45AM +0000, Laeeth Isharc via Digitalmars-d wrote: [...]
> (it's fascinating on these kinds of threads the number of accounts that pop up who I never recall having posted before, whatever that may mean)

When an unusually large number of new accounts suddenly pop up, all pretty much echoing the same opinions with the same tone and writing style, it's usually an indication that sockpuppeteering is going on. *shrug*  That's just what some people do with the convenient anonymity of the internet.  It's a practice as old as Usenet, and I've learned to just ignore it.


[...]
> Its a particular subset that post on the forums at all, and plenty of people active on the forums don't express themselves on these kinds of threads.  A subset of a subset.
> 
> I know a few people active in the development of the language and library that don't say much on the forums because they feel making pull requests are more productive.

Also, sometimes these forum discussions just devolve into mud-flinging and/or never-ending reiteration of opinions with no forward progress, so after a while it becomes clear that it's just a waste of time and energy that could have been better spent elsewhere. Like submitting PRs to make D better.


[...]
> And to return to an old point.  It's much better to focus on people that like what you are doing and already using your product than those who say "if only you would do X, D would be huge".  That's the nature of the innovator's dilemma and also if one is to be persuasive then it's helpful to remember that talk is cheap, whereas making a closely reasoned argument accompanied by skin in the game - now that is much more persuasive.

+1.  When it becomes clear to me that a particular debate participant has no vested interest in D, I usually find myself very disinclined to respond.  Talk is cheap for a bystander who can just idly point out all of your flaws yet without lifting a finger himself. Words mean so much more when the person is actually writing D code and facing actual issues in actual, for-real code.  Or better yet, actually contributing to D and pointing out issues that he discovered in the process.


T

-- 
This sentence is false.

On Saturday, 17 November 2018 at 07:05:58 UTC, H. S. Teoh wrote:
>
> Talk is cheap for a bystander who can just idly point out all of your flaws yet without lifting a finger himself.

This is a really awful statement.

I recall Walter getting offended by something recently, but this is far worse.

What you are essentially saying, is that the people who seem like 'new users', that have been involved in this discussion, are just 'bystanders unwilling to lift a finger', and perhaps even all one person creating lots of fake accounts?

First, a user is someone who spends their time learning to use and understand D.

That is time, take from their life, which cannot be taken back.

So just calling them 'bystanders' because they might not be involved in PR's is really offensive - but is pretty typical of what 'new users' have to experience on these forums.

Second, having read back over all the post in this thread, I see no evidence at all, of sockpuppeting. What is the basis for your wild accusation? New users expressing their opinion - or ones that you don't like?

If anyone has ruined this discussion, it was you, with your post.