Code That Says Exactly What It Means

[jmh530]

On Wednesday, 29 October 2025 at 16:18:22 UTC, Paul Backus wrote:
> On Wednesday, 29 October 2025 at 13:55:42 UTC, jmh530 wrote:
>> You say it's a "major change to the language". Is it really? I 
>> thought `private(this)` was added to Open D without much 
>> difficulty.
>
> It's a change to the grammar, which means that all parser-based 
> tooling (DCD, DScanner, serve-d, etc.) would need to be updated 
> to support it.

Hmm, I don't have a sense of how much of a lift that is. But I 
think it comes back to putting the burden on the people who 
support the DIP. Make a list of tools that need to be  updated 
and say the DIP is only approved if they update those to support 
it.

>
>> It's also occasionally more difficult to split up code into 
>> multiple modules. For instance, what if you are prototyping 
>> something in run.dlang.io (impossible I think in this case)
>
> You can actually have multiple modules on run.dlang.io, using 
> the following syntax:
>
>     --- lib.d
>     module lib;
>
>     int fun() { return 42; }
>
>     --- app.d
>     module app;
>
>     import lib;
>
>     void main()
>     {
>         assert(fun() == 42);
>     }
>

Sorry, I think I knew this but had forgotten.

(Jonathan Marler who wrote the HAR code left the D community for 
Zig, might be something that the DLF could take over)

>> With respect to the secondary arguments:
>> 1) On the mental complexity budget issue, I don't view that as 
>> a big issue as it is a convenient extension of the protection 
>> modifiers. `protected` and `package` are probably more 
>> confusing than this.
>
> Managing overall language complexity is the #1 challenge in 
> language design. If you don't take this seriously, your 
> language ends up like C++ or Perl--a huge mess that nobody 
> really understands completely. (You could argue that D has 
> already crossed this line, but even if that's true, it doesn't 
> mean we should make it worse.)
>
> Even features that are small and simple in isolation can add up 
> to an enormous amount of complexity if you accumulate too many 
> of them (see: Perl). So the fact that this individual feature 
> is relatively simple is not a strong counterargument.

The optimal amount of complexity isn't zero. Obviously.

As with all things, there is a trade-off, whether that's against 
performance, expressiveness, etc. If all you care about is 
complexity, then you would never add any new features. It's an 
argument for setting things in stone (and I thought the whole 
point of editions was to allow the language to evolve).

The argument about complexity is most convincing when it is 
phrased like "this feature adds complexity without generating 
enough of an improvement in performance/expressiveness/etc" (or 
from a second-level basis something like if we add this feature 
now then it may place a higher burden on adding additional 
features).

In this sense, it is a question of marginal cost (complexity) vs. 
marginal benefit (performance/expressiveness/etc).

On the marginal cost side, there are lots of different kinds of 
complexity. What you responded to was me talking about cognitive 
complexity. I happen to think that's really small here. But 
people can disagree. The complexity I would be more worried about 
is the impact on the compiler code base. I don't have the ability 
to speak to that, but I take people like Dennis and Walter at 
their word that it's something to be concerned about. But if the 
argument against it is that complexity will increase, then the 
argument carries more weight if we can spell out more concretely 
how it will increase.

On the marginal benefit side, there are clearly people out there 
pounding the table for this feature, even if it's not that 
important to most.

My point is that I don't think it's a slam dunk in favor of 
adding this feature, or for that matter saying no. I think it's 
something that should get weighed.

This complexity vs. expressiveness trade-off shows up in a number 
of places in D. The string interpolation debate was one example 
where a less complex solution was proposed and was loudly shouted 
down in favor of a more complex and more expressive solution (and 
led to the creation of openD). When DIP1000 was originally 
discussed, the approach was argued for as less complex than a 
more generally expressive approach. And we're still debating 
these issues now, like 9 years later. Sometimes the more 
expressive approach will be less demanding from a cognitive 
perspective, even if it is more complex to implement.

At the top I said the optimal amount of complexity isn't zero. 
Even something like the trade off between complexity and 
performance/expressiveness/etc., we would be trying to evaluate 
the language on a more-or-less objective basis. Another way to 
think about it is whether adding a feature will mean more 
projects get written in D than otherwise (or even better consider 
something similar that incorporates profits or some measure of 
value-add) (note: I don't mean actual people writing actual 
projects per se, so much as hypothetical people writing 
hypothetical projects). This could also account for second order 
effects where if the feature makes D harder to implement other 
new features or have higher cognitive load, then it would impact 
the trajectory. This framework would suggest that if has a first 
order impact of getting more people to write more D projects 
(esp. if they are projects with positive value-add) with limited 
second order impact, then it should be given a reasonable 
considered, especially with Editions being added to the language.

The D leadership has built a really cool programming language, 
but it's still a niche programming language. And I don't see much 
on the horizon to change that. If they want it to stay a niche 
language, then that's fine. If they want to make it a more 
popular language, then they might need to change the way they 
think about some of these issues.