I would just start with point 1 and do one topic area at a time. I
can't help but think some topics are subjective and fall into the
beauty (Groovy idiomatic) is in the eye of the beholder. (I am not
sure how useful it is to have a "tabs vs spaces"-like debate. Groovy
tends to stay agnostic and let the developer decide on such matters.)
Possible starting topic areas (my personal comments in brackets):
* var/def (for me it's the intended audience of viewers that lean me
in one direction or the other - if writing code/scripts for a Java
shop were Java developers are likely to be maintainers or a blog post
where numerous Java developers will read, I tend to favor var)
* ARM blocks (Groovy's specialised Closures tend to read better but if
you have multiple resources, try-with-resources can end up being
shorter and clearer than many nested Closures)
* Method references and method pointers (there are some differences
under static compilation worth knowing)
* Strings (for non-GString strings, single quotes is a nice hint to
the reader that no interpolated variables will appear, i.e. it's
definitely not a GString - but in places like Gradle build files, I
think an argument can be made to prefer double quotes)
* lambdas vs closures (somewhat personal preference but there are some
technical differences worth knowing about in particular with type
checking in play)
* records vs @Immutable (I think both are valuable)
* streams vs non-stream aggregators/processing (I think both are valuable)
Points 2 and 3 can always be added later. I am unclear whether 2 is
just the current "Differences with Java" section (perhaps expanded) or
something else.
On Thu, Dec 5, 2024 at 6:45 PM Gianluca Sartori <g.sart...@gmail.com> wrote:
>
>
> So let me recap:
>
> Groovy syntax in main documentation + Java compatible syntax in side notes
> A "Groovy for Java developers" chapter that collects all Java compatible
> syntax and code styling
> A "Groovy for Groovy developers" chapter that collects all Groovy best
> practices
>
> Could this be the structure of the Groovy documentation and a goal to reach
> in 2025?
>
>
> Gianluca Sartori
> --
> Cell. +39 388 1026822
>
>
> On Wed, 4 Dec 2024 at 16:11, MG <mg...@arscreat.com> wrote:
>>
>> Hi Gianluca and Paul,
>>
>> having thought about this some more, to explain Java constructs/syntax in
>> side notes seems like a good approach :-)
>>
>> Initially I was for collecting this information in a seperate chapter.
>> But this would not work well for all cases, because some off-meta language
>> constructs can have their merits in some cases, and so should be explained
>> together with native Groovy concepts.
>>
>> e.g. using a for(foo : foos) { ... } loop instead of canonical Groovy
>> foos.each { foo -> ... }, to be able to easily return from the for body from
>> multiple places using return statements.
>>
>> It also could lead to people thinking that Groovy does not support a certain
>> syntax which they are used to, when in fact it does.
>>
>> If you are in the "let's have have a quick look here" phase of evaluating a
>> language, this can imho turn away people pretty quickly.
>>
>> In addition, having an (extended) "Java constructs in Groovy" (o.s.) chapter
>> might still also be a good idea.
>>
>> Imho it could just explains a little bit of the general background of:
>>
>> Groovy aiming for Java copy-and-paste compatibility where possible.
>> Java compatibility vs canonical Groovy.
>> Examples for caveats where Groovy matches Java syntax, but not Java
>> semantics (e.g. var).
>> etc
>>
>> ...and for details refer to the Java side notes in specific chapters.
>>
>> On the inverse side of that, giving information in the side notes (and/or a
>> sperate chapter) about what would be considered canonical Groovy, best
>> practice, or what is general a powerful way of using Groovy in certain
>> scenarios, might also be beneficial.
>>
>> e.g. that using dynamic Groovy together with @TypeChecked:
>>
>> Is fast (because, generally speaking, dynamic Groovy is fast).
>> Gives the same level of rigid code checking static compilation in Java
>> supplies.
>>
>> Or can even go beyond that.
>>
>> While still supporting e.g. dynamic call site resolution, which allows for
>> the very simple & elegant addition of handling of newly introduced sub
>> classes in method calls, without changing any of the calling code or
>> resorting to a if(foo instanceof FooChild) { ... } cascades G-)
>>
>> Cheers,
>> mg
>>
>>
>> On 04/12/2024 11:02, Gianluca Sartori wrote:
>>
>> > What you call "Java Compatibility" many Groovy users would call expected
>> > features.
>>
>> > 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.
>>
>> If Groovy gets diluted with the Java syntax we are going to loose the
>> "Groovyness" and we should stop talking about "Idiomatic Groovy" (and all
>> this thing about `var` is not needed by Groovy and is not idiomatic Groovy,
>> this thing about `var` smells like fear in any way you want to look at it).
>>
>> You folks are starting to feel weak, scared and probably tired. You feel
>> "safer" promoting writing Java code with Groovy? Because that does not make
>> any sense whatsoever. I believe all this "forcing Kotlin everywhere for any
>> reason" thing is taking up not only the Groovy space, but some space in our
>> minds where it is not supposed to be.
>>
>> > 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.
>>
>> I suggest we talk about Groovy as the main language and we put on side
>> notes, as you suggest, where we can use the Java syntax to achieve the same
>> results. So we don't have a separate chapter and the Java "alternative" is
>> inline with the documentation. But the Groovy syntax always gets first, and
>> the Java "alternative" on a side note.
>>
>> Unless this is all about suggesting Groovy to newbies as a step to learn
>> coding before transitioning to Java.
>>
>> This is my message, and I want to scream it: GROOVY FIRST.
>>
>> Cheers,
>> Gianluca
>>
>>
>>
>>>
>>> [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
>>
>>
