Comments inline. On Mon, Dec 2, 2024 at 7:57 PM Gianluca Sartori <g.sart...@gmail.com> wrote: > > >> I have had more than 100 (maybe more than 200) Java folks tell me that they >> like >> Groovy because it lets them bring their Java style with them. > > > I am not going into a "mine is bigger than your discussion", what I know for > sure is that when you learn a new language you go through the "Quick Start" > guide at least, and try to understand what the language has to offer instead > of expecting the language to accept what you are used to. > > Anyway...
This is true in general. But Groovy has always been a close cousin to Java. It has been sold as "like Java but more productive and more extensible in certain ways" and as having a low learning curve from Java. We have debated many times moving further away from Java but keep finding it useful to stay a close cousin. Whenever Java innovates, Groovy often gets the bulk of that innovation for almost free. >> If you feel the documentation can be improved, please submit a PR. > > > I'd like to contribute, but before submitting a PR I want to reach an > agreement on what to do, I don't want to spend my time on something just to > have my work rejected because of arbitrary arguments with no real data to > support them. > > How are decision taken in the Groovy team? Who do I have to convince to have > a "Similarities with Java" chapter and put there all the features you call > "Java Compatibility" and remove every reference to those features from every > other place in the docs? This mailing list is where we discuss such things. What you call "Java Compatibility" many Groovy users would call expected features. They want everything Java has to offer plus Groovy's added value. I agree not all users would be in that category. My personal feeling is that there are places in our documentation which do assume more Java knowledge than is ideal, but I can't help wondering whether reworking for a totally "unaware of Java" audience might not be right either. Perhaps there is a middle ground where we use signposts/sidebars which let different audiences easily obtain the info they need and ignore info that is less relevant for them. My suspicion is that for each feature you might want to move into a "Similarities with Java" chapter, there will be some users that regard that feature as a critical Groovy feature. Take the var/def example. I think it would be great to let Java developers know they can use "var" in Groovy wherever they use it in Java (variable definitions plus a few more places). But perhaps that information can be in a sidebar with a preface letting non-Java developers know that they can safely ignore "var" if they want to. Also note, we already have a "Differences with Java" section[1]. It also needs some TLC. We've also debated using "val" for defining constants but so far resisted (we have "final"). If we do eventually support "val", then I can see some users wanting to mix var/val rather than def/val. But that's a future discussion. [1] https://groovy-lang.org/differences.html > Cheers, > Gianluca > >> >> Cheers, Paul. >> >> On Fri, Nov 29, 2024 at 6:45 PM Gianluca Sartori <g.sart...@gmail.com> wrote: >> > >> > Paul, I don't know why you think that I don't want to use `var` since I've >> > opened the discussion with: >> > >> > > I would like to start using the more Java-ish `var` instead of the >> > > Python-ish `def` lexicon >> > >> > I've been tagged to pose weak arguments but I really think the argument of >> > wanting "Java developers to be able to >> > come to Groovy and bring their preferred styles with them" is the weakest >> > argument ever. >> > >> > Do we really think any kind of developer moving from a language to another >> > language wants to keep writing code with the keywords of their first >> > language? >> > >> > To have the Groovy compiler compile Java code is an issue, to promote the >> > use of not-idiomatic coding practices is a completely different one. >> > >> > I think we are falling in love with the idea that a Java developer wants >> > to move to Groovy because the Groovy compiler compiles Java code. To me >> > this is a disfunctional interpretation of the reality. Unfortunately we >> > don't have data to support any opinion about that. >> > >> > I don't really think any Java developer would feel better with Groovy >> > because they can use `var` insted of `def` when all the Internet, >> > documentation, examples, stack overflow issues and everything, basically, >> > use `def`. >> > >> > And they will use `def` in any case to indicate that they want to return >> > `Object` from a method (so why should one use two different keywords that >> > are the same in variable definiton but not the same in method definition?!) >> > >> > And you say that Groovy users are smart enough? With such arguments? >> > >> > I don't think so. >> > >> > Cheers, >> > Gianluca >> > >> > Gianluca Sartori >> > -- >> > Cell. +39 388 1026822 >> > >> > >> > On Thu, 28 Nov 2024 at 21:47, Paul King <pa...@asert.com.au> wrote: >> >> >> >> Java didn't use the term "keyword" but chose "reserved type" since >> >> generally you can't use keywords in most other places in your code, >> >> but for backwards compatibility you can still have "var" as a variable >> >> name. >> >> Groovy also lets you have var as a variable name as well as lets you >> >> have keywords in certain places: >> >> >> >> var var = [def: 1, as: 2, in: 3, trait: 4] >> >> >> >> You are certainly within your rights to not like "var" and think of it >> >> as a cross language copy-n-paste hack, but Groovy generally tries to >> >> stay agnostic on such matters. Groovy users are smart enough to be >> >> able to decide whether they want OO/functional, static/dynamic typing, >> >> var/def, closures/lambdas, etc. We want Java developers to be able to >> >> come to Groovy and bring their preferred styles with them. Of course, >> >> you can write a codenarc rule that flags "var" usage with warnings if >> >> you particularly don't want "var" style in your codebases. >> >> >> >> Cheers, Paul. >> >> >> >> On Wed, Nov 27, 2024 at 8:35 PM Gianluca Sartori <g.sart...@gmail.com> >> >> wrote: >> >> > >> >> > >> >> >> 'var' support [..] slightly more flexible >> >> >> than Java but definitely not use var (short for variable) for methods. >> >> > >> >> > >> >> > You say it is "short for variable" (like in "define a variable?") but >> >> > the documentation says it is "short for Object". It says it is a "Type >> >> > Placeholder". >> >> > >> >> > This is confusing because neither Java nor Groovy have a specific >> >> > keyword to define variables. >> >> > >> >> > In both languages variables are defined by preposing a Type before the >> >> > variable name. >> >> > In both languages methods are defined by preposing a Type before the >> >> > method name. >> >> > >> >> > So if `var` is to be a Type Placeholder it should be valid in all >> >> > contexts where a Type is valid, so everywhere `def` is valid. >> >> > >> >> > Now, I understand it may not be immediate to use `var` in front of a >> >> > method definition but if it is documented as a Type Placeholder then >> >> > that's the way our mind will look at it. >> >> > >> >> > I never saw `def` as something else than a keyword in Python, because >> >> > in the docs they say it is a keyword. >> >> > I never saw `def` as a keyboard in Groovy because in the docs they say >> >> > it is a type placeholder equivalent to Object. >> >> > >> >> > I think it is a mistake for Groovy to document `var` the way it is >> >> > documented today. Because it is suggesting people to use it, but it is >> >> > not a core Groovy feature, it is not idiomatic Groovy, it is a marginal >> >> > addition that exists just to make a compiler happy when copy-pasting >> >> > Java code. It should not be mentioned in the docs along with `def`. It >> >> > should be documented in a separate chapter "Java source code >> >> > compatibility"or something like that. >> >> > >> >> > Cheers, >> >> > Gianluca >> >> > >> >> > >> >> >> >> >> >> Cheers, Paul. >> >> >> >> >> >> On Wed, Nov 27, 2024 at 4:46 AM Gianluca Sartori <g.sart...@gmail.com> >> >> >> wrote: >> >> >> > >> >> >> > >> >> >> > >> >> >> >> For me, def == var, in my mental model. Which means == Object. >> >> >> > >> >> >> > >> >> >> > This is how I was looking at it since that’s how it has been >> >> >> > documented, but it has not been implemented that way. >> >> >> > >> >> >> > At this point of the discussion I understood it is a documentation >> >> >> > issue, but still something in my mind is telling me we should have >> >> >> > def == var. >> >> >> > >> >> >> > It would be groovier! >> >> >> > >> >> >> > Cheers, >> >> >> > Gianluca >> >> >> > >> >> >> > >> >> >> > >> >> >> >> On Tue, Nov 26, 2024 at 5:08 PM MG <mg...@arscreat.com> wrote: >> >> >> >>> >> >> >> >>> Hi Rémi, >> >> >> >>> >> >> >> >>> yes, I saw that, thank you. >> >> >> >>> >> >> >> >>> Most of the examples seemed obvious to me, and the bugs that could >> >> >> >>> be introduced feel like they are a little bit on the artficial >> >> >> >>> side. >> >> >> >>> >> >> >> >>> But, having said that: Inferring an interface type or a less >> >> >> >>> specific parent type in some cases could imho be a very Groovy >> >> >> >>> thing: >> >> >> >>> >> >> >> >>> e.g. inferring List<T> instead of ArrayList<T> >> >> >> >>> Potentially through some explicit construct, such as "var>" to >> >> >> >>> indicate that a more loose / interface type shall be used. >> >> >> >>> >> >> >> >>> Not that I see any of that becoming a reality anywhere in the near >> >> >> >>> future... ;-) >> >> >> >>> >> >> >> >>> Cheers, mg >> >> >> >>> >> >> >> >>> PS: I googled a bit, and I could not find in general that ppl >> >> >> >>> think var >> >> >> >>> in Java is something you should avoid. Instead, as with any >> >> >> >>> language >> >> >> >>> feature, one can over-/abuse it, thereby making code less readable >> >> >> >>> than >> >> >> >>> when using explicit types. >> >> >> >>> It is funny thinking about this in the context of Groovy, where >> >> >> >>> typically ppl who use it as a scripting language do not even use >> >> >> >>> final >> >> >> >>> instead of def when defining variables, even though they will never >> >> >> >>> reassign said variable 99% of the time... ;-) >> >> >> >>> >> >> >> >>> There is an official guide that explains some of the gotchas >> >> >> >>> https://openjdk.org/projects/amber/guides/lvti-style-guide >> >> >> >>> >> >> >> >>> regards, >> >> >> >>> Rémi >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Guillaume Laforge >> >> >> >> Apache Groovy committer >> >> >> >> Developer Advocate @ Google Cloud >> >> >> >> >> >> >> >> Blog: glaforge.dev >> >> >> >> Twitter: @glaforge >> >> >> >> Mastodon: @glafo...@uwyn.net
