Why is D unpopular?

[forkit]

On Saturday, 11 June 2022 at 12:57:25 UTC, Alexandru Ermicioi 
wrote:
> On Saturday, 11 June 2022 at 11:24:04 UTC, forkit wrote:
>> The module is not a type!
>>
>> I do not design my solution around the module. I design it 
>> around types, and I use the module to bring related types 
>> together.
>
> Then don't use module to bring related types yet not tightly 
> coupled ones toghether. Use rather packages. It seems that your 
> definition of module is more matching to a package in D rather 
> than D module.

I don't. So the suggestion in irrelvant.

Package brings related modules together, not related types.

> It is indeed pain sometimes to have to create new modules, but 
> you can argue that it is also pain to skim through thousands of 
> lines of code in a single module.
>

Yes, exactly! one class per module, just to ensure the invariants 
of that class can be verified at compile time, is .. a pain!


>> Separate, unrelated types can go in their own module.
>>
>> In the event a type (and I'm talking about an instatiation of 
>> class here) - is a standalone type.. sure..it can go it's own 
>> module, no problem. Makes sense even.
>>
>> But you don't have to put every int your define into its own 
>> module, just so the compiler can enforce its invariants. That 
>> would be crazy.. yes?
>
> Why not? Why crazy?

I don't get it. Put every int into its own module? Is that what 
you're saying here?


> Usually a type (class/struct) is not just a single or two 
> lines, but 10-20 at least. Imho it is perfectly fine to put 
> them in single file. In java, that is how it is done, one file 
> one public class.
>

Don't talk to me about Java ;-)

The problem is NOT, whether a type should go in its own module.

The problem, is being forced by the language, to put a type in 
its own module, just so you can ensure its invariants.

Please read above lines again, so you know what my argument 
actually is.


>> A class is just a type - why is it considered less a type than 
>> an int? (i.e. the only way to protect its invariants, is to 
>> put it all by itself in its own module.
>>
>> What utter nonsense!
>
> Obviously you're comparing apples with grapes. int is a 
> built-in type and certainly not a class or struct, although 
> making the builtin-types and user defined ones have homogeneous 
> rules mostly, would be beneficial.
>

No. You cannot put "wft!" into a int. Its invariants are enforced 
(from code surrounding that int, in the same module). Not so with 
a class type.


>> The module is not a type. You do not design your solution 
>> using types.
>>
>> You do not instatiate a module, and start sending it messages, 
>> or recieve messages from it, or change its behavior, or have 
>> it change its own behavior.
>>
>> The module is a just convenient static encapsulation for 
>> related types.
>
> Well, why can't it be?
> You certainly can consider it being a singleton per thread, 
> where global vars are it's internal state, and exported 
> functions are the methods to class (module). Certainly it 
> doesn't have inheritance and other OOP aspects, but saying that 
> module is a bunch of related types only, is not right. Better 
> to say, is that they are bunch of tightly coupled types, 
> meaning that extracting one type into separate module most 
> certainly would require the other types in module to be 
> adjusted to the change (not by importing the new module, but 
> actual code changes).
>

Again, this is not an argument as to whether a type should go in 
its own module.

This is an argument about the language forcing you to put a type 
(in this case a class type) into its own module, for the single 
purpose of enforcing the invariants of that type from surrounding 
code.

Please read above lines again, so you know what my argument 
actually is.


> In summary, the current access modifiers, don't make oop 
> programming in D in any way less powerful, than any other 
> language with comparable oop features.
>
> Best regards,
> Alexandru.

I don't agree. If I cannot enforce the invariants of my class 
type, from ANY code surrounding it (related or not), then that 
type is not longer a strong type, but a weak type - and this 
requires to you to restructure your design, to accomodate this .. 
flaw!