[External] : Re: Question about circular references

[David Alayachew]

Hello Ron,

Thank you for your response!

> > We need to make sure not to forget to add the Shotgun
> > branch to our static initialization block. That's a
> > problem.
>
> Yes, but is it a big one? How often is it encountered and
> how hard is it to detect and solve?

Lol, let me link you again to my post about Data-Oriented Programming.

https://mail.openjdk.org/pipermail/amber-dev/2022-September/007456.html

My biggest pain point from there by far was not being able to keep track of
all of my states attributes as they morphed due to changing requirements. I
went into great detail talking about exactly how big of a pain point it was
in my side. Several people were able to sympathize with me as well.

> Having the language solve every problem that the language
> can solve is one approach to language design, but it
> rarely yields popular languages. Such languages tend to
> grow quickly.
>
> The challenge of language design is exercising judgment
> in picking which problems are worth addressing. Every
> feature needs to “carry its weight”: the magnitude of the
> problem it solves needs to be bigger than the complexity
> it adds to the language. Much if not most of the time we
> spend thinking about features is spent on answering the
> question: is the problem big enough to justify
> complicating the language (or even spending time thinking
> about a solution)? That’s also where most ideas,
> including those that are raised internally, are dropped;
> yes, they solve a problem, but not one that’s big enough
> to justify a language change.


Agreed. That's why I started this entire thing off by talking about what
was bothering me and seeing if anyone else could relate. My claim was based
on a faulty premise, but once the foundation of that premise was corrected
and reoriented, I think I have pointed out a significant pain point in the
language.

> Maybe there’s a way to extend definite assignment in a
> way that covers sufficiently many more interesting cases
> that aren’t currently covered without adding too much
> complexity, but my gut instinct is that the cost/benefit
> here is more questionable than other features we’re
> working on, and so isn’t a high priority. In other words,
> given the likely-non-trivial nature of a feature that
> would cover this use case, the magnitude of the problem,
> as presented, is not big enough to merit immediate
> attention

I'm definitely willing to accept that this feature just isn't a top
priority compared to deconstruction patterns or something similar.

But I feel like once an accurate picture of the level of effort has been
painted, that'll be when this question can be answered.

And I should emphasize -- any successful attempt to improve definite
assignment will have a massive reach because definite assignment is
EVERYWHERE in Java. It bleeds into practically every line of code we ever
write in Java. Even a small improvement, that only moves the ball forward a
few inches, will have a huge benefit. It becomes a question of the costs.

> (although sometimes we need to address a
> smaller problem when we discover it stands in the way of
> addressing a bigger problem).

I see what you mean. I am curious if the world of lazy loading would
benefit from this.

> But that’s just my opinion. Maybe when others return from
> their vacation they would want to offer a different
> perspective.

Yes, would love to hear more perspectives on this topic. You and I have had
plenty to say, but my primary goal was to see if anyone felt similarly.

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230706/d866dc0b/attachment-0001.htm>