It's funny to see arguments about compatibility with Java here. Groovy's
compatibility with Java is the promise that you can _almost_ copy and paste
Java code and it compiles in Groovy. Not the other way around ;)
In any case, I was doubtful as you are here before actually using it in
Kotlin. After a few weeks, it became clear to me this syntax was both more
concise and more self-explanatory.
2018-03-21 9:07 GMT+01:00 David Dawson <david.daw...@simplicityitself.com>:
> LOL. thanks, I probably deserved that being thrown back at me :-)
>
> I think that Jochen said it best "It seemed to be part of a bigger
> picture, but the bigger picture is missing."
>
> My CS background is on the weaker side, so I can't quite say what I want...
>
> Apart from Groovy, the two languages that I've *enjoyed* working with
> over the past few years are Clojure and Rust. Of the things in them, "code
> as data" and pure functions from clojure and heavier expression usage in
> Rust (of course, the actual advanced thing in Rust, lifetimes, aren't
> applicable at all to the JVM) are what I miss from them in Groovy. Still,
> Groovy does dominate my development when I have much choice in client
> projects.
>
> Echoing Jochen though, perhaps asking Cedric and Daniel, are these syntax
> suggestions picking around anything deeper? I'd love there to be, in
> Groovy 4 or whatever.
>
> David.
>
>
> On 20 March 2018 at 23:16, MG <mg...@arscreat.com> wrote:
>
>>
>>
>> On 20.03.2018 17:16, David Dawson wrote:
>>
>>> To give an alternate take on the topic.
>>>
>>> The best thing in Groovy when it first started gaining adoption was this
>>>
>>> ["hello"], "world"].collect {
>>> it * 2
>>> }.each { println it }
>>>
>>> Utterly incompatible with Java, happily destroying its idioms.
>>> Collection literals, closures, removing parans, functional chaining. Source
>>> compatibility was nice, but proper two way interaction in the object models
>>> was better.
>>>
>>
>> I agree that that was one of the features that drew me to Groovy. But I
>> never felt that it did break with or deviate from Java syntax - quite the
>> contrary, I immediately felt at home using this syntax, since it felt like
>> a organic extension.
>> The syntax is in general one of the strenghts of Groovy for me: It has
>> "somehow" managed to avoid falling into the many syntax pitfalls that other
>> languages so often exhibit (e.g. var/val in Scala I have already posted;
>> Python is just weird, with its underscores and indentation having semantic
>> meaning; Ruby supports curly braces and Algol begin/end; Basic is a car
>> crash from start to finish; etc).
>> I have programmed in 6502/68000 assembler to Occam, and we could all be
>> programming in Brainfuck (https://en.wikipedia.org/wiki/Brainfuck) or
>> Whitespace (https://en.wikipedia.org/wiki/Whitespace_(programming_langu
>> age)). Humans are adaptable. But a powerful, clear, logical,
>> compact/concisce, while still well to comprehend/read syntax which helps in
>> minimizing programming errors is a clear advantage.
>>
>> I came to Groovy originally to gain access to the above, and stayed
>>> because I could go quicker and still read what I'd written afterwards. I've
>>> used a raft of languages and, to me at least, expression oriented syntax is
>>> a boon for lots of styles of development and problems. Adopting aspects of
>>> that into Groovy, in the pragmatic way that Groovy gives us, would be
>>> great, for me at least.
>>>
>>
>> The suggested extension as I understand it is only syntactic sugar, to be
>> able to write "= ..." instead of "{ ... }" to define simple function
>> bodies. It does not extend Groovy's capabilities in any way.
>> Are you thinking more along the line of first order functions support
>> (outside of Groovy's existing closures and upcoming Groovy 3.0 Java style
>> lambdas):
>> final handler = String fun(String s, int i, x) { ... }
>> or
>> final handler = String _(String s, int i, x) { ... }
>> ?
>>
>> This is broader than the email chain may warrant, sorry if it is and
>>> hopefully it doesn't drag things off track, but I always pay attention when
>>> I see someone proposing substantial new things in Groovy. Perhaps what's
>>> needed is a broader conversation on the philosophical direction of Groovy.
>>> Is it just to be Java+, or something else? I'd like it to regain
>>> something of the lead it once had in raw productivity features and good,
>>> strong language features to adopt. I know that lambdas burned the
>>> community a bit by causing a break in compatibility with Java for so long,
>>> but since we've got Parrot integrated, and that gap closed, it strikes me
>>> that of all times, now is the time for the Groovy community to be bolder
>>> about the direction it can go in.
>>>
>>
>> Thinking/discussing is always good in my book: What big and bold
>> directions did you have in mind ? :-)
>>
>>
>>
>>
>>
>
