Sam,
That is... amazing. I wish I'd known that existed, it seems really useful.
But that's kind of the kicker, isn't it? People don't really know it
exists. In the same vein, we've actually had access to Java 21 syntax for
half a decade now with the "jabel" plugin for Gradle, but even as someone
who works with Java professionally on a day-to-day basis, I only learned
about it a few months ago.
My ideal is that something supported by probably the most influential Java
library contributor next to Google would be able to reach - and therefore
help - a lot more people. As well, by being as *simple and bare-bones* as
possible - confidently acting as an *addon* to Java rather than a new
language - it makes it much more approachable for users who wouldn't
otherwise want to pick up a new language.
On Sun, Mar 24, 2024 at 6:25 PM Sammy Sam <bedigitalsm...@gmail.com> wrote:
> Hi Caleb,
> If I may add my humble opinion, it also looks a lot like the 'xtend
> programming language', which is less used than Groovy.
>
> Best
> Sam Moulem
>
> On Sun, 24 Mar 2024 at 22:09, 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
>> >>
>>
>
