groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Dawson <david.daw...@simplicityitself.com>
Subject Re: [RFE] Methods as expressions
Date Wed, 21 Mar 2018 08:07:41 GMT
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 <mgbiz@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 ? :-)
>
>
>
>
>

Mime
View raw message