Paul,
I'm sorry if I accidentally sounded like I was insulting Groovy there! Groovy's features are tremendously powerful, and it's a blast to work with from what I've seen. I only meant to say that the layman's *perception* of Groovy is that it, like Scala or Kotlin, is a language relatively distant from normal Java, and thus is fairly intimidating. I think having something that acts as a midpoint between "a comprehensive language built off of Java" and "vanilla Java" has the potential to reach a much larger casual audience - people who wouldn't consider a full-blown language shift but might consider a plugin to speed up development - so it would still be worth investing in. Or in this case, giving some pointers as I basically build the entire project myself, as is the case with Google Summer of Code projects. Either way, thank you so much for your opinion! Even though I personally disagree, I can see where you're coming from, and that's the important part. :D I look forward to working with you if I ever contribute to the Groovy project in the future! Thanks again, Caleb Brandt On Sun, Mar 24, 2024 at 8:49 PM Paul King <pa...@asert.com.au> wrote: > Technically, what you suggest would be feasible. Whether it is worth > doing is the big question. > > Other things you might want to look at are https://jactl.io/ and > http://manifold.systems/. > > My advice, don't gauge Groovy usage based on one DSL, Gradle. Gradle > could have written a type-checked Groovy DSL but went down the Kotlin > path instead. Were your issues with Gradle due to its complex build > model or the thin Groovy DSL layer? > > We'd love to have you work on Groovy features or Groovy marketing! :-) > > Cheers, Paul. > > On Mon, Mar 25, 2024 at 9:22 AM 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 > >>> >> >> >
