Discussion on boilerplate for code tightly bound to OOP

[Julian Waters]

I don't believe I've seen (or heard of) "the gradual regularization of
"nest X in Y" changes, such as local interfaces, and "static members in
inner classes"" so far, what's that about?

Though "public static void main" and Hello World not being a one liner are
related issues, they're more of a symptom of the actual problem- That is,
although Java *can* definitely be written without OOP, it punishes the
developer a bit too much for doing so. As mentioned, verbosity in this
particular case isn't a tradeoff for a benefit that helps the developer,
it's more just there for correctness. I'd stress that turning Java into a
scripting language shouldn't be a goal however, instead the aim should just
be to make it less painful to write anything that isn't OOP bound without
changing Java excessively. Maybe after we've established some sort of
baseline syntax (Eg a "package" class of sorts for instance) we could then
tack on extra features that would ultimately let developers write better
functional (Ahem, methodical?) code and make Hello Worlds a true 1 liner (The
latter understandably likely doesn't have a high priority). I unfortunately
don't have a good indicator of Amber's current progress, which is why I was
querying about this issue initially. Out of curiosity, have there already
been plans drawn out for this specific issue, or could we use this
discussion as a rough start when the time comes?

I can't really comment about singletons, given that I didn't have them in
mind for this particular discussion. Granted, it would be interesting to
see them being added as a full-on language feature though (I'm unsure if
people using enums as singletons nowadays is encouraged or not).

best regards,
Julian

On Thu, May 12, 2022 at 8:33 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Yes, this is well understood.  OOP is useful for many things; we don't
> need to force everything through it.  As you point out, we've made some
> steps in this direction, and will likely make more.
>
> Some obvious ones that have been raised a bazillion times:
>
>  - "Why do I need a public class Foo / public static void main" to write
> Hello World?  This one is a substantial concern for both "script
> developers" and educators.  The single-source-file launcher was a help, but
> really, people want "Hello World" to be a one-liner.  This is reasonable,
> but as always, the volume of detail here is significant.  (Though if you
> look closely, we've already started this work; have you noticed the gradual
> regularization of "nest X in Y" changes, such as local interfaces, and
> "static members in inner classes"?  These are paving the way to this.)
>
>  - A better way to define singletons.  Right now, "singleton" is just a
> pattern; Scala, for example, raises this to a language feature ("object Foo
> { }").  In such a world, your procedural program is just an object.
>
> These are all realistic candidates, and ones we've spent some time scoping
> out.  But as always, we can realistically only do about 1% of the
> "reasonable features you could imagine", so we have to prioritize
> aggressively.
>
>
>
> On 5/11/2022 11:56 PM, Julian Waters wrote:
>
> (cc'ed to amber-spec-observers at openjdk.java.net)
> Hey everyone,
>
> Previously I submitted a post for discussing potential new ways to reduce
> boilerplate in Java for all sorts of applications, ranging from simple
> experiments a newcomer to the language may create to large and complex
> systems in production (https://mail.openjdk.java.net/pipermail/amber-dev/2022-April/007303.html).
> It's been pointed out to me that the issue hasn't been properly defined
> though, so I'd like to discuss that here instead, without jumping the gun
> like in the previous post.
>
> The problem is something that Java's had for quite some time, and is one of
> the main issues that earns it quite a bad reputation[1] amongst developers
> (Even if some of that disdain is outdated and has already been rectified in
> newer Java releases)- The language is simply too verbose/has too much
> boilerplate, and Java code itself is too tightly linked to classes[1] (at
> least on the semantic level; Languages like Kotlin support other paradigms
> like functional code even though they ultimately compile down to Java
> classfiles).
>
> Of course, like I did mention above, quite a number of these issues are
> already being tackled (records, accessors for arbitrary classes, talks
> about deconstructors, with expressions, future reified generics, potential
> operator overloading in Valhalla with values and primitives), which is a
> great thing, but Java is still having trouble catching up with modern
> developer expectations and other languages as a whole. While many of these
> complaints are often fueled by hype and personal opinion and provide no
> constructive value as feedback whatsoever, there are still many salient
> points to address, in this case it's how the language is too forceful with
> OOP.
>
> It's not much of a secret that if one wants to write simple, procedural
> Java, they have to fight the language substantially to do so. Classes have
> to be marked as final, their constructors privated and made to throw an
> exception if reflection is used on them anyway, and every method has to be
> marked as static. At first glance, this might just seem like a mild
> inconvenience and one would wonder why this is an issue, but this becomes
> incredibly repetitive and frustrating when made to scale, which will
> undoubtedly drive developers off when considering it as a language of
> choice (Even with a simple "Hello World" jar, many newcomers are often put
> off with how much code is required, which is the last thing we'd want to
> happen). Much of this extra verbosity from having procedural code (unlike
> with statically typing a variable or a method's return type for instance)
> is also a tradeoff without any benefit as well, and there doesn't seem to
> be much of a reason to make developers pay such heavy penalties if we can
> help them out with new language features, even more so since "mutating"
> value classes was already considered too painful in the amber drafts (Also
> from[2] "You get more typing practice?" "The shares for keyboard
> manufacturers go up?" "You can sell software to generate this <Expletive
> omitted> automatically?").
>
> It could be argued that this could all be avoided by embracing OOP
> entirely, which is certainly one of Java's biggest strengths, but there are
> many instances where the procedural approach would be significantly easier
> to implement the program's logic in (think the number of Java codebases
> that have static only utility classes), or where forcing OOP would actually
> degrade both code quality and performance (deeply nested chains of object
> pointers or pointless object allocations for instance). There's also
> another problem in that this forceful approach also causes newer developers
> to learn rather harmful and over-the-top notions of OOP and how everything
> must be a class and object- To the point that there is even an entire talk
> for how to unlearn the rigid and incorrect concepts of OOP for people
> coming to other languages from Java[3]. Given how popular of a language
> Java already is despite the number of complaints against it, we should be
> careful to not be the ones responsible for "poisoning" individuals new to
> programming with the idea that everything has to be in a class- This does
> no one any favours, not us, nor the learning programmers who may end up
> harming the ecosystem at large once their assumptions are deeply rooted.
>
> Maybe Java's current verbosity when it comes to procedural code could still
> be an advantage for enterprise applications, where being as explicit as
> possible with boilerplate can be helpful when reading a codebase, but that
> would be a rather shortsighted view. It would be favourable for Java to
> become a well liked choice for general purpose utilities such as regular
> desktop applications or quick and small ones written out of convenience for
> instance, and limiting it to enterprise-only would make its ideal users
> only a very specific group- Not good if we want it to stay competitive. Not
> to mention that a new language feature for facilitating procedural code can
> indeed be explicit without much of the boilerplate of static only
> classes, if designed properly. This would also help in hiding the
> implementation detail of ultimately compiling down to classfiles, bypassing
> the issue mentioned above entirely, since to the developer there is
> technically no class involved whatsoever- Just methods. You could even get
> IDE support for checking whether reflection attempted to call a constructor
> at compile time too!
>
> In the end, it certainly doesn't help with Java's image (and potential
> newcomers to the language) that a common view of it by many developers out
> there is that it's reluctant to include newer language features
> because "<Expletive
> omitted> you, I'm Java"[2], which is a reputation we can do without, and I
> feel that this discussion would be a good place to start in dispelling that
> view of Java that many developers have today.
>
> best regards,
> Julian
>
> P.S. On an unrelated note, personally I feel that it'd be slightly better
> if "with" expressions were declared with a -> or with any other existing
> keyword instead of reserving an entirely new one for this purpose. I
> digress however, this is just a personal viewpoint.
>
> Links:
> [1] https://www.youtube.com/watch?v=m4-HM_sCvtQ&ab_channel=Fireship
> [2]https://www.reddit.com/r/learnprogramming/comments/1cv8rb/why_does_java_get_such_a_bad_rep/
> [3] https://www.youtube.com/watch?v=o9pEzgHorH0
>
>
>