On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
> Symptom: The compiler can't discard unused symbols at compile time, and so it will spend a lot of time pointlessly optimising code.
>
> Problem: D has no notion of symbol visibility.
>
> Possible Solution: Make all globals hidden by default unless 'export'.
>
> Side effects: Everyone will be spending weeks to months fixing their libraries in order to only mark what should be visible outside the current compilation unit as 'export'.
>
> Benefits: Faster compile times, as in, in the most extreme example I've built one project on github with gdc -O2 and build time went from 120 seconds to just 3!
>
> Iain.

You can probably solve it like haskell does: Export all symbols by default.

So this module exports everything:

-----------
module MyModule where

-- My code goes here

-----------

this one not:

-----------
module MyModule (symbol1, symbol2) where

-- My code goes here

-----------

On 23/08/2018 7:47 PM, Eugene Wissner wrote:
> 
> You can probably solve it like haskell does: Export all symbols by default.
> 
> So this module exports everything:
> 
> -----------
> module MyModule where
> 
> -- My code goes here
> 
> -----------
> 
> this one not:
> 
> -----------
> module MyModule (symbol1, symbol2) where
> 
> -- My code goes here
> 
> -----------

We already have the solution, and is export as an attribute.

---------
module bar;
export:
int foo;
---------

---------
module bar;
export int foo;
---------

On 23/08/18 09:58, Joakim wrote:
> Because you've not listed any here, which makes you no better than some noob

Here's one: the forum does not respond well to criticism.



Here's an incredibly partial list:

* Features not playing well together.

Despite what Joakim seems to think, I've actually brought up an example in this thread. Here is another one:

functions may be @safe, nothrow, @nogc, pure. If it's a method it might also be const/inout/immutable, static. The number of libraries that support all combinations is exactly zero (e.g. - when passing a delegate in).

* Language complexity

Raise your hand if you know how a class with both opApply and the get/next/end functions behaves when you pass it to foreach. How about a struct? Does it matter if it allows copying or not?

The language was built because C++ was deemed too complex! Please see the thread about lazy [1] for a case where a question actually has an answer, but nobody seems to know it (and the person who does know it is hard pressed to explain the nuance that triggers this).

* Critical bugs aren't being solved

People keep advertising D as supporting RAII. I'm sorry, but "supports RAII" means "destructors are always run when the object is destroyed". If the community (and in this case, this includes Walter) sees a bug where that doesn't happen as not really a bug, then there is a deep problem, at least, over-promising. Just say you don't support RAII and destructors are unreliable and live with the consequences.

BTW: Python's destructors are unworkable, but they advertise it and face the consequences. The D community is still claiming that D supports RAII.

* The community

Oh boy.

Someone who carries weight needs to step in when the forum is trying to squash down on criticism. For Mecca, I'm able to do that [2], but for D, this simply doesn't happen.

------

This is a partial list, but it should give you enough to not accusing me of making baseless accusations. The simple point of the matter is that anyone who's been following what I write should already be familiar with all of the above.

The main thing for me, however, is how poorly the different D features fit together (my first point above). The language simply does not feel like it's composed of building blocks I can use to assemble whatever I want. It's like a Lego set where you're not allowed to place a red brick over a white brick if there is a blue brick somewhere in your building.

Shachar

1 - https://forum.dlang.org/thread/pjp2ef$310c$1@digitalmars.com
2 - https://forum.dlang.org/post/pctsgk$182l$1@digitalmars.com

On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote:
> Pretty positive overall, and the negatives he mentions are fairly obvious to anyone paying attention. D would really benefit from a project manager, which I think Martin Nowak has tried to do, and which the companies using D and the community should get together and fund as a paid position. Maybe it could be one of the funding targets for the Foundation.
>
> If the job was well-defined, so I knew exactly what we're getting by hiring that person, I'd contribute to that.

Didn't intend to chime in, but no, that was not what I have meant at all. My stance is that as long as current leadership remains in charge and keep sames attitude, no amount of money or developer time will fix D.

What is the point in hiring someone to manage things if Walter still can do stuff like -dip1000? For me moment of understanding this was exact point of no return.

On 23/08/2018 9:09 PM, Shachar Shemesh wrote:
> On 23/08/18 09:58, Joakim wrote:
>> Because you've not listed any here, which makes you no better than some noob
> 
> Here's one: the forum does not respond well to criticism.
> 
> 
> 
> Here's an incredibly partial list:
> 
> * Features not playing well together.
> 
> Despite what Joakim seems to think, I've actually brought up an example in this thread. Here is another one:
> 
> functions may be @safe, nothrow, @nogc, pure. If it's a method it might also be const/inout/immutable, static. The number of libraries that support all combinations is exactly zero (e.g. - when passing a delegate in).

Indeed that combination is horrible. It does deserve a rethink, but it probably doesn't warrant changing for a little while since its more of a polishing than anything else (IMO anyway).

> * Language complexity
> 
> Raise your hand if you know how a class with both opApply and the get/next/end functions behaves when you pass it to foreach. How about a struct? Does it matter if it allows copying or not?

get/next/end functions, what?

> The language was built because C++ was deemed too complex! Please see the thread about lazy [1] for a case where a question actually has an answer, but nobody seems to know it (and the person who does know it is hard pressed to explain the nuance that triggers this).
> 
> * Critical bugs aren't being solved
> 
> People keep advertising D as supporting RAII. I'm sorry, but "supports RAII" means "destructors are always run when the object is destroyed". If the community (and in this case, this includes Walter) sees a bug where that doesn't happen as not really a bug, then there is a deep problem, at least, over-promising. Just say you don't support RAII and destructors are unreliable and live with the consequences.
> 
> BTW: Python's destructors are unworkable, but they advertise it and face the consequences. The D community is still claiming that D supports RAII.
> 
> * The community
> 
> Oh boy.
> 
> Someone who carries weight needs to step in when the forum is trying to squash down on criticism. For Mecca, I'm able to do that [2], but for D, this simply doesn't happen.

The N.G. by in large is self regulating. If you see behavior that isn't acceptable you say so. Anybody can do this. Only when it gets really bad does Walter step in and say to stop.

If we need to move away from assuming people are good and will be professional given the chance, it will destroy the community. But I can understand if we move to a more private channel for regulars and go for a more regulated option for everybody else. Would that suit you?

On Thursday, 23 August 2018 at 07:00:01 UTC, Iain Buclaw wrote:
> On Thursday, 23 August 2018 at 06:34:04 UTC, Shachar Shemesh wrote:
>> On 23/08/18 09:17, Jacob Carlborg wrote:
>>> I don't see why we just can't add support for scoped lazy parameters. It's already in the language just with a different syntax (delegates). That would probably be an easy fix (last famous words :)). I guess it would be better if it could be inferred.
>>
>> Here's the interesting question, though: is this *going* to happen?
>>
>> We've known about this problem for ages now. No movement.
>>
> It's on my todo list, however I've instead been doomed to work on higher priority things.
>
> More generally though, some time should be spent on trying out things in the spirit of "will it blend" just to see what happens.
>  Putting effort towards having a more homogeneous environment in the language should in the long run pay its dividends.

Is there even any way to escape a lazy? If no, then lazy is identical to scope lazy.
E.g. https://run.dlang.io/is fails to compile

On 23/08/2018 9:16 PM, Mihails wrote:
> On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote:
>> Pretty positive overall, and the negatives he mentions are fairly obvious to anyone paying attention. D would really benefit from a project manager, which I think Martin Nowak has tried to do, and which the companies using D and the community should get together and fund as a paid position. Maybe it could be one of the funding targets for the Foundation.
>>
>> If the job was well-defined, so I knew exactly what we're getting by hiring that person, I'd contribute to that.
> 
> Didn't intend to chime in, but no, that was not what I have meant at all. My stance is that as long as current leadership remains in charge and keep sames attitude, no amount of money or developer time will fix D.
> 
> What is the point in hiring someone to manage things if Walter still can do stuff like -dip1000? For me moment of understanding this was exact point of no return.

Whoever acts as a project manager would need to be given the ability to override W&A as far as process is concerned. They shouldn't be able to create said process, but should be able to enforce it.

Remember their job would be to facilitate communication within the community not deal with burn down charts. Ensuring DIP's and spec remain up to date is a big part of that.

That is why I suggested it originally. It minimizes a lot of the existing problems we have had for years.

On Thursday, 23 August 2018 at 09:30:45 UTC, rikki cattermole wrote:
> Whoever acts as a project manager would need to be given the ability to override W&A as far as process is concerned. They shouldn't be able to create said process, but should be able to enforce it.

Good luck getting W&A to agree to it, especially when there is yet another "critical D opportunity" on the table ;)

On 23/08/2018 9:45 PM, Mihails wrote:
> On Thursday, 23 August 2018 at 09:30:45 UTC, rikki cattermole wrote:
>> Whoever acts as a project manager would need to be given the ability to override W&A as far as process is concerned. They shouldn't be able to create said process, but should be able to enforce it.
> 
> Good luck getting W&A to agree to it, especially when there is yet another "critical D opportunity" on the table ;)

No. They have power for as long as we the community say that they do.
We are at the point where they need a check and balance to keep everybody going smoothly. And I do hope that they listen to us before somebody decides its forkin' time.

On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
> Possible Solution: Make all globals hidden by default unless 'export'.

Same mess as in C++. But there you have -fvisibility=hidden at least to fix it.

> Side effects: Everyone will be spending weeks to months fixing their libraries in order to only mark what should be visible outside the current compilation unit as 'export'.

Shouldn't it be sufficient to put an export: at the top of each module to roll back to the old behavior and do the real fix later?

> Benefits: Faster compile times, as in, in the most extreme example I've built one project on github with gdc -O2 and build time went from 120 seconds to just 3!

So why not add such an opt-in flag to all compilers, deprecate the old behavior and do the switch at some point.