Initial discussion of solutions for issues presented in amber-dev/2022-May/007322

[Julian Waters]

Hi Steve,

I appreciate the feedback, but I will stress that this is *not* just
because I dislike writing static in classes- That was just one example I
was using, I personally can adapt to language syntax rather well, but I'll
put a plug in that for now.

My primary concern is mostly in helping the language move forward; I really
do hope Java becomes a more attractive choice among developers for...
Everything, to be honest. I realize several of my worries may sound (or
even be outright) trivial, but that doesn't mean that Java doesn't have
issues (There is a reason why Kotlin is grossly preferred over Java for
Android applications for instance). I may just not be very adept at
explaining what they are, or the ideas I can come up with are impractical.
But that's what the mailing list is here for, isn't it? In this particular
case I did try to describe what, in my experience, is a very common
complaint about the language which seemed to follow a widespread pattern
that could be tackled (Utility Classes) and hoped to gather
feedback/suggestions from people far more experienced than I am, so I
apologize if it somehow came across as sounding like this was posted merely
because I disliked having to write something a certain way- It really
wasn't, and neither is this even meant to be a catch-all proposal of a
solution at all!

The unfortunate truth is that modern developers are very unforgiving when
getting to know a new language, and one public static void main(String[]
args) later they will have acquired a burning hatred for Java (If not
immediately driven off by the main method, then when they have to write
multiple static methods). To you and me, it's not much of a big deal, but a
vast amount of people do not share the same opinion. If Java is to stay
competitive, this is an ugly side of the general dev community we'll have
to end up facing one way or another- There's only so much that
supercharging the JVM's performance can do, if a large amount of developers
still find the language a torture to work with, we're done for, and there
is absolutely no shortage of hatred for the language's syntax (It's not an
uncommon event for people to exclaim "Companies still use Java???" in
absolute shock when asked if they have any knowledge of it!). Of course
turning Java into a language overladen with sugar and having 50 ways to do
the same thing is out of the question- I too enjoy how explicit it is most
of the time, but we should at least try to get rid of extra verbosity that
can be confirmed to not benefit anyone in any way whatsoever (Ignoring the
current discussion, isn't that what records were introduced for?).

I'm all for collecting features in a list like you describe, but from what
I've learnt something related happened in Project Coin that apparently(?)
resulted in a large fight over what feature to include, and so on, so I
doubt that'd be something people would be willing to have on the Amber page.

"So I encourage the community to think about how to self-organize to support
us in moving the language forward. More Steves would definitely help!"

That's the thing though, most of the conflict in improving the language is
going to be fought between developers who are comfortable with Java, and
those that already despise it with a fiery passion and often only use it
out of necessity. The 2 groups (including those with experience like you
mention) are going to have drastically different ideas as to what an
"improvement" to the language actually is, but both sides will also
typically have valid points to address, how would we decide on who to
listen to?

Thanks for the link to the earlier discussion though, I was not aware that
it was on the list.

best regards,
Julian