groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: [RFE] Methods as expressions
Date Tue, 20 Mar 2018 23:16:59 GMT


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_language)). 
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 ? :-)





Mime
View raw message