[Comments inline below.] On Mon, Mar 25, 2024 at 12:53 PM Caleb Brandt <calebbrand...@gmail.com> wrote: > 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.
It isn't a case of being insulted. I was just correcting what might be thought of as invalid perceptions. Groovy uses Java syntax and adds shortcuts which you can use, or not, depending on how comfortable you are with the improvements. Scala and Kotlin have different syntax to Java. So, there should be no need to feel intimidated if you are already a Java developer when moving to Groovy. > 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. There are lots of ways to describe things. A "full-blown language shift" is a strong term when you don't have to change language syntax in 99% of cases. But a simple "plugin to speed up development" might be an over-simplification given that it might mean losing IDE support, losing ability to debug, and so forth. You should ask the Lombok folks how much IDE support they get for free vs requires special IDE support. Also, why I gave references to Manifold and Jactl. In general, the technical part of the problem is the simple part. It is useful to ask, how do you intend to market the technology, and how will you maintain interest in the technology over many years when you personally have moved on to other interests. Cheers, Paul. > 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 >> >>> >> >>
