On Thursday, November 15, 2018 7:02:26 PM MST H. S. Teoh via Digitalmars-d wrote:
> On Thu, Nov 15, 2018 at 06:03:37PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...]
>
> > *sigh* Honestly, auto-decoding is almost a perfect storm of issues for us being able to actually get rid of it. So, while I agree with you that we'd ideally fix the problem, it's _not_ an easy one to fix, and really the only "easy" way to fix it is to pretty much literally say "D3" and hard break all code. I think that the reality of the matter is that there are issues in every language that you can't fix without either creating a new language or creating a new version of the language that's not backwards compatible with the old one (which then forks the language and community).  So, while we'd very much like to fix everything, there are going to be some things we simply can't fix if we're not willing to create D3, and talking about D3 creates a whole other can of worms, which I don't think we're even vaguely ready for yet.
>
> Talking about D3 has sorta become taboo around here, for understandable reasons -- splitting the community now might very well be the death of D after that Tango vs. Phobos fiasco.  Python survived such a transition, and Perl too AIUI.  But D currently does not have nearly the size of Python or Perl to be able to bear the brunt of such a drastic change.
>
> Nevertheless I can't help wondering if it would be beneficial to one day sit down and sketch out D3, even if we never actually implement it. It may give us some insights on the language design we should strive to reach, based on the experience we have accumulated thus far. Autodecoding, even though it's a commonly mentioned example, actually is only a minor point as far as language design is concerned.  More fundamental issues could be how to address the can of worms that 'shared' has become, for example, or what the type system might look like if we were to shed the vestiges of C integer promotion rules.

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

In any case, I think that _most_ of the things that should go in something like D3 can be done in D2 so long as Walter and Andrei can be convinced. For instance, we totally _could_ fix the nonsense about treating bool as an integer type in D2. There's nothing about that that requires D3. Unfortunately, of course, Walter and Andrei weren't convinced by the DIP that would effectively have fixed that by removing the implicit conversions from integer literals to bool, so that's not happening in D2 unless something drastic changes, and as such, I see no reason to expect that it would happen in D3. And I think that most of the potential changes are like that. Maybe Walter and Andrei can be convinced of a particular change, maybe not. But each change can tackled individually, and for the most part, I think that the ones that have real value can be made in D2 (though obviously, convincing Walter and Andrei of any particular change is rarely easy). It's just the real earth-shattering ones like reversing the defaults of things that can't be, and I'm not at all convinced that any of those would actually be a good idea anyway, much as folks like to talk about them. In a large program, it can very much be worth going to the extra effort of making your program work with a lot of extra attributes, but they often just get in the way, and forcing them on all programs by default would easily risk making D miserable to work in by default. LOL. Walter's comment at dconf this year that he wished D had const as the default definitely makes me that much more leery of D3 ever arriving, since I increasingly avoid const in D.

Honestly, the only thing I can think of where I'd love the opportunity to be able to sit down and start from scratch would be ranges - and not just for auto-decoding. I'd want to rework them so that save wasn't a thing, and I'd want to figure out how to rework them so that the reference and value semantics were cleaner. What we have works really well in the common case but ends up as a bit of a mess in the corner cases, and I don't think that it's entirely fixable. It's mostly a library issue (though it's also partly an issue with foreach), but it's pervasive enough that we can't really change it at this point. It's one of those areas where we introduced a revolutionary idea, and we didn't get it quite right. So, it's great, but it has problems, and we're stuck with at least some of them. Personally, that's probably the only thing that I'd be looking to change that I don't think could be changed without effectively doing D3. In general, the kind of changes that I can think of that I'd like to see are things that can definitely be done in D2 - assuming that Walter and Andrei can be convinced, which is rarely easy, and the question of D2 vs D3 probably wouldn't change that much (some, since backwards compatibility would be less of an issue, but that doesn't mean that they'd then be easy to convince of major changes in general).

- Jonathan M Davis

On Friday, 16 November 2018 at 00:42:05 UTC, H. S. Teoh wrote:
>
> That's ridiculous.  So you're saying, to use C++ effectively you basically have to use only a subset of it?

Yes. That's exactly what I am saying. Although, I would replace 'effectively' with 'safely'.

A programmer writing secure industrial strength code, must understand the features they are using. No exception.

This is why Java is so popular - due to it's limited features - which correspond well to the limitations most programmers have with regards to much they can continually hold in their head.


> So why do we keep having to haul the rest of that baggage around?

So all the programmers in the world don't have to program in Java ;-)


> Not to mention, you cannot enforce this sort of thing in a project of any meaningful scale, short of draconian code review institutions.  As long as a feature is there, SOMEBODY is bound to use it someday, and it will cause headaches to everyone else.

Well, you *can* restrict yourself to hiring quality, experienced programmers though.

>
> Patently ridiculous.  What's the point of having something in a language if nobody's going to use it, or if nobody *should* use it?  A language should be a toolbox for the programmer to draw upon, not a minefield of dangerous explosives that you have to very carefully avoid touching in the wrong way.  You should be able to combine any language feature with any other language feature, and it should work without any surprising results or unexpected interactions. (Not even D fully meets this criterion, but C++ hasn't even made it on the chart yet!)

Which statement is more 'Patently ridiculous' .. I mean really.

Library implements need tools most other programmers will not need.

The tools needed to write a driver, or kernel, are not the tools most programmers will need.

What you don't need to use, you don't need to know about.

> Which also means that every new feature or change added to a language not only brings the intended benefits, but also comes at the price of technical debt.  The larger the language, the less people can fully comprehend it, and the less you can comprehend it, the more chances you will not use something correctly, resulting in bugs that are hard to find, reduce productivity, and waste time.  A language that cannot be fully comprehended by any one person is far too large, and has the stench of bad language design.

So, it follows, from your arguments, that we should all use Java. Is even that too complex for you?


>
> Actually, I've used most of D's features myself, even just in my own projects.  Won't lie, though: some parts look dark and dirty enough that I wouldn't go beyond reading about it, if I had the choice.

A return to common sense. Horray!

> Then screw the institution.  Programming is about facilitating the programmer to express what he wants to the computer, not about binding him in a straitjacket and making him jump through hoops just to express the simplest of concepts (*ahem*cough*Java*sneeze*).

Well, a programmer would say that. But you want to be employed?

Now you seem to be arguing for a language that has more complexity?

C'mon.. make your mind.


> It's a big lie and a great fallacy that language restrictions lead to software correctness.  Restrictions only reduce productivity, and sweep the problem under the rug -- you may get rid of the superficial mistakes, but fundamental errors committed through inexperience or a faulty paradigm will continue to promulgate.

Well, a programmer would say that.

But you want to be employed? Start writing correct code - even if that means more effort.

> Real support for correctness in a language comes from a careful, well thought-out design of language features such that the paradigm itself leads you to think about your programming problem in a correct way that results in correct code. Most correctness problems stem from thinking in the wrong way about something, which manifests itself as the symptoms of leaky (or outright unsafe) abstractions, programming by convention, needless boilerplate, and so on.  These in turn leads to a proliferation of bugs.

If there is 'thinking' involved, then bugs will follow. It can't be helped.

What's important to me, is being able to very clearly state my intent, so that the compiler know it, others know it, and most of all, I know it.

How many features the language has is irrelevant, to me. It is only necessary that language allows you to clearly express you content.

The language should server me. Not I serve the language.

>
> Common fallacy: popular == good, unpopular == bad.
>
> I couldn't care less which language people flock to.  In fact, in my book, people flocking to the language is a strong indication that I should probably avoid it.  People flocked to Java back in the day -- I was skeptical.  And recently, after having gotten over my skepticism, I finally conceded to try it out.  Did not last long.  In the process, although I did find one or two pleasant surprises, my overall experience was that 85% of my time was wasted fighting with a crippled, straitjacketed language, rather than making progress in the problem domain.

Again? I cannot determine which side of your two arguements you are on.

>
> (Not saying that implicit conversions in D are any good -- in fact, I'm in favor of killing off outdated C-style implicit conversions altogether, even if this will only ever happen over Walter's dead body -- but seriously, "old school" as the reason? Wow. Never seen a more rational argument.)

It's old school to have the language deciding for you, what your intent is.

I agree that D2 will not change that - nor should it.

But it could provide 'option' that programmers could 'opt into'.

But then people will say 'no, change is to complex for us to handle'.

Or (more likely), Walter won't like it. So lets not even bother thinking about it anymore.

> Yawn.  Still not over the hangup over 'private', I see.  Missing the forest for the trees.  There are far more important issues in programming than such trivialities.

Really? Private state is a trivial notion? Who'd have guessed.

Anyway, the D module is really just a 'God' class (or struct, depending on your point of view).

>
> *snort* The Bear, eh? :-D  A sickly and overweight one, no doubt, with a deteriorating heart condition dangerously close to a stroke, still clawing the edge of the cliff in memory of its former strength even as it slowly but surely falls off the stage of relevance into the dusts of history, dragged down by its own weight of backward compatibilities and layers of bandages upon patches upon bandages that paper over fundamental design problems that will never be truly fixed.  Yawn.
>

Well, keep poking it ...you'll get its attention soon enough ;-)

On Thursday, November 15, 2018 7:30:15 PM MST AlCaponeJr via Digitalmars-d wrote:
> On Friday, 16 November 2018 at 02:02:26 UTC, H. S. Teoh wrote:
> > ... after that Tango vs. Phobos fiasco....
>
> Do you mind to explain this for newcomers?

Walter has always been focused primarily on dmd, not the standard library or its runtime. During D1, Andrei was not involved, and Walter was the main person behind everything. Phobos was the standard library, and it included druntime. They weren't separate, and the standard library was very small. The process was also less open at the time, since none of it was on github. It was in a subversion repo that not many folks had access to. So, it was much harder to get changes committed, and Walter's focus was on the language, not the library.

There were folks in the D community who created a library called Tango which grew to dwarf Phobos. At some point in the process, it got its own runtime, which meant that it was incompatible with Phobos. So, anyone using D1 had to choose whether they wanted to use the standard library, Phobos, or to use Tango. Almost everyone chose Tango, since it was much, much larger and was actively developed. This did sort of fork the community, and there was talk of two standard libraries (though officially, there was only Phobos), since you had to pick one or the other. However, since most everyone used Tango, I think that the biggest problem here was really a PR problem if anything. The fact that you couldn't use the standard library with Tango was definitely bad, but almost everyone used Tango, so I don't think that there was a huge split in reality (though I didn't use D until early in D2, so my understanding could be off). It did make the community look bad though.

The bigger fork in the community came with D2. Folks had been using D1 in production, and when Walter was going to add const in a serious way, it was going to break enough code that he decided to fork the language so that folks could continue to use D1, and he could continue to develop the language with D2. Andrei had joined up around then. So, he took over the design of Phobos and started to influence the direction of the language (e.g. making everything thread-local by default). And since Walter no longer had to worry about avoiding breaking production code, he was a lot more willing to make massive changes. So, for a while, D2 was very volatile and not at all viable for production. During that process, Phobos grew quite a bit. The runtime was split out from Phobos to try and fix the problem that had existed between Phobos and Tango in D1, and in fact, druntime comes from Tango's runtime. But as D2 grew and matured, it became a very different language from D1.

So, eventually, we ended up with a shrinking community using D1 with Tango, and a growing community using D2 with Phobos (some of whom came from the D1 community). A lot of the folks using D1 did not like D2. Phobos was _very_ different in its approach from Tango. D1 and Tango were more Java-like if anything, and Phobos and D2 are closer to C++ and the STL in their approach. Tango did eventually get ported to D2, and thanks to druntime being separate from Phobos, Phobos and Tango could be used together, but they were so different that most folks probably still wouldn't for the most part. And at this point, Tango is unmaintained.

So, the fact that we had two major libraries in D1 that were viewed as the "standard" library (even though only one was actually the standard library) was a divider in the community, and the switch to D2 was an even bigger divider in the community. I think that the switch to D2 was by far the bigger divider in reality, but outside of the community, folks still sometimes bring up how D is divided by having two standard libraries.

- Jonathan M Davis

On Friday, 16 November 2018 at 02:02:26 UTC, H. S. Teoh wrote:
>
> Talking about D3 has sorta become taboo around here, for understandable reasons -- splitting the community now might very well be the death of D after that Tango vs. Phobos fiasco.
>  Python survived such a transition, and Perl too AIUI.  But D currently does not have nearly the size of Python or Perl to be able to bear the brunt of such a drastic change.
>
> Nevertheless I can't help wondering if it would be beneficial to one day sit down and sketch out D3, even if we never actually implement it. It may give us some insights on the language design we should strive to reach, based on the experience we have accumulated thus far. Autodecoding, even though it's a commonly mentioned example, actually is only a minor point as far as language design is concerned.  More fundamental issues could be how to address the can of worms that 'shared' has become, for example, or what the type system might look like if we were to shed the vestiges of C integer promotion rules.
>
>
> T

I can't help but think D3 is the one true way to go to become significantly adopted by more companies.
Even though D2 is used by several companies, it still remains a very marginal language and a migration with no backward compatibilities wouldn't be a much a thing to deal with.
Maybe ten companies are using D for minor projects, it doesn't justify to stall or slow down the whole language specs.

The language is still in a phase where it can allow himself breaking changes to significantly improve its performances or reduce the frictions and asymetries.

However, I wouldn't gamble a penny on D3 for more practical reasons.
The creators and the main contributors of D are all C++ full-time developers and some of them even members of C++ commities. For example, Walter distribute and commercialize a C++ compiler and Andrei contribute to C++ meeting in order to identify and improve the weaknesses of C++...

So why should they care about a D3 branch?

No offense, but I don't think anyone important here believe in D becoming a industry-proof language in any timeline. In my opinion and with due respect, I am convinced that D is more or less processed like a research laboratory to test and implement new features to then improve C++ specs and its standard librairies.

The D project, despite of its elegant design, isn't in pursuit of becoming a successful language himself but a successful sandbox for other mainstream languages (e.g. C++, C#).

I hope I am wrong but after 2 years toying with the language for home projects and reading the changelogs and the forums, it is my overall impression that something is wrong and cannot be ignored.

D cannot grow and develop its own identity if the main focus is C/C++ compatibility.
Make no mistake, nobody will abandon his job in C++ among the D community to persuade a employer to hire him for a D full-time job (and thereby not contributing to the success of D), if it does'nt do anything else but operate with they already-used C++.
History has showed us that trying to tease and please to C++ community does not help D to be adopted in industry.

I wish I haven't hurt anyone's feelings but D project lack a bit of long-term vision.
And it scares me to never use D in my professional life.

On Friday, 16 November 2018 at 00:42:05 UTC, H. S. Teoh wrote:
> A language should be a toolbox for the programmer to draw upon, not a minefield of dangerous explosives that you have to very carefully avoid touching in the wrong way.

That is a most beautiful turn of phrase. You should add that to the list of random quotes at the bottom of your posts.

On Thursday, November 15, 2018 9:41:31 PM MST Nicholas Wilson via Digitalmars-d wrote:
> On Friday, 16 November 2018 at 00:42:05 UTC, H. S. Teoh wrote:
> > A language should be a toolbox for the programmer to draw upon, not a minefield of dangerous explosives that you have to very carefully avoid touching in the wrong way.
>
> That is a most beautiful turn of phrase. You should add that to the list of random quotes at the bottom of your posts.

It's definitely good, but it would be a bit funny for him to randomly quote himself.

- Jonathan M Davis

On Friday, 16 November 2018 at 05:02:32 UTC, Jonathan M Davis wrote:
> On Thursday, November 15, 2018 9:41:31 PM MST Nicholas Wilson via Digitalmars-d wrote:
>> On Friday, 16 November 2018 at 00:42:05 UTC, H. S. Teoh wrote:
>> > A language should be a toolbox for the programmer to draw upon, not a minefield of dangerous explosives that you have to very carefully avoid touching in the wrong way.
>>
>> That is a most beautiful turn of phrase. You should add that to the list of random quotes at the bottom of your posts.
>
> It's definitely good, but it would be a bit funny for him to randomly quote himself.

It would be hilarious, especially if it was in context (and would  add quite a bit to the confirmation bias that it is not at all random).

On Wednesday, 14 November 2018 at 23:09:33 UTC, Walter Bright wrote:
> On 11/14/2018 7:33 AM, rikki cattermole wrote:
>> Really butchered. From what I can see they never mentioned D in any of the documents (kinda glad tbh). Those documents even question what it should be doing...
>
> The C++ community insists they invented ranges independently from D. It's obviously not true, but they say that for all the D features they've implemented (except for static if).

Actually Eric Niebler did mention in his (i think it was a keynote) in cppcon 2015 that a lot of the work was done by the D community :)...  Or "thanks to the D community" or something along those line.

On Friday, 16 November 2018 at 04:41:31 UTC, Nicholas Wilson wrote:
> On Friday, 16 November 2018 at 00:42:05 UTC, H. S. Teoh wrote:
>> A language should be a toolbox for the programmer to draw upon, not a minefield of dangerous explosives that you have to very carefully avoid touching in the wrong way.
>
> That is a most beautiful turn of phrase. You should add that to the list of random quotes at the bottom of your posts.

Except, that one does not really need to stay away from them.

One just needs to understand them.

If one needs to stay away from them, they shouldn't be there.

On Friday, 16 November 2018 at 06:51:56 UTC, aliak wrote:
>
> Actually Eric Niebler did mention in his (i think it was a keynote) in cppcon 2015 that a lot of the work was done by the D community :)...  Or "thanks to the D community" or something along those line.

lets be more precise shall we ;-)

(on bottom of slide) 'The idea for this talk was taken from the article "Component programming with ranges" on the D language wiki.'

Then a few seconds later, says that it was 'stolen from the D community'.