(I also use Java professionally, not just for Minecraft, but we only use
Maven on business projects so I'm more familiar with the horrors of
*Minecraft's* toolchain management.)
On Sun, Mar 24, 2024 at 7:21 PM Caleb Brandt <calebbrand...@gmail.com>
wrote:
> 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
>>> >> >>
>>>
>>
