On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote:
>
> D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe.

There is the core of the problem.

Because you want to understand it all, therefore it must be simplified.

This is not something that nature imposes on itself. It's entirely a product of the human mind.

Why constrain ourselves in this way?

Let it go, and let it grow ;-)

On Tuesday, 29 May 2018 at 05:47:32 UTC, Let-It-Go wrote:
> On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote:
>>
>> D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe.
>
> There is the core of the problem.
>
> Because you want to understand it all, therefore it must be simplified.
>
> This is not something that nature imposes on itself. It's entirely a product of the human mind.
>
> Why constrain ourselves in this way?
>
> Let it go, and let it grow ;-)

As a a compiler developer, I can guarantee that at some point you _need_ to understand all of the language.
If you don't you will mis-compile code.

Also the more complex the language gets the more special-case handling needs to be added to the compiler making it slower and more brittle.

Unconstrained complexity growth is a pretty scary thing.

On Tuesday, 29 May 2018 at 07:25:39 UTC, Stefan Koch wrote:
>
> As a a compiler developer, I can guarantee that at some point you _need_ to understand all of the language.
> If you don't you will mis-compile code.
>
> Also the more complex the language gets the more special-case handling needs to be added to the compiler making it slower and more brittle.
>
> Unconstrained complexity growth is a pretty scary thing.

Could this be more a problem of compiler 'architecture'?

Or perhaps hardware architecture?

Can we design better architecture (at all levels) to better accomodate inevitable change?

Could it be a problem of not having enough compiler writers - where each knows some part(s), but together they know all the parts? Collaboration is good way to manage complexity.

A compiler writer insisting they must know it all, (while understandable) is an unatural constraint. You'll end up like Scott Meyers - decades of effort learning, but can never understand it, because change is a moving target.

On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote:
> D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe.

Within D, there is a bit smaller and cleaner language struggling to get out!

On Tuesday, 29 May 2018 at 11:31:53 UTC, Guillaume Piolat wrote:
> On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote:
>> D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe.

What are the things that you think will be simplified? I thought that D had some of the same issues about breaking backward compatibility that C++ had.

> Within D, there is a bit smaller and cleaner language struggling to get out!

Ha, one of my favorite Stroustrup quotes about C++!

One of the reasons I like the betterC switch is that it does simplify the language, perhaps too much, but preserves some of the best parts of D, like metaprogramming and modules.

On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
> A cautionary tale we should all keep in mind.
>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
>
> https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
>
> https://news.ycombinator.com/item?id=17172057

Hmm reminds me of this Scott Meyers talk:
https://www.youtube.com/watch?v=ltCgzYcpFUI&feature=youtu.be

On Tuesday, 29 May 2018 at 11:31:53 UTC, Guillaume Piolat wrote:
> On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote:
>> D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe.
>
> Within D, there is a bit smaller and cleaner language struggling to get out!

Seems like it could be broken into two languages, one a garbage collected object-oriented language. The other, C with metaprogramming and other "betterC" type stuff.

On Tuesday, 29 May 2018 at 17:40:39 UTC, Tony wrote:
> On Tuesday, 29 May 2018 at 11:31:53 UTC, Guillaume Piolat wrote:
>> On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote:
>>> D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe.
>>
>> Within D, there is a bit smaller and cleaner language struggling to get out!
>
> Seems like it could be broken into two languages, one a garbage collected object-oriented language. The other, C with metaprogramming and other "betterC" type stuff.

I don't think it's difficult to do that yourself. There's no need to have a formal split. One example is that it's really nice to have the GC available for part of the program and avoid it for another part. @nogc gives you a guarantee. Different variants of the language are a special case of this that is equivalent to annotating the entire program to restrict behavior. That's rarely desirable.

On Tuesday, 29 May 2018 at 20:19:09 UTC, bachmeier wrote:

> I don't think it's difficult to do that yourself. There's no need to have a formal split. One example is that it's really nice to have the GC available for part of the program and avoid it for another part. @nogc gives you a guarantee. Different variants of the language are a special case of this that is equivalent to annotating the entire program to restrict behavior. That's rarely desirable.

What would be an example of a type of application (or maybe that should be "which type of domain" or "which type of developer") where you would want part of it to do garbage collection and the rest of it do not do garbage collection?

On 30/05/2018 8:37 AM, Tony wrote:
> On Tuesday, 29 May 2018 at 20:19:09 UTC, bachmeier wrote:
> 
>> I don't think it's difficult to do that yourself. There's no need to have a formal split. One example is that it's really nice to have the GC available for part of the program and avoid it for another part. @nogc gives you a guarantee. Different variants of the language are a special case of this that is equivalent to annotating the entire program to restrict behavior. That's rarely desirable.
> 
> What would be an example of a type of application (or maybe that should be "which type of domain" or "which type of developer") where you would want part of it to do garbage collection and the rest of it do not do garbage collection?
> 

GUI's, audio systems, language tooling, games, I'm sure somebody can come up with a much more longer list.