Well, maybe Groovy did get a better static analyzer, but I sure haven't
seen it. Marketing is the other biggest thing, and my (and the entire
Minecraft community's) poor experience with Gradle makes me cringe at the
idea of using Groovy for a larger project, even if it's actually really
well made.
So yeah, Groovy absolutely has everything I'm talking about, but I want
*Java* to have it too. It seems like it would be pretty straightforward to
do so, so do you think it's as feasible as I'd imagine it to be?
On Sun, Mar 24, 2024 at 7:16 PM Caleb Brandt <calebbrand...@gmail.com>
wrote:
> Oh absolutely, but the impression I and a lot of other users who aren't
> familiar with Groovy got was unfortunately fairly far from that. Lack of
> first-class static analysis, Gradle being... not the *best*
> representation let's say, and the aggressive use of closures make it feel
> like it's a much more complicated language than it is.
>
> The biggest problem is the *STATIC ANALYSIS*, though. If you can't use
> the high-octane intellisense features, type inference, and code refactoring
> tools you're used to in your home language, you'll bear with the minor
> annoyance of its drawbacks, even though it's really grating after a while.
> As a compiled language, static analysis has to be built from the ground up
> with its compiler in mind, and Groovy unfortunately never received
> first-class support like Kotlin or Scala...
>
> The Java transpilation would completely solve the static analysis problem
> though, as we would easily be compatible with the highest-end static
> analysis tools through the same mechanism that C macros get linted.
>
> On Sun, Mar 24, 2024 at 7:04 PM Paul King <pa...@asert.com.au> wrote:
>
>> One of Groovy's goals is to be simple to learn for Java users, so you
>> can in fact just use the Java syntax that you are familiar with and
>> take on board as many (or as few) Groovy idioms as you feel
>> comfortable with.
>>
>> On Mon, Mar 25, 2024 at 8:27 AM Caleb Brandt <calebbrand...@gmail.com>
>> wrote:
>> >
>> > Thank you so much for the reply, Paul!
>> >
>> > And you're absolutely right: Groovy does give you all of those things,
>> as do Kotlin and Scala. The issue I'm trying to solve isn't one of "not
>> enough features in other languages", but one of "too many features". For
>> example, Kotlin has every single one of the features I mentioned, but the
>> amount of changes makes the jump from Java a steep one.
>> >
>> > Similarly, Groovy is extremely intimidating to long-time Java
>> developers because of the sheer amount that it changes. While it's
>> certainly the closest of the non-Java JVM languages to Java, it still has
>> entirely new syntax, new libraries, new standards, and many things that
>> don't have a direct Java analogue due to the bytecode tricks used.
>> >
>> > The whole point of this is to essentially "trickle down" some of those
>> advanced JVM-language features to pure Java, so people can use some of
>> these quality-of-life features without needing to learn a whole new
>> language to use them. A dialect, if you will.
>> >
>> > On Sun, Mar 24, 2024 at 6:09 PM Paul King <pa...@asert.com.au> wrote:
>> >>
>> >> Hi Caleb, what you are describing as your desired goal sounds alot
>> >> like Groovy to me. Can you elaborate on anything that you desire that
>> >> Groovy doesn't already give you?
>> >>
>> >> Thanks, Paul.
>> >>
>> >> On Mon, Mar 25, 2024 at 1:58 AM Caleb Brandt <calebbrand...@gmail.com>
>> wrote:
>> >> >
>> >> > I..... forgot to subscribe to this list first. :/ Please prune the
>> duplicate that's under moderation.
>> >> >
>> >> > Also, if this isn't the right place for this, please tell me where I
>> should send it. I don't want to come barging in ignoring the way you guys
>> do things. I'm just really excited to possibly work with you guys.
>> >> >
>> >> >
>> >> > On Sun, Mar 24, 2024, 10:38 AM Caleb Brandt <calebbrand...@gmail.com>
>> wrote:
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> I wanted to submit a new idea for this summer's GSoC. You should
>> stick around, because I trust you'll find this as interesting as I do.
>> >> >>
>> >> >>
>> >> >> Motivation:
>> >> >>
>> >> >> I know you made Groovy, but if you're anything like me, you love
>> Java.
>> >> >>
>> >> >> I mean, how could you not: Java is unparalleled when it comes to
>> readability and structure while still being powerful. You can track data
>> flow through a program at a glance, there are a thousand easy-to-use and
>> intuitive libraries, and - as much as I love C++ - there aren't any
>> ambiguous operators, syntax that's only valid in one specific place, or
>> random macro usage in the main library functions. You know exactly what
>> something does just by looking at it, and that's still such a breath of
>> fresh air even in the modern programming space. These new languages try to
>> be as concise as possible for writing, but they sometimes forget that
>> people have to read the dang thing too, am I right?
>> >> >>
>> >> >> But... Java can also be a bit too verbose at times, can't it? We
>> only recently got a concise syntax for POJOs in the form of Records, and
>> they come with their own set of stipulations that make using them somewhat
>> niche. And that's not to mention the continued waiting for destructuring
>> declarations, the getters and setters left floating around in the class,
>> the endless if-elseif trees checking the same value against different
>> things that make it so hard to track... There are a few areas of
>> improvement; let's say that.
>> >> >>
>> >> >> Languages like Scala and Kotlin try to remedy this, but they end up
>> with their own problems like enforced programming models, completely
>> overhauled libraries that lose the intuitiveness of Java's, and just the
>> overall learning curve of being a completely different language. Same thing
>> with Groovy to a lesser extent: these languages are powerful, but they lose
>> the familiarity that comes with Java.
>> >> >>
>> >> >> What we need is the ability to just... add some stuff to Java,
>> without making people learn a whole new language to use it.
>> >> >>
>> >> >>
>> >> >>
>> >> >> So what if we did?
>> >> >>
>> >> >> Proposal: Add Some Stuff To Java
>> >> >>
>> >> >> Essentially, the plan is to make a set of
>> syntactically-sugary-delicious constructs that transpile to plain ol' Java
>> 8 source code, similar to how TypeScript's advanced features still compile
>> to ECMA2016.
>> >> >>
>> >> >> The core principles are zero overhead and improved readability;
>> this isn't remaking the wheel and constructing new libraries, this is just
>> adding shorthand for ubiquitous and consistent features that we wish we
>> could have saved time doing by hand. It's gotta feel like you're just
>> using a version of Java from the near future: no syntax weirdness, just
>> some extra intuitive constructs so it's easier both to write and to read.
>> >> >>
>> >> >> Things like:
>> >> >>
>> >> >> Getters and setters being part of the variable declaration, and
>> being called via the property name itself;
>> >> >> If/else-if trees that check the same variable against different
>> things being allowed to be in the form of a `switchif` statement, similar
>> to Kotlin's sequential switch statements;
>> >> >> Python-style "group imports" to save space and local renaming for
>> imported functions and classes, so people can still give their items
>> descriptive names without being forced to type the whole thing out every
>> single time they want to use it;
>> >> >> Kotlin-style `with` blocks for the convenience and readability of
>> "chaining" when chaining isn't an option;
>> >> >> The `as` keyword so you aren't forced to relearn lisp every time
>> you need to cast something multiple times;
>> >> >> Destructuring declarations using annotations instead of waiting for
>> pattern matching to come through
>> >> >> Operator overloading so we can do things like "accessing lists
>> through brackets" and "doing boolean algebra in a readable manner", again
>> declared using annotations so method names remain informative instead of
>> letting developers hide actual behavior inside a non-descriptive function
>> name;
>> >> >> Extension functions for grouping utility methods with the classes
>> that use them; and
>> >> >> All syntactic sugar added since Java 8, now available for those of
>> us living in the past (and also a lot of the world, because they don't even
>> make a JRE for the latest version anymore) to use freely too.
>> >> >>
>> >> >>
>> >> >> This would be accomplished using a Gradle plugin as a preprocessor,
>> converting any J+ constructs to their Java 8 counterparts and then sending
>> the new source off to javac to be compiled, eliminating the need for
>> brittle ASM invocations to hook into the compiler directly, while still
>> having relatively-low added runtime. For the most part it would be simple
>> regex find-and-replace, avoiding any bytecode generation on purpose so the
>> end user can see exactly what their code is ending up as.
>> >> >>
>> >> >> If possible, I'd like to also add the ability to apply the
>> annotation-based parts - operators and destructuring - to preexisting
>> libraries too, using what's essentially a ".d.ts" file but for Java. This
>> would allow the convenience factor for advanced users without requiring it
>> of newer ones, but it's likely out of scope for this project.
>> >> >>
>> >> >>
>> >> >> To be honest, I'm just tired of having to keep track of my getters
>> and setters. If I can replace this:
>> >> >>>
>> >> >>> private String foo = "bar;
>> >> >>>
>> >> >>> public String getFoo() {
>> >> >>>
>> >> >>> return this.foo;
>> >> >>>
>> >> >>> }
>> >> >>>
>> >> >>> public void setFoo(String newVal) {
>> >> >>>
>> >> >>> this.foo = newVal;
>> >> >>>
>> >> >>> doOtherThing();
>> >> >>>
>> >> >>> }
>> >> >>
>> >> >>
>> >> >> with this:
>> >> >>>
>> >> >>> String foo = "bar";
>> >> >>>
>> >> >>> get() {
>> >> >>> return foo;
>> >> >>> }
>> >> >>>
>> >> >>> set(newVal) {
>> >> >>> foo = newVal;
>> >> >>> doOtherThing();
>> >> >>> }
>> >> >>
>> >> >> while still being able to use my precious Java syntax? And all it
>> takes is banging my head against some regex for a couple hundred hours?
>> That sounds like a fair trade to me.
>> >> >>
>> >> >> I have a full plan formulated with a finalized process for every
>> step, but this is a "brief" overview of it. For the most part, I just
>> desperately need the input of people who are experienced with this area.
>> Even if you don't like this for GSoC, I would still love to chat about it
>> in the future, because I think it will make Java just a little bit better
>> for everyone.
>> >> >>
>> >> >>
>> >> >>
>> >> >> So, what do you think? Does this sound like a good proposal idea?
>> Let me know your thoughts in the replies; I look forward to your feedback,
>> and I happily await this being torn apart by people more knowledgeable in
>> the field than I.
>> >> >>
>> >> >>
>> >> >> Thank you so much for your time,
>> >> >>
>> >> >> Caleb Brandt
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> About Me:
>> >> >> I'm a hobbyist programmer and Fixer of Things: if I see something
>> wrong that I can fix, I might as well help out. The power of programming
>> is that if you solve a problem for yourself, you also solve it for every
>> single person who will ever live, which is why I admire open-source
>> consortiums such as you guys so greatly. You're everything I wanted to be
>> when I grew up, and I'm applying because you still represent the hallmark
>> of what good coding is to me: helping people do stuff better, just because
>> you can.
>> >> >>
>> >> >> I'm finishing up my Bachelor's degree in Computer Science at the
>> University of Central Florida, and in my off-time I make compatibility mods
>> for Minecraft: optimizing interactions between other mods using Mixin (a
>> framework for ASM), reflectively exposing new APIs in mods for other
>> developers to use, bytecode-patching bugs in abandoned libraries, and
>> anything else I can do to make the ecosystem a bit better than how I found
>> it. I also attempt to fix any issues I encounter in open-source software;
>> I already spent the time tracking it down, I might as well take one more
>> step and fix it for everyone too. I just like to make helpful things, and I
>> >> >>
>>
>
