Why is D unpopular

[forkit]

On Monday, 13 June 2022 at 01:07:07 UTC, Mike Parker wrote:
> On Sunday, 12 June 2022 at 23:15:30 UTC, forkit wrote:
>> On Sunday, 12 June 2022 at 14:56:53 UTC, Mike Parker wrote:
>>>
>>
>> It takes a certain amount of ' ?? ' (not sure of the right 
>> word to use here) to not be surprised, when you're new car 
>> arrives and you're told "only brakes on the rear are necessary 
>> in this car", when you're experience is, that brakes on all 
>> wheels are more likely to protect you from an accident.
>
> The ?? is that you think this is a relevant analogy.

Yes, coming up with an analogy for confusing decision in D, is 
challenging ;-)

Putting analogies aside then....

The D approach of 'everything in a module is global to the module 
- and that's all there is to it', results in massive blobs of 
potentially globally mutating logic, that is very difficult to 
reason about.

Don't believe me? Go look at D source code.

But, just look what happens, when you have more flexibilty with 
access control:

public class SomePublicClass // explicitly public class
{
   fileprivate func someFilePrivateMethod() {}  // explicitly 
file-private
   private func somePrivateMethod() {}          // explicitly 
private class
}

(1) Now you can fully reason about that 'chunk' of code. You 
don't need to factor into consideration what other code as well, 
just to understand this little chunk.

(2) Now the reasoning acts as a form of documentation also.

(3) Now the reasoning is enforced by the compiler (you don't have 
to 'just not make mistakes').

Why would anyone would want to 'give this up' (or be forced to 
give it up), in favour of a 'global module mutation approach'?

It is beyond my comprehension, and difficult to come up with a 
suitable analogy.

Although, that brakes analogy suddenly starts to look not so bad 
afterall.

i.e. Perhaps they 'just don't care all that much' about reducing 
the likelihood of an accident. 'Just don't have one' is their 
motto.