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