IDEs will still interpret stuff incorrectly at times.* On Mon, Mar 25, 2024 at 4:17 PM Caleb Brandt <calebbrand...@gmail.com> wrote:
> Thank you all so much for your insight! And I'm not being facetious here; > you guys keep blasting away the points that don't hold water, so I think > I've finally nailed down *why* I feel this project is so necessary. > > Because you're absolutely right: Groovy already *does* do much of what I > want. In terms of contributing new functionality to the ecosystem, my > project isn't necessary in the slightest. My argument is entirely borne > out of *ignorance* to what Groovy can do. > > But to be honest... that's kind of the *point*. It's absolutely > IGNORANT, and that's absolutely *WRONG*, but even still, it *is*. > > > See, I've been programming in Java for around seven years at this point. > I'm very immersed in the Minecraft dev space, and I've worked with others > on non-Minecraft things as well, like working on toolchains and libraries, > contributing to a handful of personal projects, etc. And as a member of > those spaces, the "vibe" that I've gotten is this: "the non-Java JVM > languages are clunky". > > > See, Groovy has exactly two things going against it for reaching the most > people: it's a *language*, and it's *compiled*. Now that might sound odd > to criticize, but bear with me. > > > 1. As another language, it is *inherently* intimidating to people who > aren't familiar with it. > > People are closed-minded, and like to stick to what they know. I know when > I see "Foo.groovy" on Github, I immediately go "oh god", though it > *absolutely* isn't warranted! Fact is, people who use Java and know > their way around it like the back of their hand don't want to go relearn > how to speak in code just to do the same thing a tiny bit easier. > > Their instinct is to go: > >> "I've never used Groovy, and I never intend to, because I'm fine with >> Java. I can do everything I need to with Java. Why do people have to be >> weird and use something that isn't Java when writing a Java program? I >> don't want to have to learn a new language just to sift through this." >> > > It doesn't really matter if it's identical to Java in most places, the > very *name* not being "Java" is enough to spook people who aren't > familiar with it. Sure, once you get to know it, you realize there was > never any reason to be intimidated, but that's a leap too far for most > people when they could just... *not* use it, without any consequence. > > Even as someone who tries to be more open-minded than most people, I > *still* find myself having that instinct. Even though I know my fear of > Groovy was unwarranted, it doesn't change the fact that it *took this > conversation* to change my mind about it. Very few people are going to > have this conversation; most are just going to say "oh, that's neat, I > guess" and leave it. > > > And also: > > 2. As a compiled language, any analysis tools need to be specifically > written *for Groovy*, and they just can't match the ones for Java. > > And that's no fault of Groovy's! See, even if we got the* brightest > minds* in the world together to make a static analyzer, debugger, and > suite of tools for Groovy, Java still has *twenty years* on us. It's > just a fact: without massive resources, we can't match the tools made for > Java. Debuggers will fail inside Closures, static analyzers will infer the > wrong types and throw false errors, and IDEs > > Even if we could theoretically do all of that *better than Java*, we'll > inevitably still be working in a *Java-based* ecosystem. Any tools made > are implemented in a Java IDE: analyzers are slower, intellisense loses > track of where things are defined, postfix completions have to be > redefined, templates stop working; *every single thing* has to be > retooled for Groovy. And that includes community-made plugins too! > > It's unfortunate, but it's a fact: any non-Java JVM language will - by > virtue of not being Java - be slightly more clunky than Java in a > Java-based ecosystem. > > > > But they're still worth it, right? > > Of course they are! But that doesn't matter if no one *uses them*. > > See, you can *tell* when it fails where Java wouldn't. You notice when > it takes slightly longer for errors to pop up, when types get inferred > incorrectly, when intellisense can't find your class and you have to > manually go and search for the reference to import. It's *annoying* to > have to take over for something that worked seamlessly before. > > Again, it's no fault of the *language*, it's just the fact that our tools > are *inevitably* going to be slightly less refined than ones made by a > company doing it for profit. > > But when you're *already* feeling the malaise from being immersed in a > somewhat-new language and you notice that the things you've taken for > granted are suddenly *failing*, what impression do you get about the > language? In my experience: that it's a novelty, one that's slightly worse > in your experience than the one you're used to. > > > > > *That's* what I'm trying to solve here. It's not a matter of *features*, > it's a matter of *accessibility* and making sure people *don't feel > disinclined* to continue past their first glance at it. > > So how do you do that? How do you get people to take that leap - to > continue past that cliff that stops people from continuing past their first > impression? > > > It's simple: don't let there be any leap at all. > > 1. Forget the "language" part. Show your features for what they are: *tiny > addons* for the language they already know. > > There are a few parts to making it as approachable as possible: > > *1. The NAME:* > > There's a reason I didn't call it "Latte", "Javaccino", or "Mocha" instead > of "Java Plus". To be honest, even *THAT* might be too much; *everything > about it* needs to emphasize that it is *NOT* a new language. > > I'd describe it as "A *few* *tiny* (eensy-weensy teeny-weeny) snippets to > save you time writing things you constantly use", and specifically > accentuate the *small* part. It needs to *feel* like something you can > just "click on" without any commitment on your part. > > > *2. DROP-IN INSTALLATION:* > People need to be able to plug it into their preexisting project without > *any* action on their part besides pasting in the plugin. *Not even any > file extension changes.* If it *looks* like it isn't Java from far away, > people will *feel* like it isn't Java. > > We can do this fairly easily: take all of the Java files, scan them for > our constructs, generate new source files with their transpiled > counterparts, and give the new files to javac. We actually do a very > similar thing in MinecraftForge already: source files are copied to the > `out` directory, where tokens are replaced and deobfuscated method calls > are mapped to their obfuscated counterparts before the new sources are > passed on to the `compile` task. > > The only problem with this approach is that you end up having two > identical sets of source files: one in the src directory, and one in the > out directory. However, this actually turns from a bug into a *feature* > because of the third step: > > > > *3. DROP-OUT REMOVAL:* > It's Java allllll the way down. If you want to stop using it, awesome! > Everything gets converted to plain ol' Java, so every single one of the > vanilla Java files are RIGHT THERE for you to use outside of this project. > This is also why TypeScript is so approachable: you can add or remove it at > any time without any impact to your project. There's *no commitment* to > using the plugin in everything; you're still a Java developer like everyone > else, you just have some new things in your toolbelt that Oracle didn't add. > > Speaking of: > > > *4. IT'S JUST "MORE" JAVA:* > Everything that's added needs to "feel like Java". Again, it's a > psychological thing: people will feel some malaise if they're using > something that doesn't look like something they're used to, so it all has > to be an *intuitive analogue* to something that already exists in Java. > > We all know what a getter and a setter is, so condensing them into one > place is easy to understand. But what's a "closure"? What's a "delegate"? > What's a "virtual thread"??? (I'm kidding.) People don't have a basis for > these things in Java, so it's just *more* stuff to learn instead of > already making sense to a Java-only programmer. > > I actually removed the idea of the `pojo` keyword from this proposal for > this very reason: while it's clever shorthand for something that people do > a lot, it *hides too much* from the writer. Where are the getters? Where > are the setters? Do we access them by field or by method? How do we do > internal member referencing? Can we extend classes? It's just too much > hidden behind a single keyword, so it's not a good fit for this project, > instead being partially covered by the declaration get/setters. Every > addition needs to scan like Java at face value and feel like something > Oracle themselves would have added. > > > And on the backend: > > 2. Instead of COMPILING, we transpile it to Java source code > > Unlike with JVM bytecode, this one would transpile to Java 8 *source code*, > letting a few things happen that *completely* change the game: > > > *1. WE CAN USE JAVA'S TOOLS* > Yeah so remember what I said about how "nothing will ever match Java in a > Java space"? If you can't beat 'em, join 'em. By acting as a transparent > frontend to real Java source code, we can leverage existing Java analyzers > to do our linting for us. The IntelliJ system already has a variant of > this for CLion's macro processing, being able to detect errors in the > applied macro and display the code it'll be replaced with in a hover popup. > > We can also use Java debuggers to their fullest extent too: it'll link to > the processed Java8 sources when we freeze on a breakpoint instead of the > J+ sources, but once again that's a *feature*, not a bug. With a good > enough formatter on the processor, they'll even thank us for it. > > We don't return anything, only being *syntactic* sugar instead of > *library* sugar, so type-checking is a non-issue as well. (I *wanted* to > add the ability to return from an outer function from inside an Optional, > so I wouldn't have to do the "Optional Dance" whenever I wanted to get or > return if null, but that would break the rules I highlighted above so it > was a no-go.) > > No Java syntax rules are broken either - nothing new goes outside a > method, for starters - so any community-made Java source plugins will work > exactly the same on the unprocessed source as they would on the vanilla > source. > > > *2. W E C A N U S E J A V A ' S T O O L S* > Again, you don't realize how huge this is. There's *no* overhead. > There's no stuttering. No incorrect typing, no invalid templates, no > broken plugins; it works *exactly* like normal Java, just with additional > features. People won't have any excuse *not* to use it. It's purely > helpful without breaking people's workflows in the slightest. (...save for > some additional gradle configuration to point any other plugins to the > processed sources, but just *sneezing* on the project does the same > thing, so it's an acceptable loss imo) > > > *3. It's great marketing for Groovy* > > Like I said before, people don't like to stray too far from what they > know. They know Java, so they stick with Java. Oh, but now they know Java > Plus too! But... by its very design, Java Plus can only do half of the > things that Groovy can. So, if they want even *more* features, we tell > them to go try Groovy! "It's just like this, but more!!!" > > > > > So, do you get what I'm going for now? In the end, it *won't* end up all > that different from Groovy in function, but that's not the point. The > point is to be something that doesn't exist yet: an approachable set of > useful features for people who otherwise would look at a whole other > "language" and run away. > > > As for marketing: I'm friends with some of the biggest Minecraft > developers in the space; if something's going to be used by new Java > developers, it'll be recommended by them. I can even get it packaged into > the major modding frameworks for the game if it's intuitive enough, and > from there it'll spread by word-of-mouth as long as there's no learning > curve at all. It will improve readability, make you have to keep fewer > things in your head while writing, and sort through your code easier; there > will be no reason *not* to use it, which is exactly what I have in mind. > Hell, if the features prove stable enough, we could even pitch them to > Oracle for inclusion in the language proper. > > It'll be a great stress-test for some sorely-needed features in Java. > Plus, it'll let me keep track of where my getters and setters are without > having to open the Structure tab every five minutes. Win-win. > > > So, have I sold you on it yet? > > > Cheers, > > Caleb > > On Mon, Mar 25, 2024 at 11:35 AM OCsite <o...@ocs.cz> wrote: > >> Caleb, >> >> On 24. 3. 2024, at 16:57, Caleb Brandt <calebbrand...@gmail.com> wrote: >> >>> I know you made Groovy, but if you're anything like me, you *love* Java. >>> >> >> just for one, although I haven't co-operated on the Groovy creation (am >> just a very satisfied user), I *hate* Java very bitterly. >> >> The language design is simply *terrible*, all the worse since the people >> who made that abomination, i.e., Sun, knew Objective C well (they used to >> cooperate with NeXT on OpenStep) and thus *knew* how to do an >> object-oriented language right. >> >> Instead they botched it *terribly*. No real polymorphism. Very limited >> encapsulation. Type-system which effectively prevents (or at the very least >> makes highly complicated and expensive) all the best and most important >> object-oriented patterns like e.g., proxying and message forwarding. >> Classes are not objects and their „methods“ do not support inheritance >> properly. It is quite normal to access instance variables directly, instead >> of consistent usage of accessors. *Heaps and heaps* of boilerplate. >> Often, the darned thing limitations just force the IDEs to generate code — >> compare e.g., WOLips. Could rant on for months like this :( >> >> Whilst languages like e.g., Kotlin or Scala fix some of the problems all >> right, they, alas, do not allow to switch a big project from the Java >> disaster without re-writing it at once and completely, which is a big >> show-stopper. >> >> The vast advantage of Groovy is that you can take a big project, just >> rename all *.java to *.groovy, and it will essentially work (well, as >> someone already wrote, 99 % — my experience is rather 99.99 %, but indeed >> there are things which need fixing and there are a couple of gotchas, but >> there's really a very very small number of them). Then you can work on with >> the project and gradually change the stupid Java patterns to the pretty >> decent Groovy ones, part by part, method by method and if need be, >> practically line by line, without losing any functionality during the >> process. No other language I know of allows anything like this. >> >> All the best, >> OC >> >>
