Why is D unpopular?

[H. S. Teoh]

On Sat, Jun 11, 2022 at 12:37:17AM +0000, forkit via Digitalmars-d wrote:
> On Friday, 10 June 2022 at 23:36:48 UTC, H. S. Teoh wrote:
> > ...
> > 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.
> 
> People can interact, and nothing need to get mutated.
> 
> If they're all stubborn in their views, then it's likely nothing can
> be mutated anyway. In this case, interaction and mutation are mutually
> exclusive.
> 
> In the same way, I want to protecting my class from mutation (making
> it stubborn to being mutated by the outside world). My class will
> decide when to mutate, and when not to mutate. My module should not
> force mutation on me.

You know how ridiculous that sounds, right? -- when you rephrase that in
terms of a different unit of encapsulation.  "I want to protect my
function's per-object state from mutation by other functions in the
class.  My function will decide when to mutate, and when not to mutate.
My class should not force mutation on me."  Or, "I want to protect my
local variables from mutation by other blocks in the function. My block
will decide when to mutate, and when not to mutate.  My function body
shold not force mutation on me."

One can argue that functions in a class ought to work together on that
class's data; one could argue the same for functions (and other code) in
a module. Or blocks in a function.  It's essentially the same argument
at the core; the only difference is the unit of encapsulation.

As I said, opinions differ on this.  You say the class ought to be unit
of encapsulation, Walter says it should be the module. Maybe next week I
should write a DIP arguing for the block to be the unit of encapsulation
instead.  Each side of the argument has its merits and demerits; the
choice is essentially arbitrary, based on what the language designer
deems more important or not, in balancing the tradeoffs in the language.

There are bigger fish to fry in the pond of programming language design.


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. -- Sammy