Oh, and the reason it adds so few features is (well *one* to be in scope for a summer programming gig, but *two:*) so that it's not overwhelming to people. Again: a small handful of features that help a *bit*, but don't completely outshine Java's own features, and don't require constantly checking docs for new stuff you can do.
On that note, it's possible that once we have a preprocessor framework developed, we could expand on its functionality with plugins (with their own *separate* documentations to avoid overwhelming people) to expand on its features. But uh, the biggest thing is that I want to spend my summer working on a passion project with some really knowledgeable people and get real-world experience in open-source software development. So like, if this even *somewhat* sounds like a good idea... would anyone be willing to mentor me? 🥺 On Mon, Mar 25, 2024 at 4:22 PM Caleb Brandt <calebbrand...@gmail.com> wrote: > 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 >>> >>>
