Why aren't more people looking at Groovy?

[Eric MacAdie <em...@gmail.com>]

I started this discussion on the old list, and someone said it should be
brought here.

Here is my original post:



*In addition to Groovy, I am also interested in Clojure. I found an
interesting article on the Clojure reddit: "Our curvy road to Clojure" at
http://inside.unbounce.com/product-dev/our-curvy-road-to-clojure/
<http://inside.unbounce.com/product-dev/our-curvy-road-to-clojure/>*


*The basic gist of the article is that they were a Java and Ruby shop, and
they realized that combination was not working as well as they hoped, so
they started looking for alternatives. They tried JRuby and Scala, before
settling on Clojure.*




*What I find odd is he never mentions looking at Groovy. I hear and read a
lot about shops that start out using Java and pick up Ruby, and some of
them eventually realize that the chocolate and the peanut butter do not mix
as well as they had hoped. So they look for something else. Yet I never
hear about any of them looking at Groovy. It seems like if you are using
Java for heavy lifting and Ruby for more dynamic/agile work that Groovy
would be a great fit.*
*Has anyone else noticed this? Any thoughts?*
I left a comment on the Unbounce blog asking if they looked at Groovy, and
here is the response:

*In their pre-Unbounce lives, several of us have had experience with
Groovy, from short embedded scripts to full blown Grails apps ; thus we
have a good grasp of the language.*

*There's no doubt that Groovy has some very strong points, including
closures, progressive typing, null-safe property navigation and tons of
smart extensions to the JDK. But the fact the language is mutable by
default and supports meta-programming (expando meta-class), has the
capacity to complicate things. If you've worked on a non-trivial Grails
application, I'm sure sure you know what I mean.*

*Moreover, from a pure perception standpoint, despite 12 years of
existence, Groovy seems to have stayed a niche language. Its tumultuous
past and uncertain future, doesn't help deciding to bet the house on it.
The addition of closures and streaming API to Java, the rise of Rx, makes a
massive shift towards Groovy less likely in the future.*

*Considering all of these, Clojure seemed a safer choice. There's a strong
language theory behind it. Its community is vibrant, opinionated and
pragmatic, a rare combination in our industry.*

*We'll see in the future if our bet was right or not. In the meantime, what
a great ride :)*


= Eric MacAdie

Re: Why aren't more people looking at Groovy?

[Owen Rubel <or...@gmail.com>]

One of the other things you have to do is whenever you see someplace Groovy
SHOULD be but isn't (ie product, wikipedia, etc), do your best to make sure
it gets listed or integrated. Bring it to the attention of the management
or the community.

For example, CodeEnvy didn't have Groovy integration back in BETA when they
asked me to test and I pointed that out and they said it wasn't a concern.
I said for all the work they were doing with devops, Gradle and Spock and
tools like it that are based on Groovy would need to be integrated.

And Android uses Groovy as well so they were leaving out a heavily used
language in the JVM.

Needless to say, it is now part of the CodeEnvy online IDE over 6 months
later :)


Owen Rubel
415-971-0976
orubel@gmail.com

On Tue, Apr 28, 2015 at 3:07 PM, Ralph Johnson <jo...@cs.uiuc.edu> wrote:

> I'm glad you posted here.   I was beginning to wonder if the apache
> mailing lists were working!
>
> I'm using Groovy because of language mutability.   Language mutability is
> definitely a two-edged sword, and it is easy to cut yourself if you aren't
> careful.  But sometimes it can make a big difference.
>
> In my project, we are designing a programming system for accountants.
> They have a browser that enables them to create and edit business rules.
> The business rules are a stripped down version of Groovy.  Using Groovy
> meant that we didn't need to write our own parser.  We teach the
> accountants a subset of Groovy, but every so often we discover that the
> system isn't quite strong enough and we have to write a script that uses
> something outside the subset.   That gets flagged as a design issue, and we
> try to figure out a better way of designing the system so that the
> accountants never have to write something like that.   Our phrase is "Ugg.
> It looks like programming".  Accountants don't want it to look like
> programming, they want it to look like a spreadsheet.   Even though we all
> know that spreadsheets are programming, too.
>
> Anyway, Groovy made it easy for us to build the system and to evolve it.
> I've always planned that at some time in the future, when the design
> settled down, we'd write a real parser and make the language look more like
> Excel.  At that point, we might rewrite everything in Java (or, who knows,
> Clojure or Scala) and get rid of Groovy.   But I think that is years away.
>   For now, with a small team, Groovy is fine.
>
> I like functional programming.   We don't let our accountants write for
> loops, but they can iterate over accounts or positions using closures.
> They like operators like SUM and think they are easy.   Assignment
> statements are tricky.  I try to steer them away from assignment, but
> sometimes we can't avoid it.  I've thought of having our system detect all
> scripts with assignment and label them in red, and then have some way of
> looking at all red scripts so we can review them.
>
> However, in the core of the system, the part that programmers look at but
> accountants do not, functional programming wouldn't be that much use.  It
> is fairly stateful.  Most of the system is in the sweet spot for
> object-oriented programming, not functional programming, and Groovy has
> served us well.
>
> -Ralph Johnson
>
> -Ralph Johnson
>
> On Mon, Apr 27, 2015 at 10:06 PM, Eric MacAdie <em...@gmail.com> wrote:
>
>> I started this discussion on the old list, and someone said it should be
>> brought here.
>>
>> Here is my original post:
>>
>>
>>
>> *In addition to Groovy, I am also interested in Clojure. I found an
>> interesting article on the Clojure reddit: "Our curvy road to Clojure" at
>> http://inside.unbounce.com/product-dev/our-curvy-road-to-clojure/
>> <http://inside.unbounce.com/product-dev/our-curvy-road-to-clojure/>*
>>
>>
>> *The basic gist of the article is that they were a Java and Ruby shop,
>> and they realized that combination was not working as well as they hoped,
>> so they started looking for alternatives. They tried JRuby and Scala,
>> before settling on Clojure.*
>>
>>
>>
>>
>> *What I find odd is he never mentions looking at Groovy. I hear and read
>> a lot about shops that start out using Java and pick up Ruby, and some of
>> them eventually realize that the chocolate and the peanut butter do not mix
>> as well as they had hoped. So they look for something else. Yet I never
>> hear about any of them looking at Groovy. It seems like if you are using
>> Java for heavy lifting and Ruby for more dynamic/agile work that Groovy
>> would be a great fit.*
>> *Has anyone else noticed this? Any thoughts?*
>> I left a comment on the Unbounce blog asking if they looked at Groovy,
>> and here is the response:
>>
>> *In their pre-Unbounce lives, several of us have had experience with
>> Groovy, from short embedded scripts to full blown Grails apps ; thus we
>> have a good grasp of the language.*
>>
>> *There's no doubt that Groovy has some very strong points, including
>> closures, progressive typing, null-safe property navigation and tons of
>> smart extensions to the JDK. But the fact the language is mutable by
>> default and supports meta-programming (expando meta-class), has the
>> capacity to complicate things. If you've worked on a non-trivial Grails
>> application, I'm sure sure you know what I mean.*
>>
>> *Moreover, from a pure perception standpoint, despite 12 years of
>> existence, Groovy seems to have stayed a niche language. Its tumultuous
>> past and uncertain future, doesn't help deciding to bet the house on it.
>> The addition of closures and streaming API to Java, the rise of Rx, makes a
>> massive shift towards Groovy less likely in the future.*
>>
>> *Considering all of these, Clojure seemed a safer choice. There's a
>> strong language theory behind it. Its community is vibrant, opinionated and
>> pragmatic, a rare combination in our industry.*
>>
>> *We'll see in the future if our bet was right or not. In the meantime,
>> what a great ride :)*
>>
>>
>> = Eric MacAdie
>>
>
>

Re: Why aren't more people looking at Groovy?

[Ralph Johnson <jo...@cs.uiuc.edu>]

I'm glad you posted here.   I was beginning to wonder if the apache mailing
lists were working!

I'm using Groovy because of language mutability.   Language mutability is
definitely a two-edged sword, and it is easy to cut yourself if you aren't
careful.  But sometimes it can make a big difference.

In my project, we are designing a programming system for accountants.  They
have a browser that enables them to create and edit business rules.   The
business rules are a stripped down version of Groovy.  Using Groovy meant
that we didn't need to write our own parser.  We teach the accountants a
subset of Groovy, but every so often we discover that the system isn't
quite strong enough and we have to write a script that uses something
outside the subset.   That gets flagged as a design issue, and we try to
figure out a better way of designing the system so that the accountants
never have to write something like that.   Our phrase is "Ugg.  It looks
like programming".  Accountants don't want it to look like programming,
they want it to look like a spreadsheet.   Even though we all know that
spreadsheets are programming, too.

Anyway, Groovy made it easy for us to build the system and to evolve it.
I've always planned that at some time in the future, when the design
settled down, we'd write a real parser and make the language look more like
Excel.  At that point, we might rewrite everything in Java (or, who knows,
Clojure or Scala) and get rid of Groovy.   But I think that is years away.
  For now, with a small team, Groovy is fine.

I like functional programming.   We don't let our accountants write for
loops, but they can iterate over accounts or positions using closures.
They like operators like SUM and think they are easy.   Assignment
statements are tricky.  I try to steer them away from assignment, but
sometimes we can't avoid it.  I've thought of having our system detect all
scripts with assignment and label them in red, and then have some way of
looking at all red scripts so we can review them.

However, in the core of the system, the part that programmers look at but
accountants do not, functional programming wouldn't be that much use.  It
is fairly stateful.  Most of the system is in the sweet spot for
object-oriented programming, not functional programming, and Groovy has
served us well.

-Ralph Johnson

-Ralph Johnson

On Mon, Apr 27, 2015 at 10:06 PM, Eric MacAdie <em...@gmail.com> wrote:

> I started this discussion on the old list, and someone said it should be
> brought here.
>
> Here is my original post:
>
>
>
> *In addition to Groovy, I am also interested in Clojure. I found an
> interesting article on the Clojure reddit: "Our curvy road to Clojure" at
> http://inside.unbounce.com/product-dev/our-curvy-road-to-clojure/
> <http://inside.unbounce.com/product-dev/our-curvy-road-to-clojure/>*
>
>
> *The basic gist of the article is that they were a Java and Ruby shop, and
> they realized that combination was not working as well as they hoped, so
> they started looking for alternatives. They tried JRuby and Scala, before
> settling on Clojure.*
>
>
>
>
> *What I find odd is he never mentions looking at Groovy. I hear and read a
> lot about shops that start out using Java and pick up Ruby, and some of
> them eventually realize that the chocolate and the peanut butter do not mix
> as well as they had hoped. So they look for something else. Yet I never
> hear about any of them looking at Groovy. It seems like if you are using
> Java for heavy lifting and Ruby for more dynamic/agile work that Groovy
> would be a great fit.*
> *Has anyone else noticed this? Any thoughts?*
> I left a comment on the Unbounce blog asking if they looked at Groovy, and
> here is the response:
>
> *In their pre-Unbounce lives, several of us have had experience with
> Groovy, from short embedded scripts to full blown Grails apps ; thus we
> have a good grasp of the language.*
>
> *There's no doubt that Groovy has some very strong points, including
> closures, progressive typing, null-safe property navigation and tons of
> smart extensions to the JDK. But the fact the language is mutable by
> default and supports meta-programming (expando meta-class), has the
> capacity to complicate things. If you've worked on a non-trivial Grails
> application, I'm sure sure you know what I mean.*
>
> *Moreover, from a pure perception standpoint, despite 12 years of
> existence, Groovy seems to have stayed a niche language. Its tumultuous
> past and uncertain future, doesn't help deciding to bet the house on it.
> The addition of closures and streaming API to Java, the rise of Rx, makes a
> massive shift towards Groovy less likely in the future.*
>
> *Considering all of these, Clojure seemed a safer choice. There's a strong
> language theory behind it. Its community is vibrant, opinionated and
> pragmatic, a rare combination in our industry.*
>
> *We'll see in the future if our bet was right or not. In the meantime,
> what a great ride :)*
>
>
> = Eric MacAdie
>