www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Isn't it about time for D3?

reply Liam McGillivray <yoshi.pit.link.mario gmail.com> writes:
D is a language with much promise, but it still has many problems 
that prevent it from being the great replacement for C++ that it 
was always meant to be.

There have been many changes suggested over time to improve the 
language, but they were rejected as they would inevitably cause 
breaking changes.  I think that breaking changes are something to 
be careful about, and they can definitely be a nuisance to adapt 
to.  But they must happen once in a while for things to advance.

I think it's about time for D3 to start developing.  So many 
suggestions for language changes have accumulated by now so I 
think that it's time to introduce to introduce the next wave of 
breaking changes.
It's nice to see that there's a wiki page that documents the 
history of suggested language changes. I applaud the organization.
https://wiki.dlang.org/Language_design_discussions

I realize that there are people who want to continue using D as 
it is, but those people may continue to use D2. Putting the 
breaking changes in a separate branch ensures that DM won't lose 
current clients as they can just continue using D2 as they are. 
Even after D3 is stabilized, D2 could have continued support 
until nobody wants it.

In Lua (a language with a bigger past and hopefully smaller 
future than D), breaking changes are introduced in even minor 
versions.  While I do think that's excessively frequent, there 
are still users of Lua 5.1.  Making D3 doesn't mean that D2 has 
to die.

I feel like D3 would see significantly wider adoption than D2 
ever got, as long as it successfully solves the problems of D2.

Here are some ways that D3 can be an improvement of D2:
-Final by default
-A standard library that is effective with or without garbage 
collection

Even Andrei has admitted some issues with D when answering this 
Quora question:
https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why

Even if you don't want to release a D3 too soon, I think it 
definately makes sense to get started sooner rather than later.  
D3 should be developed for the same reason that D was first 
developed; to make a better programming language that learns from 
the problems of the one before.
Jun 10
next sibling parent Seb <seb wilzba.ch> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
 D is a language with much promise, but it still has many 
 problems that prevent it from being the great replacement for 
 C++ that it was always meant to be.

 [...]
FYI: There also has been a recent debate about developing a new version of Phobos (http://forum.dlang.org/post/volmdaxjihbkpbtplynj forum.dlang.org) to be able to get rid of auto-decoding, make everything work nicely with nogc and allocators, fix design issues with ranges, cleanup messy packages (e.g. std.traits), etc. I think everyone on the forums here agrees about the problems, it's just not clear what the best course of action is as breaking changes are costly. Remember that there are still companies using D1 or Python 2 out there. OTOH many people representing companies have already vouched here that they would love to see the annoyances fixed and something these issues are even blockers for their official D use at work ...
Jun 10
prev sibling next sibling parent bpr <brogoff gmail.com> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

I'd be fascinated by a revised D like language, say D3 or 
whatever.

 Here are some ways that D3 can be an improvement of D2:
 -Final by default
Wow, after all that, this is it? I think final by default would be an improvement, and I wish it had gone through, but it's not a big enough deal to make a new language.
 -A standard library that is effective with or without garbage 
 collection
That's being worked on with D right now, isn't it? If you're not going to be very bold, what's the point of a D3? Let's really change stuff!
 Structs, enums, and pattern matching, like Rust and ML
 Type follows name like Ada, Scala, Rust, ...
 Macros like Nim
 Parallel features from Chapel
I think it's a huge uphill battle for a new language these days, and that there's more to be gained from fixing the current D and others, but I encourage you to design the next D.
Jun 10
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
 D is a language with much promise, but it still has many 
 problems that prevent it from being the great replacement for 
 C++ that it was always meant to be.

 There have been many changes suggested over time to improve the 
 language, but they were rejected as they would inevitably cause 
 breaking changes.  I think that breaking changes are something 
 to be careful about, and they can definitely be a nuisance to 
 adapt to.  But they must happen once in a while for things to 
 advance.

 I think it's about time for D3 to start developing.  So many 
 suggestions for language changes have accumulated by now so I 
 think that it's time to introduce to introduce the next wave of 
 breaking changes.
 It's nice to see that there's a wiki page that documents the 
 history of suggested language changes. I applaud the 
 organization.
 https://wiki.dlang.org/Language_design_discussions

 I realize that there are people who want to continue using D as 
 it is, but those people may continue to use D2. Putting the 
 breaking changes in a separate branch ensures that DM won't 
 lose current clients as they can just continue using D2 as they 
 are. Even after D3 is stabilized, D2 could have continued 
 support until nobody wants it.

 In Lua (a language with a bigger past and hopefully smaller 
 future than D), breaking changes are introduced in even minor 
 versions.  While I do think that's excessively frequent, there 
 are still users of Lua 5.1.  Making D3 doesn't mean that D2 has 
 to die.

 I feel like D3 would see significantly wider adoption than D2 
 ever got, as long as it successfully solves the problems of D2.

 Here are some ways that D3 can be an improvement of D2:
 -Final by default
 -A standard library that is effective with or without garbage 
 collection

 Even Andrei has admitted some issues with D when answering this 
 Quora question:
 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why

 Even if you don't want to release a D3 too soon, I think it 
 definately makes sense to get started sooner rather than later.
  D3 should be developed for the same reason that D was first 
 developed; to make a better programming language that learns 
 from the problems of the one before.
Dev resources are stretched thin as it is, I doubt the core team would go for it. For example, the vast majority of the work on the main compiler frontend in the last year was done by one person, 3-5 if you're being generous: https://github.com/dlang/dmd/graphs/contributors?from=2016-05-01&to=2017-06-10&type=c I think we need to build that team up before we consider branching again. While it has now been longer since the D2 branch than from the beginning to D2, I get the impression the core team is nowhere near finished with D2, to the point where they want to branch again. While I personally think a D3 branch now would make sense on the technical merits, I doubt we're at an organizational state where we can afford it, ie not enough manpower.
Jun 10
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
 Dev resources are stretched thin as it is, I doubt the core 
 team would go for it.
I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage.
Jun 10
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Adam D. Ruppe wrote:

 On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
 Dev resources are stretched thin as it is, I doubt the core team would 
 go for it.
I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage.
actually, some time ago i proposed to create "experimental and breaking language changes" subforum, where people can go with their wild ideas, and other people can post patches/builds with those (or other) ideas imlemented/half-implemented. this way we can gather some feedback from someone who is really using new feature, and have a better vision if it worth further time investments or not. 'cause having a live compiler with new feature to play with is not the same as simply dicussing the possible feature in NG. i maintain my private fork of dmd/druntime/phobos, and this is the way i evaluate features: just add what i can, and then see if i'll start using it in my code. if not, the feature is cutted, otherwise it is retained. and ah, building dmd from sources is not something many people want/can to do. sure, downloading binaries from random people over the net is not the safest thing to do, but if there will be patch+binary combos, it may work. i.e. i see that "experimental" subforum as a place for ideas *and* implementations. and implementors can provide built binaries for people to play, or other people can build binaries ('cause if you built it for yourself, why don't share it with others?). i know that this forum is actually a newsgroup, and it can't host files. but i believe that this problem can be solved -- either by using some simple js-free (for download; yeah, there are such things! ;-) service to host binaries, or by some other means.
Jun 10
next sibling parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:
 Adam D. Ruppe wrote:

 On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
 Dev resources are stretched thin as it is, I doubt the core 
 team would go for it.
I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage.
actually, some time ago i proposed to create "experimental and breaking language changes" subforum, where people can go with their wild ideas, and other people can post patches/builds with those (or other) ideas imlemented/half-implemented. this way we can gather some feedback from someone who is really using new feature, and have a better vision if it worth further time investments or not. 'cause having a live compiler with new feature to play with is not the same as simply dicussing the possible feature in NG. i maintain my private fork of dmd/druntime/phobos, and this is the way i evaluate features: just add what i can, and then see if i'll start using it in my code. if not, the feature is cutted, otherwise it is retained. and ah, building dmd from sources is not something many people want/can to do. sure, downloading binaries from random people over the net is not the safest thing to do, but if there will be patch+binary combos, it may work. i.e. i see that "experimental" subforum as a place for ideas *and* implementations. and implementors can provide built binaries for people to play, or other people can build binaries ('cause if you built it for yourself, why don't share it with others?). i know that this forum is actually a newsgroup, and it can't host files. but i believe that this problem can be solved -- either by using some simple js-free (for download; yeah, there are such things! ;-) service to host binaries, or by some other means.
Yeah, sounds good, because to make progress, progress has to be made. Most people are very shortsighted and live in a fear based mentality. Mention any type of change and they nearly shit themselves and never actually think about the consequence of those changes. They just assume it means change and it's something they can't handle. Having an "experimental" D allows those crazy and potentially "mind altering" advancements to be worked on, advanced, and polished. It takes time for ideas to grow(because, ultimately, it involves learning and learning takes time). So, the good experimental changes will eventually be adopted. Without such a mechanism, they can't EVER be. The problem is that only the core people of D actually get to decide what is good and they tend to push through changes that haven't been well tested(regardless of what they think, D is a prime example by all the miscalculations as is C). Most people fear growth because growth requires change and change ventures in to the unknown... The unknown is where all the good shit lies and the breakthrough is when someone brings the unknown in to the known.
Jun 10
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Mike B Johnson wrote:

 Yeah, sounds good, because to make progress, progress has to be made. 
 Most people are very shortsighted and live in a fear based mentality. 
 Mention any type of change and they nearly shit themselves and never 
 actually think about the consequence of those changes. They just assume 
 it means change and it's something they can't handle.

 Having an "experimental" D allows those crazy and potentially "mind 
 altering" advancements to be worked on, advanced, and polished. It takes 
 time for ideas to grow(because, ultimately, it involves learning and 
 learning takes time).
yeah. this is exactly the mentality i want to fight with. in my opition, having such forum "officially blessed" will encourage people to experiment. or at least i hope so. ;-)
Jun 10
parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote:
 Mike B Johnson wrote:

 Yeah, sounds good, because to make progress, progress has to 
 be made. Most people are very shortsighted and live in a fear 
 based mentality. Mention any type of change and they nearly 
 shit themselves and never actually think about the consequence 
 of those changes. They just assume it means change and it's 
 something they can't handle.

 Having an "experimental" D allows those crazy and potentially 
 "mind altering" advancements to be worked on, advanced, and 
 polished. It takes time for ideas to grow(because, ultimately, 
 it involves learning and learning takes time).
yeah. this is exactly the mentality i want to fight with. in my opition, having such forum "officially blessed" will encourage people to experiment. or at least i hope so. ;-)
It's an uphill battle. You are fighting human nature/evolution/ignorance ;/ The good news is that humans are good at mountain climbing when they want to be.
Jun 11
parent ketmar <ketmar ketmar.no-ip.org> writes:
Mike B Johnson wrote:

 On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote:
 Mike B Johnson wrote:

 Yeah, sounds good, because to make progress, progress has to be made. 
 Most people are very shortsighted and live in a fear based mentality. 
 Mention any type of change and they nearly shit themselves and never 
 actually think about the consequence of those changes. They just assume 
 it means change and it's something they can't handle.

 Having an "experimental" D allows those crazy and potentially "mind 
 altering" advancements to be worked on, advanced, and polished. It 
 takes time for ideas to grow(because, ultimately, it involves learning 
 and learning takes time).
yeah. this is exactly the mentality i want to fight with. in my opition, having such forum "officially blessed" will encourage people to experiment. or at least i hope so. ;-)
It's an uphill battle. You are fighting human nature/evolution/ignorance ;/ The good news is that humans are good at mountain climbing when they want to be.
yeah. i don't have enough energy to keep a *real* fight going, but i at least poping up with my "experimental forum" idea from time to time. i'm in no hurry, and i'm sure that slow, but constant efforts will won the battle. 10 years, 100 years, 1000 years... as i said, i'm in no hurry at all. ;-)
Jun 11
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:
 Adam D. Ruppe wrote:
 I think dev resources are thin because of mismanagement by the 
 core team failing to attract and retain contributors. Part of 
 this mismanagement is a really discouraging attitude toward 
 positive yet breaking change; I propose that mere willingness 
 to shake up the status quo would help to solve the resource 
 shortage.
+1
 actually, some time ago i proposed to create "experimental and 
 breaking language changes" subforum, where people can go with 
 their wild ideas, and other people can post patches/builds with 
 those (or other) ideas imlemented/half-implemented.
That's called a feature-branch ;-) The nightlies and CI scripts fully support feature branches since a couple of months (i.e. the same branch is checked out on all dmd, druntime and phobos). Currently it's only used for `scope` and `newCTFE`: http://nightlies.dlang.org Currently not much is happening on these feature branches and thus Martin is running the builds on demand by hand. However, from a technical point of view, it would be rather easy to use this for more feature branches ;-)
Jun 10
parent ketmar <ketmar ketmar.no-ip.org> writes:
Seb wrote:

 On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:
 Adam D. Ruppe wrote:
 I think dev resources are thin because of mismanagement by the core 
 team failing to attract and retain contributors. Part of this 
 mismanagement is a really discouraging attitude toward positive yet 
 breaking change; I propose that mere willingness to shake up the status 
 quo would help to solve the resource shortage.
+1
 actually, some time ago i proposed to create "experimental and breaking 
 language changes" subforum, where people can go with their wild ideas, 
 and other people can post patches/builds with those (or other) ideas 
 imlemented/half-implemented.
That's called a feature-branch ;-)
not everybody in the world is github-centric.
Jun 10
prev sibling parent reply Cym13 <cpicard openmailbox.org> writes:
On Sunday, 11 June 2017 at 00:22:50 UTC, Adam D. Ruppe wrote:
 On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
 Dev resources are stretched thin as it is, I doubt the core 
 team would go for it.
I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage.
Building on that: 82% of patches for Mozilla Firefox are accepted at first sight. Analysis of the reviews shows that the developper himself often comes back to his patch to correct it before resubmitting it. Such corrections often are due to style because style isn't generally blocking. That said, having worked on Firefox's codebase a fair amount of time I must say that they have one of the cleanest C++ codebase I've ever seen. The whitepaper is here [1], named "The influence of non-technical factors on code review". I strongly recommend reading it, especially for you Walter and Andrei as I think you might like some of its insights. There again we are not Mozilla, Phobos is a standard library, a compiler doesn't release every 3 months. But one thing is sure, if Firefox can accept 82% of patches at first sight, if 60% of all patches end up being integrated without resubmission, then the projet size isn't an issue. And before such evidence I am definitely not convinced that it should be hard to introduce a change. What should be hard is introducing a bad one. (Then again I'm all talk and not wanting to take care of the matter myself so I'm not expecting anything to change just from this post.) [1]: https://cs.uwaterloo.ca/~rtholmes/papers/wcre_2013_baysal.pdf
Jun 11
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/11/17 5:14 AM, Cym13 wrote:
 Building on that: 82% of patches for Mozilla Firefox are accepted at 
 first sight.
Thanks for referring the paper, I'll read it on the plane. Facebook's rate would be probably comparable. An important detail: is that the rate for internal developers or public contributors? Couldn't get a definitive answer by skimming the paper. -- Andrei
Jun 11
next sibling parent Cym13 <cpicard openmailbox.org> writes:
On Sunday, 11 June 2017 at 12:22:02 UTC, Andrei Alexandrescu 
wrote:
 On 6/11/17 5:14 AM, Cym13 wrote:
 Building on that: 82% of patches for Mozilla Firefox are 
 accepted at first sight.
Thanks for referring the paper, I'll read it on the plane. Facebook's rate would be probably comparable. An important detail: is that the rate for internal developers or public contributors? Couldn't get a definitive answer by skimming the paper. -- Andrei
I'm not certain either. For Webkit they took all patches without discriminating by origin so I think they did the same for Firefox. The development plateform is public so it would be more work to filter commits, therefore I don't think they did.
Jun 11
prev sibling parent Cym13 <cpicard openmailbox.org> writes:
On Sunday, 11 June 2017 at 12:22:02 UTC, Andrei Alexandrescu 
wrote:
 On 6/11/17 5:14 AM, Cym13 wrote:
 Building on that: 82% of patches for Mozilla Firefox are 
 accepted at first sight.
Thanks for referring the paper, I'll read it on the plane. Facebook's rate would be probably comparable. An important detail: is that the rate for internal developers or public contributors? Couldn't get a definitive answer by skimming the paper. -- Andrei
Found it: the paper I linked focuses more on webkit, the case of firefox is detailed in a previous paper [1]. They did choose to focus on core developers defining them as having proposed 100+ patches. This point of the methodology is explained in more details in section IV of the paper. [1]: https://plg.uwaterloo.ca/~migod/papers/2012/wcre12-olgaAlexReid.pdf
Jun 11
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Liam McGillivray wrote:

 I feel like D3 would see significantly wider adoption than D2 ever got, 
 as long as it successfully solves the problems of D2.
..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even more features, and i feel that the way to get The Perfect D (sorry! ;-) is trying to cut all the features that aren't strictly necessary (including fat-free stdlib too: i see stdlib as a part of the language).
Jun 10
parent reply Liam McGillivray <yoshi.pit.link.mario gmail.com> writes:
On Sunday, 11 June 2017 at 00:27:06 UTC, ketmar wrote:
 ..and it actually should be D1.5, not D3. ;-) 'cause D3 implies 
 even more features, and i feel that the way to get The Perfect 
 D (sorry! ;-) is trying to cut all the features that aren't 
 strictly necessary (including fat-free stdlib too: i see stdlib 
 as a part of the language).
D1.5? What? This has nothing to do with D1. D3 would be forked from D2. The reason that it would be considered a major version is because it introduces breaking changes. As far as I know, D2 hasn't been allowed breaking changes since stabilization June 2010.
Jun 10
next sibling parent reply Suliman <evermind live.ru> writes:
There is already something like D3 exists. 
https://github.com/VoltLang
Jun 10
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 11 June 2017 at 05:03:10 UTC, Suliman wrote:
 There is already something like D3 exists. 
 https://github.com/VoltLang
https://github.com/VoltLang/Watt/blob/97507a202250af96560317f84c29cb2248ae588b/src/watt/algorithm.volt#L37-L91 I don't think so.
Jun 10
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Liam McGillivray wrote:

 On Sunday, 11 June 2017 at 00:27:06 UTC, ketmar wrote:
 ..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even 
 more features, and i feel that the way to get The Perfect D (sorry! ;-) 
 is trying to cut all the features that aren't strictly necessary 
 (including fat-free stdlib too: i see stdlib as a part of the language).
D1.5? What? This has nothing to do with D1.
and D1.5 too. sure it should be forked from D2, and then it should be made *smaller*. which, essentially, makes it D1.5, not D3. besides, it will be very fun explaining people that we have D1, then D2, and the newest version is D1.5. people will blog/tweet this, for sure. free PR!
Jun 10
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 11 June 2017 at 05:24:25 UTC, ketmar wrote:
 and D1.5 too. sure it should be forked from D2, and then it 
 should be made *smaller*. which, essentially, makes it D1.5, 
 not D3. besides, it will be very fun explaining people that we
D--? Out of curiosity; wouldn't it be better to start with one of the alternative compilers that are being worked on (SDC or others), or are they no longer active?
Jun 11
parent ketmar <ketmar ketmar.no-ip.org> writes:
Ola Fosheim Grøstad wrote:

 On Sunday, 11 June 2017 at 05:24:25 UTC, ketmar wrote:
 and D1.5 too. sure it should be forked from D2, and then it should be 
 made *smaller*. which, essentially, makes it D1.5, not D3. besides, it 
 will be very fun explaining people that we
D--? Out of curiosity; wouldn't it be better to start with one of the alternative compilers that are being worked on (SDC or others), or are they no longer active?
to remove features, it is nice to *have* those features first. and there are no other feature-complete frontends besides dmdfe.
Jun 11
prev sibling next sibling parent James Hofmann <jhofmann 321f.net> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
 I realize that there are people who want to continue using D as 
 it is, but those people may continue to use D2. Putting the 
 breaking changes in a separate branch ensures that DM won't 
 lose current clients as they can just continue using D2 as they 
 are. Even after D3 is stabilized, D2 could have continued 
 support until nobody wants it.
Here is my suggestion for how to migrate into D3 well, if it were to be done: First define a "Small D2". The goal of this language is to not really be that much smaller(it could still leave in most of the language, in fact), but to sweep up all the changes breaking with D2 into a form that's clearly less flexible while still being palatable for the majority of modules. It's allowed to be intentionally clumsy and regressive in some ways so that it can be forward-looking later, but not so much so that people don't want to write in it. Small D2 is given the freedom to do things like regress standard library functions back into hardcoded compiler behaviors, to be more restrictive, to allow less ambiguity, and to generally follow with existing idioms but break the things that needed breaking and leave out the parts that didn't work. The new stuff of Small D2 would be "one-trick-pony" features that bottleneck what can be expressed into a "library" that is actually a compiler hack, or "new syntax" that is actually fake and only allows arbitrary expressions that are already possible in other ways. Most importantly, Small D2 retains compatibility with regular ("big") D2 modules, so codebases can be migrated into Small D2 piecemeal, while leaving a small remainder to be migrated in a larger way when D3 rolls out. In essence, Small D2 allows the underlying formulation of D to be challenged, but it actually relies on regular D2 constructs internally, so iteration on design can go faster than if we "did it for real". And because Small D2 gives people a taste of new stuff, it will have some instant appeal: People should want to write new code in it, even knowing that it's a hack and less powerful. Small D2 would be the debate platform for what the "core" of D is. Then, D3 is Small D2 with everything "done for real" this time. Small D2 code migrates forward seamlessly and can continue operating as if nothing happened. The rest of it is considered breaking.
Jun 10
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
 I realize that there are people who want to continue using D as 
 it is, but those people may continue to use D2.
Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D.
Jun 11
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Guillaume Piolat wrote:

 On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
 I realize that there are people who want to continue using D as it is, 
 but those people may continue to use D2.
Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D.
as you can see, D is alive and kicking, and nothing disasterous or fatal happens.
Jun 11
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:
 Well, no thanks.
 The very same strategy halved the community for D1/D2 split 
 and almost killed D.
as you can see, D is alive and kicking, and nothing disasterous or fatal happens.
https://forum.dlang.org/search?q=%22D2%22+destroyed+author%3AWalter+author%3ABright&search=Search
Jun 11
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Guillaume Piolat wrote:

 On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:
 Well, no thanks.
 The very same strategy halved the community for D1/D2 split and almost 
 killed D.
as you can see, D is alive and kicking, and nothing disasterous or fatal happens.
https://forum.dlang.org/search?q=%22D2%22+destroyed+author%3AWalter+author%3ABright&search=Search
so what? "nearly destroyed" != "destroyed". as i said, D is alive and ok, nothing fatal happens. backing fear of changes with "last time it almost destroyed us" won't do any good in the long term: it will ultimately end with having no changes at all, D will stagnate and die. changing is a natural thing for evolution, even breaking change. evaluating was what done wrong/inoptimal, and improving on that it the thing that will keep D not only alive, but will make it better and better. otherwise, accumulated legacy will inevitably turn D into another C++, and somebody will create E (or something ;-). why don't create E outselves, and call it D3 instead?
Jun 11
parent reply solidstate1991 <laszloszeremi outlook.com> writes:
On Sunday, 11 June 2017 at 22:53:44 UTC, ketmar wrote:
 so what? "nearly destroyed" != "destroyed". as i said, D is 
 alive and ok, nothing fatal happens. backing fear of changes 
 with "last time it almost destroyed us" won't do any good in 
 the long term: it will ultimately end with having no changes at 
 all, D will stagnate and die.

 changing is a natural thing for evolution, even breaking 
 change. evaluating was what done wrong/inoptimal, and improving 
 on that it the thing that will keep D not only alive, but will 
 make it better and better. otherwise, accumulated legacy will 
 inevitably turn D into another C++, and somebody will create E 
 (or something ;-). why don't create E outselves, and call it D3 
 instead?
E already exists (https://en.wikipedia.org/wiki/E_(programming_language) + AmigaE), two things having the same name often doom one of them into obscurity (see SDLang, which originally was called SDL). There were already a few changes in the language (use of static imports instead of directly accessing functions/libraries, etc), just as we're adding to the language, we can remove rarely used functions by first making them deprecated, then removing them altogether as time passes on.
Jun 11
parent ketmar <ketmar ketmar.no-ip.org> writes:
solidstate1991 wrote:

 E already exists (https://en.wikipedia.org/wiki/E_(programming_language) 
 + AmigaE), two things having the same name often doom one of them into 
 obscurity (see SDLang, which originally was called SDL).
and there were several "D"s too. ;-)
 There were already a few changes in the language (use of static imports 
 instead of directly accessing functions/libraries, etc), just as we're 
 adding to the language, we can remove rarely used functions by first 
 making them deprecated, then removing them altogether as time passes on.
sometimes it is hard or even impossible to change something and keep old feature still working. it also require considerably more efforts to support old and new feature set simultaneously. while D2 can continue evolving (and it surely will!), having D3, where keeping old code working is not a concern, can be useful. nobody says that we should abandon D2 tomorrow and switch everything to D3. it's more about exploring new ways without constant pressure of "don't break the code" mantra. don't get me wrong, tho: "don't break the code" is good. but it limits possible ways D can evolve (or greatly slows it all down). D3 can be "experimental research project", where some of the dreams can come true. it may won't even reach the state where it will replace D2, instead D2 may adopt some D3 features, and D3 will be scrapped (or restarted). there is nothing wrong with it. also, i don't expect D3 to be developed in "full speed" too.
Jun 11
prev sibling parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:
 Guillaume Piolat wrote:

 On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray 
 wrote:
 I realize that there are people who want to continue using D 
 as it is, but those people may continue to use D2.
Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D.
as you can see, D is alive and kicking, and nothing disasterous or fatal happens.
Yes, but could it have been a lot more alive and kicking, hadn't we shot ourselves in the foot with this D1/D2 split?
Jun 12
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Sebastien Alaiwan wrote:

 On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:
 Guillaume Piolat wrote:

 On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
 I realize that there are people who want to continue using D as it is, 
 but those people may continue to use D2.
Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D.
as you can see, D is alive and kicking, and nothing disasterous or fatal happens.
Yes, but could it have been a lot more alive and kicking, hadn't we shot ourselves in the foot with this D1/D2 split?
this question has no answer. can we do better if we will do everything right on the first try? of course!
Jun 12
parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Tuesday, 13 June 2017 at 06:56:14 UTC, ketmar wrote:
 Sebastien Alaiwan wrote:

 On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:
 Guillaume Piolat wrote:

 On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray 
 wrote:
 I realize that there are people who want to continue using 
 D as it is, but those people may continue to use D2.
Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D.
as you can see, D is alive and kicking, and nothing disasterous or fatal happens.
Yes, but could it have been a lot more alive and kicking, hadn't we shot ourselves in the foot with this D1/D2 split?
this question has no answer. can we do better if we will do everything right on the first try? of course!
My point precisely was that "not splitting D1/D2" might correspond to "doing things right".
Jun 13
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Sebastien Alaiwan wrote:

 My point precisely was that "not splitting D1/D2" might correspond to 
 "doing things right".
"not splitting" here means "we're stuck with D1". deprecation cycle of several years (not counting the time required to actually *start* the process) means "no evolution". i must make myself clear here, i guess: i value "good language" way more than "stable language". i absolutely don't mind fixing my code if it makes it better/more clear/etc. while it's hard to sell "constantly evolving" language to Big Enterprise Wheels, not making breaking changes means cloning worst C++ feature. ;-)
Jun 13
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 13 June 2017 at 12:23:19 UTC, ketmar wrote:
 Sebastien Alaiwan wrote:

 My point precisely was that "not splitting D1/D2" might 
 correspond to "doing things right".
"not splitting" here means "we're stuck with D1". deprecation cycle of several years (not counting the time required to actually *start* the process) means "no evolution". i must make myself clear here, i guess: i value "good language" way more than "stable language". i absolutely don't mind fixing my code if it makes it better/more clear/etc. while it's hard to sell "constantly evolving" language to Big Enterprise Wheels, not making breaking changes means cloning worst C++ feature. ;-)
Companies clearly value C++'s backwards compatibility. However, if there's one lesson from the D1/D2 or the Python 2/Python 3 split, it's that it's hugely disruptive (so much so that I find the idea of D3, at the moment, to be such an obviously terrible idea that I really wanted to avoid commenting on this thread). Nevertheless, C++ is still a constantly evolving language. C++14 looks a lot different from C++98. Maintaining backwards compatibility, however, has significantly increased the complexity. Thus, I think there's a trade-off. Breaking changes that improve the language may be good in certain circumstances, but Walter/Andrei should try to get the buy-in from big D users beforehand (even with a depreciation cycle). Requiring some kind of broad support from big D users would mean that breaking changes only happen if the the costs of breaking changes are smaller than the improvement to the language.
Jun 13
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 13 June 2017 at 13:29:45 UTC, jmh530 wrote:

 Companies clearly value C++'s backwards compatibility. However, 
 if there's one lesson from the D1/D2 or the Python 2/Python 3 
 split, it's that it's hugely disruptive (so much so that I find
The D1/D2 split was actually a unifier. It was the Phobos/Tango divide that was the problem. D2 healed that rift, brought us a single runtime that both libraries could share, improved Phobos, and was relatively easy for most projects to transition to (Sociomantic's experience was not common), and D1 was eventually retired. We're all better off for it. A vastly different situation than what happened with Python, where you find 2.x releases continuing on and some projects requiring one or the other. That said, at this stage, I can't imagine a D2/D3 transition being anything other than negatively disruptive.
Jun 13
prev sibling next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
Before even contemplating a big disrupting language split like 
proposed by the OP, wouldn't it first more appropriate to write a 
nice article, DIP, blog, whatever, listing the defects of the 
current language that can not be solved by progressive evolution?
I haven't the impression that the *language* itself suffer from 
so big flaws that it would warrant to fork it in a way that will 
lead to a lot frustration and bewilderment.
D is not perfect, no question, but it is not in a state that 
would jusrify such a harsh approach.
Jun 13
next sibling parent reply crimaniak <crimaniak gmail.com> writes:
On Tuesday, 13 June 2017 at 17:57:14 UTC, Patrick Schluter wrote:

 I haven't the impression that the *language* itself suffer from 
 so big flaws that it would warrant to fork it in a way that 
 will lead to a lot frustration and bewilderment.
I have the same opinion. Raw libraries, poor documentation and infrastructure are much more problematic. If it depended on me, I would declare an embargo on language changes and throw all the forces to eliminate the problems of infrastructure and libraries.
Jun 13
parent ketmar <ketmar ketmar.no-ip.org> writes:
crimaniak wrote:

 If it depended on me, I would declare an embargo on language changes
that's why we (me, and others like me ;-) need D3. i don't need "better phobos", for example ('cause i'm trying to aboid using phobos anyway), but i really need named arguments (`foo(a:42, b:"hello")`). i want '=>' to be usable for any method/free function, not only for lambdas. i want $-expands in mixin strings. warnings on unary minus on byte/short types (do you know that D doesn't do int promition in this case, and C does? it bites me several times!). i want `foreach_reverse` to be replaced with `foreach (auto a; b; reverse)` (and *require* type, modifier or `auto` there). i want optional `ref` and `out` marks for function *calls*. i want... i want alot of things, i'm not even started yet. especially not started to talk about breaking changes. i cannot do that now (i have my private fork of dmd), 'cause i need to keep compatibility with vanilla, and i have zero hopes to see it all introduced in D2 (language stability, etc.). with D2, i'll have a chance to bring 'em on a table.
Jun 13
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Patrick Schluter wrote:

 Before even contemplating a big disrupting language split like proposed 
 by the OP, wouldn't it first more appropriate to write a nice article, 
 DIP, blog, whatever, listing the defects of the current language that can 
 not be solved by progressive evolution?
 I haven't the impression that the *language* itself suffer from so big 
 flaws that it would warrant to fork it in a way that will lead to a lot 
 frustration and bewilderment.
 D is not perfect, no question, but it is not in a state that would 
 jusrify such a harsh approach.
the main reason for D3 is not language changes, but workarounding "don't break user code" thingy. it is completely impossible to experiment freely or introduce breaking changes in D2 (for a reason, there is nothing bad in it).
Jun 13
parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:
 Patrick Schluter wrote:
 the main reason for D3 is not language changes, but 
 workarounding "don't break user code" thingy. it is completely 
 impossible to experiment freely or introduce breaking changes 
 in D2 (for a reason, there is nothing bad in it).
Can you actually show us examples of what you think needs to break? Maybe i am too new to D but beyond a few oddities ( std.array needed for string manipulation, ... ) i see not a lot wrong. Do not underestimate the effect that rewriting a standard library has on a language. Beyond sucking resources away ( D is not a very big community project like Rust ). Frankly one of the reasons why i ended up with D. It has the kitchen and sink, has everything from generics, meta programming and beyond. And the most import factor, it is STABLE. I am working on a big project that needs stability for the next 10+ years. This D3 discussion is discouraging to read. D its flaws are the Phobos documentation layout ( what is partially solved by the Library documentation ), somewhat lacking support on the editors, and other points. Mostly to do because of the small community/lack of full time paid programmers. So call me confused as to what is missing and needs such radical changes? Because i can tell clearly from reading past forums, the whole D1/D2 came up in so much topics it actually made me look first into other languages. A D3 discussion is silly given the history of the language. Unless i am wrong there seem to be only one or two people actually pushing this D3 idea...
Jun 14
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 14/06/2017 8:28 AM, Wulfklaue wrote:
 On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:
 Patrick Schluter wrote:
 the main reason for D3 is not language changes, but workarounding 
 "don't break user code" thingy. it is completely impossible to 
 experiment freely or introduce breaking changes in D2 (for a reason, 
 there is nothing bad in it).
Can you actually show us examples of what you think needs to break? Maybe i am too new to D but beyond a few oddities ( std.array needed for string manipulation, ... ) i see not a lot wrong. Do not underestimate the effect that rewriting a standard library has on a language. Beyond sucking resources away ( D is not a very big community project like Rust ). Frankly one of the reasons why i ended up with D. It has the kitchen and sink, has everything from generics, meta programming and beyond. And the most import factor, it is STABLE. I am working on a big project that needs stability for the next 10+ years. This D3 discussion is discouraging to read. D its flaws are the Phobos documentation layout ( what is partially solved by the Library documentation ), somewhat lacking support on the editors, and other points. Mostly to do because of the small community/lack of full time paid programmers. So call me confused as to what is missing and needs such radical changes? Because i can tell clearly from reading past forums, the whole D1/D2 came up in so much topics it actually made me look first into other languages. A D3 discussion is silly given the history of the language. Unless i am wrong there seem to be only one or two people actually pushing this D3 idea...
Don't worry too much about "D3". While I also want a "D3" it won't be a big technical change, much more likely a philosophical change than anything else. In other words, except for the odd change like final by default for classes(eww), there isn't anything that needs to change for D2. Only smaller improvements which are well worth breaking current semantics.
Jun 14
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
Wulfklaue wrote:

 On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:
 Patrick Schluter wrote:
 the main reason for D3 is not language changes, but workarounding "don't 
 break user code" thingy. it is completely impossible to experiment 
 freely or introduce breaking changes in D2 (for a reason, there is 
 nothing bad in it).
Can you actually show us examples of what you think needs to break?
it would be a very long post. ;-) i scratched it a little above, though. my private dmd fork has 100+ patches only to dmd itself, for example, and some are disruptive enough that alot of my code is marked with `module a is aliced;`.
 Frankly one of the reasons why i ended up with D. It has the kitchen and 
 sink, has everything from generics, meta programming and beyond. And the 
 most import factor, it is STABLE. I am working on a big project that 
 needs stability for the next 10+ years. This D3 discussion is 
 discouraging to read.
and one of mine reasons was "yay, it is relatively new, unencumbered with alot of legacy, and *evolving*!" none of it (our reasoning) is better over another. ;-)
 D its flaws are the Phobos documentation layout
one of the things i absolutely don't care about, for example. ;-) besides, dpldocs rox.
 So call me confused as to what is missing and needs such radical changes?
evolving. something very opposite to "stability", as expected by some enterprise users. remember, not all D users are enterprise users. ;-) some of us (me!) came here 'cause D is fun, not 'cause D is "stable", and we may value stability much less than other kinds of users.
 Unless i am wrong there seem to be only one or two people actually 
 pushing this D3 idea...
as for me, i'm not "pushing" it, i am merely "supporting" it. just to make sure that other optinions besides "no, we don't need D3" are not seeing as non-existant only due to their bearers being silent. ;-)
Jun 14
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, June 14, 2017 07:28:34 Wulfklaue via Digitalmars-d wrote:
 Unless i am wrong there seem to be only one or two people
 actually pushing this D3 idea...
It comes up periodically, because there's some change that someone wants that will never make it into D2. Historically, it's the response to most anyone being told that what they want won't make it into D2, and actually, it used to come up quite a bit, but it rarely comes up now. Sure, there are some changes that we'd probably make to the language if we were doing things from scratch or willing to just break every existing D program, but I think that you'd have a hard time getting folks to agree on a list of what would be changed under those circumstances, and for the most part, I think that folks will agree that it's not worth it at this point - certainly, I think that you're going to have a hard time finding any core contributors who think that starting D3 would be a good idea at this point. And I'd be shocked if anyone managed to convince Walter or Andrei that it was a good idea. Now, there are changes in Phobos which a number of us would like to see that you'll see a much greater consensus on, some of which aren't likely to be possible without breaking a lot of code (most notably, the fact that strings auto-decode to ranges of dchar), which is part of why there was a recent discussion on creating a new version of Phobos that would eventually replace the one that we have now ( http://forum.dlang.org/post/volmdaxjihbkpbtplynj forum.dlang.org ), but even that discussion didn't exactly gain much traction, and changes that require massive breakage in Phobos are unlikely to happen, even if we'd very much like those changes, precisely because they'd cause massive breakage. It's still possible to make changes in the language and standard library without breaking everyone's code, and there's still plenty of room to make some changes which are breaking changes if they bring enough value, but there's a much greater focus on stability and avoiding code breakage than there used to be, and having the massive breakage of redoing the standard library or moving on to a new version of the language really doesn't fit in with that. And we can do quite a lot in place without such massive breakage. However, some folks are always looking for massive changes in the search of making the language perfect. So, there will likely always be occasional talk of moving on to D3, even if it is unlikely to be on the table any time soon, if ever. That being said, if you're expecting to be able to write D code and then have it compile 10 years from now with whatever the current compiler is at that time, you're likely to be disappointed. We're targetting stability, and we're better at managing change than we once were, but there are still occasional changes to the language, and even if the standard library is not undergoing massive churn, it does change somewhat over time. If you're maintaining your code and making the occasional, required adjustments when the language or library changes something that requires adjustments, then you should be just fine without having to do massive code rewrites or anything like that (and at this point, breaking changes normally involve a deprecation process so that they don't just force you to immediately change your code). But if you write your code now and try and compile it in a few years without maintaining it in the interim, then you're likely to have at least some code which won't compile anymore. - Jonathan M Davis
Jun 14
parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Wednesday, 14 June 2017 at 09:18:58 UTC, Jonathan M Davis 
wrote:
 If you're maintaining your code and making the occasional, 
 required adjustments when the language or library changes 
 something that requires adjustments, then you should be just 
 fine without having to do massive code rewrites or anything 
 like that (and at this point, breaking changes normally involve 
 a deprecation process so that they don't just force you to 
 immediately change your code).
That is my point exactly. I have nothing against evolving a language slowly over time to include more features. A few things get obsolete, ... no big issue. New options are added. Again. No big issue. But the moment a language opens up for developers their "wishlist", it seems everybody wants "their" changes added to the language. And this then turn into a language that is constantly changing. That is consider more the worst case scenario. Frankly, if things are handled in a evolutionary way, then i do not have a issue with it. As long as thing do not turn out into: "well, x percentage of your code just become useless". ;) The main issue is library vs existing code. There is a lot of code out there that is now abandoned but still (mostly) works. The moment the evolution gets too far, your starting to get more and more code out there that simple does not work. In my personal opinion, if you want to pull something like that, then make a totally complete clean break. Change the language name ... And yes it sounds radical and silly but if there is one frustrating point that people have new to a language, is legacy non-functional code. I can right now look up Swift examples and get over 50% that simply do not work because the language evolved so fast and everybody used the name "Swift", not "Swift 1.0", "Swift 2.0"... Its frankly a mess. And while i personally love some of the features that Swift has, its a mess for anything outside of the pure Apple development. Just putting the cards on the table but frankly D is a generic name ( Mars was not much better ). When Googling for D code, the results are hit or miss. When Googling for Dlang, it tries to search on GoLang. Marketing is hard when your product is so generic named ( double pun is intended ) :) Just changing the library to D3 and not the base D name will result in people finding old code, not getting it to work, getting frustrated and simply ignoring the language. Hey, despite loving the syntax, did the exact same thing with Swift. With D i can find 3 or 4 year old code and get it running something without a single issue. Or a quick fix. Just saying, its not just about the language and library features. it also about what is round the language. The examples and code out there, the packages, the editors and other support.
Jun 14
parent reply bachmeier <no spam.net> writes:
On Wednesday, 14 June 2017 at 11:34:09 UTC, Wulfklaue wrote:

 Just changing the library to D3 and not the base D name will 
 result in people finding old code, not getting it to work, 
 getting frustrated and simply ignoring the language. Hey, 
 despite loving the syntax, did the exact same thing with Swift.

 With D i can find 3 or 4 year old code and get it running 
 something without a single issue. Or a quick fix. Just saying, 
 its not just about the language and library features. it also 
 about what is round the language. The examples and code out 
 there, the packages, the editors and other support.
D3 isn't going to happen. I ignored this thread as a result. I only read the most recent posts because I wanted to see why it hadn't died. I doubt that Phobos 2 will happen either. All comments I've read from Walter and Andrei indicate that there are no plans for either. I've been using D for four years. I can still compile code that compiled with DMD at that time, with only a few minor modifications. I expect to be able to do the same four years from now.
Jun 14
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2017-06-14 at 11:57 +0000, bachmeier via Digitalmars-d wrote:
=20
[=E2=80=A6]
 I've been using D for four years. I can still compile code that=20
 compiled with DMD at that time, with only a few minor=20
 modifications. I expect to be able to do the same four years from=20
 now.
I suggest this is the wrong view of backward compatibility. If you have a code that is never to change then you should archive the compiler that compiled it along with that code. To demand that D must never fail to compile ancient code is just wrong. If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 14
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
 If a code is to be left untouched but the compiler not archived 
 then the code must be recompiled and amended as needed with 
 each new compiler that is accepted in the workflow.
I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines" then I most likely wouldn't use them and switch to something more stable... So, I have no problem with Python going to Pyton3.x, as long as they update and maintain Python 2.7...
Jun 14
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Ola Fosheim Grøstad wrote:

 On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
 If a code is to be left untouched but the compiler not archived then the 
 code must be recompiled and amended as needed with each new compiler 
 that is accepted in the workflow.
I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines"
at least C doesn't: almost all old-enough code is broken by various "UB".
Jun 14
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote:
 Ola Fosheim Grstad wrote:
 
 On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
 If a code is to be left untouched but the compiler not archived
 then the code must be recompiled and amended as needed with each
 new compiler that is accepted in the workflow.
I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines"
at least C doesn't: almost all old-enough code is broken by various "UB".
The difference is that unlike D deprecations, the C code will still compile and appear to work (for the most part, anyway), thus giving people the illusion that their old code is still "OK". When actually, the compiler may have done something unexpected with the UBs and thus inadvertently introduced security holes. Of course, none of this matters, since when was the last time bad C code has caused security problems? :-P T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Jun 14
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
H. S. Teoh wrote:

 On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote:
 Ola Fosheim Grøstad wrote:
 
 On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
 If a code is to be left untouched but the compiler not archived
 then the code must be recompiled and amended as needed with each
 new compiler that is accepted in the workflow.
I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines"
at least C doesn't: almost all old-enough code is broken by various "UB".
The difference is that unlike D deprecations, the C code will still compile and appear to work (for the most part, anyway), thus giving people the illusion that their old code is still "OK". When actually, the compiler may have done something unexpected with the UBs and thus inadvertently introduced security holes. Of course, none of this matters, since when was the last time bad C code has caused security problems? :-P
yeah. D should silently miscompile old code too: it seems that this is exactly what people want!
Jun 14
parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Wednesday, 14 June 2017 at 21:20:58 UTC, ketmar wrote:
 yeah. D should silently miscompile old code too: it seems that 
 this is exactly what people want!
Please point out the people who advocate for D silently miscompiling old code... Because i have yet to see anybody in this topic advocate this. There is a difference between changes that: - Fix bugs - Fix security issues And changes like - Rewritten Library functions where those function calls end up working differently - Removal of the Garbage collector ( and introducing ownership / lifetime and other rules ) - Changes that make tools not work anymore - ... It is this second part people worry about. If i need to fix code issues 5 years from now because the compiler got smarter, so be it. This will happen anyway with each progressive bugfix / recompile. But there is a difference if massive rewrites are done on the language or libraries for that benefit only a few specific people there own usage. So please keep this topic on track and not pull any straw man argumentation's. Its the internet and i know that some people like to win arguments with any means necessary but keep facts alive thank you very much. I see nothing new being added to this topic anymore beyond more and more ridiculous claims.
Jun 15
parent ketmar <ketmar ketmar.no-ip.org> writes:
Wulfklaue wrote:

 On Wednesday, 14 June 2017 at 21:20:58 UTC, ketmar wrote:
 yeah. D should silently miscompile old code too: it seems that this is 
 exactly what people want!
Please point out the people who advocate for D silently miscompiling old code... Because i have yet to see anybody in this topic advocate this.
we were talking about broken C code. that was a joke about what C commitee did with it's "UB" defintion, and allowing compilers to act as if code never ever can have "UB" in it.
Jun 15
prev sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 14 June 2017 at 20:35:15 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
 If a code is to be left untouched but the compiler not 
 archived then the code must be recompiled and amended as 
 needed with each new compiler that is accepted in the workflow.
I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines" then I most likely wouldn't use them and switch to something more stable... So, I have no problem with Python going to Pyton3.x, as long as they update and maintain Python 2.7...
It's a bigger problem for D than for those languages. If you introduce too many changes, the tools stop working, and we don't have the manpower to fix them. The same goes for libraries. A language with a larger group of developers, like Python, can be less conservative about breaking changes and not have it disrupt the ecosystem.
Jun 14
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 14 June 2017 at 22:01:38 UTC, bachmeier wrote:
 It's a bigger problem for D than for those languages. If you 
 introduce too many changes, the tools stop working, and we 
 don't have the manpower to fix them. The same goes for 
 libraries. A language with a larger group of developers, like 
 Python, can be less conservative about breaking changes and not 
 have it disrupt the ecosystem.
Yes, on the other hand, if you reach a stable version and stop adding features then you can focus on and reach maturity... Then leave the new features to the unstable version. If you keep adding features to a stable branch then maturity is perpetually out of reach. I think Go gained a lot of ground from focusing on maturity over features.
Jun 15
parent reply Suliman <evermind live.ru> writes:
Should D really move to GC-free? I think there is already enough 
GC-free language on the market. D even now is very complected 
language, and adding ways to manually managing memory will make 
it's more complicated.

A lot of people need more powerful static-typing alternative to 
Python/C# for common tasks that allow to build stand-alone 
executable files.

I think it's bad idea to mix to paradigms. People who do not need 
GC at all already use Rust.
Jun 15
next sibling parent Wulfklaue <wulfklaue wulfklaue.com> writes:
On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:
 Should D really move to GC-free? I think there is already 
 enough GC-free language on the market. D even now is very 
 complected language, and adding ways to manually managing 
 memory will make it's more complicated.

 A lot of people need more powerful static-typing alternative to 
 Python/C# for common tasks that allow to build stand-alone 
 executable files.

 I think it's bad idea to mix to paradigms. People who do not 
 need GC at all already use Rust.
Actually, D already supports GC-Free / manual memory management. https://dlang.org/phobos/std_experimental_allocator.html + nogc = manual memory management The issue is that the std library is still full of GC parts and so is third party software. But you can simply turn functions and classes that do not use the library / 3th party software into pure nogc parts. Think of it more as a hybridize system. I think there is somebody here who was writing a non-gc library for D.
Jun 15
prev sibling parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:
 Should D really move to GC-free? I think there is already 
 enough GC-free language on the market. D even now is very 
 complected language, and adding ways to manually managing 
 memory will make it's more complicated.
We need automatic deterministic destruction (and we partially have it, using scope(exit) and structs RAII). Memory management is only the tip of the iceberg of resource management ; it's the easy problem, where an automated process can to tell which resources aren't needed any more. However, an instance of a class can hold a lot more than flat memory blocks: threads, file handles, on-disk files, system-wide events, sockets, mutexes, etc. Freeing the memory of my "TcpServer" instance is mostly useless if I can't reinstanciate a new one because the TCP port is kept open by the freed instance (whose destructor won't be run by the GC).
Jun 15
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Thursday, 15 June 2017 at 17:06:31 UTC, Sebastien Alaiwan 
wrote:
 On Thursday, 15 June 2017 at 15:04:26 UTC, Suliman wrote:
 Should D really move to GC-free? I think there is already 
 enough GC-free language on the market. D even now is very 
 complected language, and adding ways to manually managing 
 memory will make it's more complicated.
We need automatic deterministic destruction (and we partially have it, using scope(exit) and structs RAII).
Not sure what exactly you are expecting, tbh. If you expect classes to be changed to behave like structs with regards to finalization: That can't happen, because they are reference types, not value types: The lifetime of value type objects is statically known to end at their enclosing scope (unless they are moved), in contrast to reference types.
 Memory management is only the tip of the iceberg of resource 
 management ;it's the easy problem, where an automated process 
 can to tell which resources aren't needed any more.

 However, an instance of a class can hold a lot more than flat 
 memory blocks: threads, file handles, on-disk files, 
 system-wide events, sockets, mutexes, etc.
All of which you can easily take care of in the class' destructor and then .destroy such objects when needed.
 Freeing the memory of my "TcpServer" instance is mostly useless 
 if I can't reinstanciate a new one because the TCP port is kept 
 open by the freed instance (whose destructor won't be run by 
 the GC).
*might not be run by the GC when you want it to. Why are you even talking about the GC when your problem seems to require deterministic lifetime management. That's not what a GC does, and thus it's the wrong tool for the job. The right tool here would be one of - std.experimental.allocator.{make,dispose} (statically known lifetime) - {std.typecons / automem}.RefCounted (dynamic lifetime)
Jun 15
parent Sebastien Alaiwan <ace17 free.fr> writes:
On Thursday, 15 June 2017 at 18:02:54 UTC, Moritz Maxeiner wrote:
 We need automatic deterministic destruction (and we partially 
 have it, using scope(exit) and structs RAII).
Not sure what exactly you are expecting, tbh.
I'm not advocating for a language change here. As I said, we already have some deterministic destruction (the rest being the GC).
 Why are you even talking about the GC when your problem seems 
 to require deterministic lifetime management. That's not what a 
 GC does, and thus it's the wrong tool for the job.
I don't have a programming problem ; I'm fine with unique and scoped! I just wanted to make a point about how even GC-languages still benefit from some extra automatic and deterministic means of resource management.
Jun 15
prev sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
 On Wed, 2017-06-14 at 11:57 +0000, bachmeier via Digitalmars-d 
 wrote:
 
[…]
 I've been using D for four years. I can still compile code 
 that compiled with DMD at that time, with only a few minor 
 modifications. I expect to be able to do the same four years 
 from now.
I suggest this is the wrong view of backward compatibility. If you have a code that is never to change then you should archive the compiler that compiled it along with that code. To demand that D must never fail to compile ancient code is just wrong. If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow.
I'm not saying all old code should compile without changes, just that it should compile with only minor changes. I know that in some cases new releases of DMD have stopped compiling pieces of my code that shouldn't have compiled in the first place, and that's a good thing. On the other hand, dropping the GC would be a dramatic change that would require a complete rewrite. Libraries have to work with future versions of the compiler, especially if others are using them and can't make changes themselves.
Jun 14
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2017-06-14 at 21:55 +0000, bachmeier via Digitalmars-d wrote:
 [=E2=80=A6]
=20
 I'm not saying all old code should compile without changes, just=20
 that it should compile with only minor changes. I know that in=20
 some cases new releases of DMD have stopped compiling pieces of=20
 my code that shouldn't have compiled in the first place, and=20
 that's a good thing. On the other hand, dropping the GC would be=20
 a dramatic change that would require a complete rewrite.=20
 Libraries have to work with future versions of the compiler,=20
 especially if others are using them and can't make changes=20
 themselves.
If D dropped the GC, then there wouldn't be a problem because there wouldn't be any users. The GC is the single major factor for D in a world of C++17, Rust, and Go: without the GC there is little point in using D since C++, Rust, and Go have much more resources for development of tools as much as of the language =E2=80=93 cf. CLion, Goglan= d, IntelliJ IDEA/Rust plugin to name just the JetBrains IDEs. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 15
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Thursday, 15 June 2017 at 07:32:42 UTC, Russel Winder wrote:
 The GC is the single major factor for D in a world of C++17, 
 Rust, and Go:
An opinion. Mine is this: The two major factors for D are (and have been for as long as I've been using it): 1. Productivity (i.e. focusing on writing actual problem solving code, not on dealing with language deficiencies) 2. Maintainability (i.e. still have that productive code look reasonable easy to understand a year from now without having to look up language deficiencies to understand why something *has* to look exactly the way it does, or introduce bugs) The GC is nice in that it contributes to both of these points (and I have no desire to see it removed), but even without it there is no other native language (that I've tried as of yet) that comes even remotely close.
 without the GC there is little point in using D since C++, 
 Rust, and Go have much more resources for development of tools 
 as much as of the language – cf. CLion, Gogland, IntelliJ 
 IDEA/Rust plugin to name just the JetBrains IDEs.
Still an opinion, so here is mine again (based merely on personal experience): Despite all those resources, someone having invested about the same amount of time in mastering C++(17), Rust, Go, and D will still end up being more productive in D, simply because, out of all of these languages, you have to fight D to do what you want the least. Is D perfect? No, not by any stretch of the definition, but it is still (by far) the least worst choice out there, no matter how good the tooling for other languages is or becomes.
Jun 15
parent ketmar <ketmar ketmar.no-ip.org> writes:
Moritz Maxeiner wrote:

 Is D perfect? No, not by any stretch of the definition, but it is still 
 (by far) the least worst choice out there, no matter how good the tooling 
 for other languages is or becomes.
exactly my feelings! ;-)
Jun 15
prev sibling parent Sebastien Alaiwan <ace17 free.fr> writes:
On Tuesday, 13 June 2017 at 17:57:14 UTC, Patrick Schluter wrote:
 Before even contemplating a big disrupting language split like 
 proposed by the OP, wouldn't it first more appropriate to write 
 a nice article, DIP, blog, whatever, listing the defects of the 
 current language that can not be solved by progressive 
 evolution?
 I haven't the impression that the *language* itself suffer from 
 so big flaws that it would warrant to fork it in a way that 
 will lead to a lot frustration and bewilderment.
 D is not perfect, no question, but it is not in a state that 
 would jusrify such a harsh approach.
+1 Does anyone currently maintain somewhere such a list of not-gonna-be-fixed-in-D2 defects? This might provide more solid grounds to this discussion.
Jun 13
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
jmh530 wrote:

 Nevertheless, C++ is still a constantly evolving language.
one of the key features of evolution is removing old and rudimentary things. without this, it is not evolution, it is mutilation...
Jun 13
prev sibling next sibling parent meppl <mephisto nordhoff-online.de> writes:
in my opinion starting with D3 is too early, because D-people 
dont even seem to know how exactly to implement new exciting 
features like "reference counting" (and how will "reference 
counting" work together with the new "scope"-feature?).

So, if a D3 gets developed _now_, i guess the compiler developers 
will create syntax issues again for those features and then we 
need a D4. Instead it might be better to collect more experience 
before thinking about D3
Jun 11
prev sibling next sibling parent meppl <mephisto nordhoff-online.de> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
 I realize that there are people who want to continue using D as 
 it is, but those people may continue to use D2. Putting the 
 breaking changes in a separate branch ensures that DM won't 
 lose current clients as they can just continue using D2 as they 
 are. Even after D3 is stabilized, D2 could have continued 
 support until nobody wants it.
sorry, i was overreading those lines of yours
Jun 11
prev sibling next sibling parent solidstate1991 <laszloszeremi outlook.com> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
 D is a language with much promise, but it still has many 
 problems that prevent it from being the great replacement for 
 C++ that it was always meant to be.

 There have been many changes suggested over time to improve the 
 language, but they were rejected as they would inevitably cause 
 breaking changes.  I think that breaking changes are something 
 to be careful about, and they can definitely be a nuisance to 
 adapt to.  But they must happen once in a while for things to 
 advance.

 I think it's about time for D3 to start developing.  So many 
 suggestions for language changes have accumulated by now so I 
 think that it's time to introduce to introduce the next wave of 
 breaking changes.
 It's nice to see that there's a wiki page that documents the 
 history of suggested language changes. I applaud the 
 organization.
 https://wiki.dlang.org/Language_design_discussions

 I realize that there are people who want to continue using D as 
 it is, but those people may continue to use D2. Putting the 
 breaking changes in a separate branch ensures that DM won't 
 lose current clients as they can just continue using D2 as they 
 are. Even after D3 is stabilized, D2 could have continued 
 support until nobody wants it.

 In Lua (a language with a bigger past and hopefully smaller 
 future than D), breaking changes are introduced in even minor 
 versions.  While I do think that's excessively frequent, there 
 are still users of Lua 5.1.  Making D3 doesn't mean that D2 has 
 to die.

 I feel like D3 would see significantly wider adoption than D2 
 ever got, as long as it successfully solves the problems of D2.

 Here are some ways that D3 can be an improvement of D2:
 -Final by default
 -A standard library that is effective with or without garbage 
 collection

 Even Andrei has admitted some issues with D when answering this 
 Quora question:
 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why

 Even if you don't want to release a D3 too soon, I think it 
 definately makes sense to get started sooner rather than later.
  D3 should be developed for the same reason that D was first 
 developed; to make a better programming language that learns 
 from the problems of the one before.
I think we just should do those little fixes on D2 (eg. fixing the standard library, DIP45), instead of yet again reinventing the wheel. We have limited resources, I think first and foremost we should port the backend from C to D to further improve our productivity on the main compiler, then bugfixes and implementing non-x86 targets will be much easier.
Jun 11
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
 D is a language with much promise, but it still has many 
 problems that prevent it from being the great replacement for 
 C++ that it was always meant to be.

 [...]
I anyone seeing the "i think" "I think"...statements? It's not something "you know". He doesn't mention "his" problem with GC. I would like to know
Jun 12
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

I'd be in favor of finally deprecating all sub-standard phobos 
module (moving them to https://github.com/dlang/undeaD) to make 
room for good implementations. Having a vacant place might be 
more encouraging than to wait for something better to come along.
Of course discussing which modules should be obsoleted is a 
tricky question.

std.signals
std.xml
std.outbuffer
std.socket
std.json // maybe ;)

I do not at all agree that a big language change is needed.
We just changed the lookup rules with 
http://dlang.org/changelog/2.071.0.html and managed to make this 
a transition instead of a break.
Also without a proposed feature list this discussion is somewhat 
lame.
Jun 14
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-14 11:38, Martin Nowak wrote:

 Also without a proposed feature list this discussion is somewhat lame.
You only need one, AST macros ;) -- /Jacob Carlborg
Jun 14
parent Martin Nowak <code dawg.eu> writes:
On Wednesday, 14 June 2017 at 19:12:36 UTC, Jacob Carlborg wrote:
 You only need one, AST macros ;)
Not going to happen anytime soon, as we do not have much interest in DSL abuse.
Jun 18
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Wednesday, 14 June 2017 at 09:38:06 UTC, Martin Nowak wrote:
 I'd be in favor of finally deprecating all sub-standard phobos 
 module (moving them to https://github.com/dlang/undeaD) to make 
 room for good implementations. Having a vacant place might be 
 more encouraging than to wait for something better to come 
 along.
 Of course discussing which modules should be obsoleted is a 
 tricky question.

 std.signals
 std.xml
 std.outbuffer
 std.socket
 std.json // maybe ;)

 I do not at all agree that a big language change is needed.
 We just changed the lookup rules with 
 http://dlang.org/changelog/2.071.0.html and managed to make 
 this a transition instead of a break.
 Also without a proposed feature list this discussion is 
 somewhat lame.
Let's do this! https://github.com/dlang/phobos/pull/5488
Jun 15
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 14 June 2017 at 09:38:06 UTC, Martin Nowak wrote:
 On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray 
 wrote:

 I'd be in favor of finally deprecating all sub-standard phobos 
 module (moving them to https://github.com/dlang/undeaD) to make 
 room for good implementations. Having a vacant place might be 
 more encouraging than to wait for something better to come 
 along.
 Of course discussing which modules should be obsoleted is a 
 tricky question.
I just got done with watching this great presentation by Rich Hickey[1]. It's about change, how semantic versioning is broken, and why packages are wrong when it comes to dependencies. In essence he is saying we should have immutable code releases. For example he would say that we should add a new namespace and not get rid of the original (std2.io, std2.xml, std2.json) now you can get your improvements out and not break anyone's code, for example he would say old modules would be deprecated but never removed. I don't agree 100% with him but he does make good points. Really what I'm hearing out of it is that these semantic versioned packages should all be accessible from your code, when you upgrade the package you don't automatically start calling the new version of the functions but instead get access to those functions along with all the previous releases. But that is a lot of extra information to add to every function call: Package(arg, 1.4.2) foo(string i, int s) ... 1. https://www.youtube.com/watch?v=oyLBGkS5ICk&feature=youtu.be
Jun 15
parent Martin Nowak <code dawg.eu> writes:
On Thursday, 15 June 2017 at 18:26:57 UTC, Jesse Phillips wrote:
 In essence he is saying we should have immutable code releases. 
 For example he would say that we should add a new namespace and 
 not get rid of the original (std2.io, std2.xml, std2.json) now 
 you can get your improvements out and not break anyone's code, 
 for example he would say old modules would be deprecated but 
 never removed.
Not much different from moving old code to Undead, requires very little work. On a plus side you have to decide whether to upgrade your code or stick with the existing modules.
Jun 18
prev sibling next sibling parent reply Mike <none none.com> writes:
On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

 I think it's about time for D3 to start developing.
I would love to see a fork of D2 that attempts to address some obstacles I encountered when I was using D. However, it is quite apparent that there is little to no interest in such a venture from those in the D community with the talent to actually do it. And I have to admit there is still room for innovation in D2, and that seems to be where most want to allocate their limited resources. For D3 to happen, it will likely require talent outside D's core team. I do a lot of programming in different domains, and it seems I have to use a different language for each one in order to be productive. I would like to find a single language that I can use to program just about any domain, but still be able to enjoy modern features for safety, convenience, zero-cost abstractions, and modeling power. I'm not aware of any language that fits that description, but the languages I've found to be somewhat close are C++11~17 and Rust. They're the only ones that appear to be scalable down to domains such as resource constrained microcontrollers. * Using D for resource constrained systems requires too many compromises and silly runtime hackery. * C++11~17 is quite good but it is not at all convenient, and safety is just too easy to get wrong. * Rust is probably the best, but it doesn't have the modeling power of D and C++. It'd be more constructive to begin collecting information from the community about what changes they'd like to see in D3. Here's a start from things just off the top of my head and in no particular order. THINGS TO CHANGE OR ADD ----------------------- * Final-by-default * immutable by default * safe by default * Fix attribute inconsistency and revisit if D is using the appropriate defaults * Pay as you go druntime. The compiler is too coupled to druntime and expects things to be there even though they're not required. This would also make D a better language for replacing much of the exising infrastructure code out there that is currently written in C because it wouldn't require the D runtime dependency and all the overhead that goes with it. Rust has done well in this regard. * Minimal druntime The language should be easy to port to other platforms. Keep druntime small and to a few fundamental primitives to whatever extent that is possible. Rust has also done well in this regard. * Compiler resolves druntime symbols at compile time. This is important for porting D to other platforms that may not have the resources or hardware to support certain features of the language. The compiler would emit a compile-time error if usage of such a feature was attempted, but not supported by the runtime. Proposed here [1]. * Some way to mark memory at compile-time with certain attributes (e.g. See [2]) to inform the compiler of proper code generation (e.g. volatile semantics). This would probably only be useful for bare-metal programming, but I encounter this all the time and its getting worse with each new MCU generation. * Remove the "module must be a file" arbitrary limitation I ran into this when I was trying to model hundreds of memory-mapped IO registers. I wanted to use a module for each register, but each module would only have a small amount of code, and I would have ended up with hundreds of little files. It would have been better if I could group all "register" modules for a given peripheral under one "peripheral.d" package file. Something like `package UART { module SR {} module DR{} }` would have been nice. I ultimately ended up with `final abstract class {}` instead, which is stupid. * get rid of the "_t" suffix added to types from C. Come up with a better, more consistent naming convention for these types that doesn't carry baggage from other languages. * Drop the GC or at a minimum make it opt-in. Add a borrow checker, automatic reference counting, or some other GC alternative that doesn't require a separate thread. DIP1000 is interesting and may enable some new interesting patterns and idioms. Might be able to take some inspiration from it. I wonder if DIP1000 would have been more elegant if D didn't have to worry about breaking code. * The C standard library bindings and C++ standard library bindings should be in Deimos not in the druntime. I already tried to promote this, but only encountered obstruction. * Cure the TypeInfo infection [3] TypeInfo has been over(ab)used in the runtime implementation. This is probably due to historical baggage, but also a lack of discipline. THINGS TO KEEP -------------- * CTFE * Templates and static-if (static-if is some powerful stuff!) * Mixins (or some other way to do convenient composition) I get that one should favor composition over inheritance, but most object oriented languages offer precious little to do the "right" thing. D mixins are great for composition. * Traits (or some other form of reflection) * UFCS THINGS TO DROP -------------- * C++ interoperabiliy Walter's right: memory safety is going to kill C and C++ will go with it. Don't waste time on this; it's not going to matter in 10 or 20 years. After collecting such a list, begin a fork of LDC, and start working on it. If you can show progress and potential, others may be willing to contribute, accelerating the project. I, personally, think it would be very exciting to see and would eventually become an active contributor myself if the project addressed some of the issues I have with D2. I was on cloud 9 when I first started using D, and had high hopes that it would change my career and even give me a new tool off which to build a profitable business. But the more I used it, I just became more disillusioned. D has so much potential compared to all other languages out there, but it's potential that it will never reach because it's just carrying too much baggage and has not been designed with domains like resource constrained microcontrollers in mind, like Rust was. I don't do anything in D anymore, but I still watch what goes on here in the D community, and hope that someday enough people will come together and begin a fork to take D to its true potential. I don't have the skills or resources at this time to lead such a project, but I'll volunteer my resources if it ever gets off the ground and shows promise. Mike [1] - Proposal to have druntime inform compiler of platform support - http://forum.dlang.org/post/psssnzurlzeqeneagora forum.dlang.org [2] - ARM Cortex-M3 memory attributes - https://developer.arm.com/products/processors/cortex-m/cortex-m3/docs/dui0552/latest/2-the-cortex-m3-processor/22-memory-model/221-memory-regions-types-and-attributes [3] - Discussion about the TypeInfo infection - http://forum.dlang.org/post/nevipjrkdqxivoerftlw forum.dlang.org
Jun 14
next sibling parent Wulfklaue <wulfklaue wulfklaue.com> writes:
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
 * Rust is probably the best, but it doesn't have the modeling 
 power of D and C++.
A lot of the points you mention, i also agree with but implementing that list is akin to writing a new language. You do not trow out the baby with the bathwater ;) From what i am reading, you want D to be Rust. Personally, Rust make me want to tear out my eyes the moment you start with lifetimes, unwrapping and ownership all combined , its becomes almost unreadable.
    fn the_longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
        if s1.len() > s2.len() { s1 } else { s2 }
    }
Rust really skips on the syntactic sugar *lol*. If people want a low level language for microprocessors/plc, well they already got C++14/17 and Rust. D can carve its own market segment no? Why complicate D for one specific market segment? There are defiantly nice point that you mention but dropping C/C++ support is like a dead sentence. D does not have the manpower and libraries that people may need.
Jun 14
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
 * immutable by default
I have to admit I always get confused why people get so invested in this. It seems like you would have to completely redesign everything related to std.range/std.algorithm.
Jun 15
prev sibling next sibling parent reply Liam McGillivray <yoshi.pit.link.mario gmail.com> writes:
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
 THINGS TO DROP
-------------- * C++ interoperabiliy Walter's right: memory safety is going to kill C and C++ will go with it. Don't waste time on this; it's not going to matter in 10 or 20 years.
Thank you for making a list to give people an idea of what D3 could be, but I definitely don't support less interoperability with C++. I want D3 to have a better argument to transition from C++ than D2 has. With all the C++ API's out there, making D incompatible would be a ginormous deal-breaker for a ridiculous number of projects. D3 should seek to be worth the transition from C++. For those who say that this idea can't go anywhere without an idea of what changes it would make, I'll relink to the page I already posted. There are many proposals that were rejected due to "breaking changes" that should be relooked for D3. https://wiki.dlang.org/Language_design_discussions People who say they like D2 for "stability" don't need to worry. What would be a threat to stability is breaking changes in D2. But that was never allowed, so you must not worry. If D3 was released, you may still use D2 just as you would have otherwise. For the people who talk about D3 being an alternative to, rather than a replacement for D2: I think that D3 should seek to be a better option than D2 for virtually every new project. If done right, it will barely split the community; I'm hoping for D3 to expand the popularity of D to overshadow what D2 ever was. Improving some things in D would make it an easier sell to C++ programmers, even in converting existing projects. What I think should be one of, if not the #1, main goal of D3 is to significantly shrink the number of scenario's in which C++ is more viable than D (to less than one third. Not "more viable" in the opinions of the D fanatics here, but to everyone who properly considers D vs C++. I feel like D only needs one more major (breaking) revision to do this, and it would be a less dramatic change than D1-D2. For those who are saying that everything is right with D2, I want to point out that there is a bias to the people in this forum. It is that people posting here tend to be "insiders", who don't mind/see the problems that discourage others from using D. There are surely many "outsiders" out there (not reading this) who have considered D in the past, but chose C++ instead for valid reasons. I recommend searching the internet for others opinions on D. You may find disadvantages of D apparent to other programmers that you never thought of. Have you ever talked to a C++ programmer about what they think of D, and why they don't use it? Also, I must say that although D is often discussed as a "systems programming language", I also have high hopes for it as an application programming language. Once it's more widely supported, it can significantly lower the barrier-of-entry for programming. People naturally gifted at programming probably don't realize how ridiculously high the barrier of entry is for most people, even those who are interested. I hope that Walter and Andrei give a proper response to this thread. I wonder why they haven't.
Jun 16
next sibling parent reply Suliman <evermind live.ru> writes:
On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:
 On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
 THINGS TO DROP
-------------- * C++ interoperabiliy Walter's right: memory safety is going to kill C and C++ will go with it. Don't waste time on this; it's not going to matter in 10 or 20 years.
Totally agree! C++ now in 90% of cases is legacy projects. At current time is more important to out of the box interoperability with Rust or Julia. Time show that C++ do not want to migrate to D. Only few people come from C++ world, because all of them waiting of new C++ standard c++x2035 (or whatever)
Jun 16
parent reply Liam McGillivray <yoshi.pit.link.mario gmail.com> writes:
Removing all C++ compatibility is a death sentence for D.  This 
may not be apparent to some people that already program in D, but 
it is downright critical to potential D users.  Zero C++ 
compatibility means that D can no longer interface with C++ 
libraries such as Qt, putting a severe limitation on it's uses.

At the very least, dropping C++ compatibility is not for D3.  If 
ever, it should happen when D is already as popular as C++.  I 
brought up this whole D3 idea because I feel like D just needs 
one more wave of breaking changes to the language and library to 
be brought to perfection.  There are many C++ programmers out 
there who looked into/tried D and felt like it was almost good 
enough.  I think it will just take one major breaking version to 
make them jump, but not if it's totally incompatible with C++.

D3 should make the changes that can be agreed between proud D 
users and C++ users who have hopes for D.

On Saturday, 17 June 2017 at 06:23:08 UTC, Suliman wrote:
 On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray 
 wrote:
 On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
 THINGS TO DROP
-------------- * C++ interoperabiliy Walter's right: memory safety is going to kill C and C++ will go with it. Don't waste time on this; it's not going to matter in 10 or 20 years.
Totally agree! C++ now in 90% of cases is legacy projects. At current time is more important to out of the box interoperability with Rust or Julia. Time show that C++ do not want to migrate to D. Only few people come from C++ world, because all of them waiting of new C++ standard c++x2035 (or whatever)
Please don't quote me just to say "Totally agree!" to someone that I quoted and disagree with. A prediction that C++ is going to be dead in 10 years is not good enough. C++ is very active, not just legacy like you say. As I said, D should not drop compatibility until it's ALREADY clear that it's getting surpassed by D. I support interoperability with Rust if it's doable. I barely know about Julia. Like I said, there are actually many C++ programmers out there who feel like D2 has promise, but not quite there. THIS is why I brought up this D3 idea. I really do think that D3 could bring quite some excitement to the programming community if it's coming along well. After a few of the more open-minded C++ programmers adopt D, it will trickle up to more and more.
Jun 17
parent reply Suliman <evermind live.ru> writes:
Why for example not Rust (i am not its fan). I do not see any 
real perspective in C++. What to do in next 5 years if C++ will 
start loosing it's popularity? Implement D4?

Plus any backwards compatibility make implementation new ideas in 
language very hard.
Jun 18
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 18 June 2017 at 07:14:24 UTC, Suliman wrote:
 Why for example not Rust (i am not its fan). I do not see any 
 real perspective in C++. What to do in next 5 years if C++ will 
 start loosing it's popularity? Implement D4?

 Plus any backwards compatibility make implementation new ideas 
 in language very hard.
Both C/C++ are loosing popularity relatively speaking, but this is not because of the languages themselves. It is because more and more applications can be written either fully or in part in higher level languages. So C++ is taking over parts of the former C domain, and other high level languages are taking over some parts of the C++ application development domain. But C++ will still be big in 10 years.
Jun 18
parent reply Suliman <evermind live.ru> writes:
 But C++ will still be big in 10 years.
Ok, let's assume it will be poplar in 10 years. But it's very short time. D exists almost 17 years. And not every people need to interfacing with C/C++. For me it's more important to have static-typing and compilable alternative to Python. And a lot of people whom I know want same.
Jun 18
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 18 June 2017 at 12:05:37 UTC, Suliman wrote:
 And not every people need to interfacing with C/C++. For me 
 it's more important to have static-typing and compilable 
 alternative to Python. And a lot of people whom I know want 
 same.
I see this a lot, but then you have to ask yourself how many languages are trying to enter the same domain (faster Python). In the end a language has to be the best for some particular domain to gain traction.
Jun 18
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:
 I hope that Walter and Andrei give a proper response to this 
 thread.  I wonder why they haven't.
They rarely give definitive answers... except after the fact, once it is already in master.
Jun 17
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 17 June 2017 at 04:32:41 UTC, Liam McGillivray wrote:
 On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
 THINGS TO DROP
-------------- * C++ interoperabiliy Walter's right: memory safety is going to kill C and C++ will go with it. Don't waste time on this; it's not going to matter in 10 or 20 years.
Thank you for making a list to give people an idea of what D3 could be, but I definitely don't support less interoperability with C++. I want D3 to have a better argument to transition from C++ than D2 has. With all the C++ API's out there, making D incompatible would be a ginormous deal-breaker for a ridiculous number of projects. D3 should seek to be worth the transition from C++.
Seems like there is a split right down the middle. The problem is of course that going down the middle is neither satisfactory nor innovative. I agree with you, but I think the C++ compatibility is a lost game and increasingly so without aligning the core semantics. C++ is changing too...
Jun 17
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
 * Drop the GC or at a minimum make it opt-in.  Add a borrow 
 checker, automatic reference counting, or some other GC 
 alternative that doesn't require a separate thread.
AIUI D's GC doesn't use a separate thread: https://dlang.org/spec/garbage.html#how_gc_works "1. Stopping all other threads than the thread currently trying to allocate GC memory. 2. ‘Hijacking’ the current thread for GC work." An earlier bullet point is confusing: "Normally, all threads other than the collector thread must be halted while the collection is in progress." Probably 'other than the collector thread' should be removed - 'collector thread' implies asynchronous collections.
Jun 19
prev sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Here are some ways that D3 can be an improvement of D2:
 -Final by default
 -A standard library that is effective with or without garbage 
 collection
100% OK about the optional garbage collector, but I have to totally disagree with you on the "final by default" approach. The current design keeps the code open to extension, in a perfectly complementary way to UFCS. They are both incredibly useful, and are part of what makes D2 perfectly work as a strongly-typed JavaScript-like scripting language. (I just had another proof of that this morning, see my recent post.) And dropping C++ compatibility is a complete non-sense IMHO. If you want more people using D, its interoperability with C and C++ should instead be improved, so that D applications can quickly and easily use any C/C++ 3D/2D/VR/audio multimedia libraries for instance...
Jun 18