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
>
>
