Why is D unpopular?

[H. S. Teoh]

On Fri, Jun 10, 2022 at 10:44:25PM +0000, forkit via Digitalmars-d wrote:
> On Friday, 10 June 2022 at 20:59:38 UTC, mw wrote:
[...]
> > D is supposed to be a better OO language (read: encapsulation,
> > separation of concerns), [...]
[...]
> Nonsense. D .. a better OO langauge??

This makes me chuckle.  So the OO bandwagon is still alive and tooting,
after all these years.


[...]
> The D module is designed to encourage shared mutability. There are no
> means to specifiy, let alone verify and enforce, encapasulated object
> invariants.  They have no 'boundary' inside a D module - by that I
> mean, any other code in the same module can transgress any boundary
> that has been specified.

Interesting. By the same logic, any code in the same class in, say,
Java, can "transgress any boundary" and omg modify shared state touched
by other code in that class -- oh the horrors!

The only pertinent difference, really, is the size of the unit of
encapsulation in which this is permitted to happen.  For any non-trivial
code to work at all, it has to interact with other code *somehow*. One
part of the program has to share data with another part of the program,
otherwise it might as well do nothing at all.

One may, of course, disagree with the chosen unit of encapsulation, but
that's all there is to it, a difference in units. It isn't as though the
universe is in danger of imploding as soon as shared state leaks beyond
the boundaries of a(n) {expression, function body, class, module,
thread, etc.}.  It's a matter of balancing between risk and bureacracy:
the larger the unit, the higher the risk; but the smaller the scope, the
more the bureacracy (when you need to cross boundaries).  I think almost
all of us agree that there has to be *some* unit of encapsulation, we
just disagree on what that unit should be.


[...]
> Co-operative mutability, is a major source of bugs - always has been,
> always will be (cause it makes it so difficult to reason about code).
> 
> Mutable state subverts encapsulation, makes it more difficult to
> reason about code, and makes it difficult to scale 'correct' code.
[...]

This sounds like a sales pitch for Haskell. :-P  The logical conclusion
of the above line of reasoning is to eliminate mutable state altogether,
and for that, Haskell perfectly fits the bill.


T

-- 
If it tastes good, it's probably bad for you.