On Thursday, 14 July 2016 at 19:17:06 UTC, Chris wrote:
> I certainly don't impose my view on others. The only reason I was going ad hominem was to get you on board in a more substantial manner than engaging in random discussions on the forum.

That won't change anything. It's not a man-hour problem.


> D is open source. Would it be possible to provide a stripped down version that satisfies you as a proof of concept?

I have no idea. I'm only familiar with the C++ code of DMD, and it was somewhat convoluted. When DMD transitioned to D it was stated that the codebase would be refactored heavily. It would make no sense to do anything until those who are intimate with the codebase are done with refactoring.

Yet, it probably would not change anything, would it? Why would anyone start on something like that without official backing?


> That's good to hear. Maybe you should go ahead anyway and see if and how it could be integrated. Maybe it won't add another layer of complexity.

It would, you would most likely need to add sub-typing constraints.


> You mean you won't give up until everybody has the same opinion as you

That's not what I meant, and not what I said. I am looking for arguments, not opinions.

If you have a good argument, good, then I learn something. If not, maybe you learn something, if you are willing.

That simple.


> Maybe a more diplomatic approach would be better.

That's just words, I'm sorry, but when a position is taken that is not sustainable then it doesn't really improve anything to say «oh, you are a little bit right, except maybe not». The point is, if people are reasonably intelligent, they do pick up the argument even if they don't admit to it in the heat of the moment. So it is better to try to present a clean position. Muddying the water pretending that people are having a reasonable position doesn't really move anything, it just confirms the position they are holding. The point is not to win, or to be right, but to bring proper arguments forth, only when people do so will there be some hope of gaining insights.

Excuses such as «system programming is complex therefore D must be this complex» is not a position that should be accepted.

You have to get rid of this position if you want to get anywhere.


> Create facts. Provide a stripped down version of D and show that it's better.

Completely unreasonable position. That would be more work than writing my own compiler since I don't have an intimate understanding of the current DMD codebase. If I had time to implement my own D compiler then I would just design my own language too... What you are expecting is out of proportions.

There is also no point in turning a sketch into a DIP that I know will be shot down because it will require sub-typing. With the current situation it would be quite reasonable to shoot it down for adding complexity. And I am also not willing to propose something that won't give the language a competitive edge... because that won't be a real improvement to status quo.

There are basically two options:

1. The people who said they were welcoming breaking changes need to push for a semantic cleanup of the core language so that D can continue to evolve.

2. Someone like Timon who appears to be trying to create a more formal model for D (if I haven't got it completely wrong) will have to find a clean core language underneath the current semantics that can express the current semantics (or most of it) and also be extended in desirable directions.

The only thing I can do is support (1).

On Thursday, 14 July 2016 at 20:09:26 UTC, Ola Fosheim Grøstad wrote:
> Excuses such as «system programming is complex therefore D must be this complex» is not a position that should be accepted.

And please note that this horrible excuse is propagate in the C++ community too. Time and time again people claim that C++ is complex, but it has to be like that in order to provide the features it provides.

Not true for C++.

Not true for D.

On Thursday, 14 July 2016 at 18:49:36 UTC, Steven Schveighoffer wrote:
> If what you wrote is UB (as it is in D), then the compiler can go ahead and assign 5 to y.
>
> In C++, the compiler has to reload x, because it may have changed.
>
> Someone explained this to me recently on the NG.
>
> -Steve

Thanks, so when people say "C++ defines the behavior of modifying const" what they really mean is "C++ defines const as meaningless."

On 7/14/2016 6:26 AM, Chris wrote:
> Now, now. Where's your sense of humor?

The thing is, he's just here to troll us. His posts all follow the same pattern of relentlessly finding nothing good whatsoever in D, and we're all idiots. There's no evidence he's ever written a line of D, his examples are pulled out of context from other posts. I don't believe he's ever read the D spec. Whenever he loses a point, he reframes and tries to change the context.

He's never contributed a single line of code, nor submitted a single bug report, nor any proposals. His criticisms are always non-specific and completely unactionable. Trying to engage him in a productive discussion inevitably turns into an endless, fruitless, utterly meaningless thread, likely because he doesn't actually know anything about D beyond bits and pieces gleaned from other ng postings.

It's sad, considering that he's obviously knowledgeable about the academic end of CS and could be a valuable contributor. But he chooses this instead.

As for me, I've decided to put him in my killfile. He's the only one in 15 years to earn that honor.

On Thursday, 14 July 2016 at 20:12:13 UTC, Ola Fosheim Grøstad wrote:
> And please note that this horrible excuse is propagate in the C++ community too. Time and time again people claim that C++ is complex, but it has to be like that in order to provide the features it provides.
>
> Not true for C++.
>
> Not true for D.

Your suggestion for static analysis goes the same way: static analysis is way more complex than D currently is, but you suggest it must be this complex?

On Thursday, 14 July 2016 at 14:46:50 UTC, Ola Fosheim Grøstad wrote:
> The JVM is also a decent example of a core language that is fairly stable. It as based on the StrongTalk VM.

AFAIK JVM has a design bug: can't reliably differentiate between methods to invoke the right one.

On 15/07/16 02:06, Jesse Phillips wrote:
> On Thursday, 14 July 2016 at 18:49:36 UTC, Steven Schveighoffer wrote:
>> If what you wrote is UB (as it is in D), then the compiler can go
>> ahead and assign 5 to y.
>>
>> In C++, the compiler has to reload x, because it may have changed.
>>
>> Someone explained this to me recently on the NG.
>>
>> -Steve
>
> Thanks, so when people say "C++ defines the behavior of modifying const"
> what they really mean is "C++ defines const as meaningless."

Const is very far from meaningless in C++. It is an extremely valuable tool in turning bugs into compile time errors. That is not something to think lightly of (and, sadly, not something D does very well)

In terms of optimizations, there are, indeed, cases where, had const not been removable, things could be optimized more. I don't think D has a right to complain about C++ in that regard, however.

Also, see http://stackoverflow.com/questions/25029516/c-reliance-on-argument-to-const-reference-not-changing

Shachar

On Thursday, 14 July 2016 at 13:24:51 UTC, Ola Fosheim Grøstad wrote:
>> You mean your process describes building prototypes only?
>
> Yes?
>
> You cannot easily iterate over the design of the core language without creating a mess. You can iterate the design of libraries and to some extent syntactical sugar.

You create something when you ship a product. If you build only prototypes, you don't achieve the goal, you described a process of not creating anything, expectedly it bore no fruit.

On 7/15/2016 2:34 AM, Shachar Shemesh wrote:
> Const is very far from meaningless in C++. It is an extremely valuable tool in
> turning bugs into compile time errors. That is not something to think lightly of

Unfortunately, C++ const is little more than advisory:

1. no protection against casting away const and changing it anyway
2. no protection against adding 'mutable' members and changing it anyway
3. only good for one level, no way to specify a data structure of generic type T as const

> (and, sadly, not something D does very well)

Explain. D fixes C++ faults 1..3.


> In terms of optimizations, there are, indeed, cases where, had const not been
> removable, things could be optimized more. I don't think D has a right to
> complain about C++ in that regard, however.

Of course D does. I had to disable const optimizations in my C++ compiler, which is one of the motivations for the way const works in D.

On 15/07/16 13:13, Walter Bright wrote:

> 1. no protection against casting away const and changing it anyway
> 2. no protection against adding 'mutable' members and changing it anyway
> 3. only good for one level, no way to specify a data structure of
> generic type T as const
>
>> (and, sadly, not something D does very well)
>
> Explain. D fixes C++ faults 1..3.
>

Yes, it does. And the result is that const is well defined, safe, and completely impractical to turn on. There are many many places I'd have the compiler enforce const correctness in C++, where in D I just gave up. In one of those places we even went as far as to add run time checks that no one inadvertently changed a buffer.

I think the one that hurts the most is fixing "C++ fault" #3. It means there are many scenarios in which I could put const in C++, and I simply can't in D, because something somewhere needs to be mutable.

Check this thread out to see that we actually do need something like #1 in D (though, at least if my suggestion is accepted, without throwing away the optimizations it allows).

>
>> In terms of optimizations, there are, indeed, cases where, had const
>> not been
>> removable, things could be optimized more. I don't think D has a right to
>> complain about C++ in that regard, however.
>
> Of course D does. I had to disable const optimizations in my C++
> compiler, which is one of the motivations for the way const works in D.
>

For const, yes. In almost every other aspect of the language, however, D favors safety over performance. Just look at range checks, memory allocation, default values, and those are just the examples off the top of my head.

I'm not saying that as a bad thing about D. It is a perfectly valid and reasonable trade off to make. I'm just saying D has no right to criticize C++ for missed optimizations. People who live in glass houses should not throw stones.

Shachar