What's Groovy's Culture?

[Hien Luu]

Hi All,

One of the advices in the "97 Things Every Programmer Should Know" book is about don't just learn a new programming language, but try to understand its culture.

So if I have to explain to someone new to Groovy, how would I describe Groovy's culture?

Thanks in advance,

Hien

[lam nguyen phuc]

On Saturday 26,March,2011 12:08 AM, Hien Luu wrote:

Hi All,

One of the advices in the "97 Things Every Programmer Should Know" book is about don't just learn a new programming language, but try to understand its culture.

So if I have to explain to someone new to Groovy, how would I describe Groovy's culture?

Thanks in advance,

Hien

In my opinion, here are some Groovy "cultures"  (as opposed to Java):

• Use closure to encapsulate a block of code and pass it around instead of using anonymous inner class
• Use some added convenient methods for recurring tasks such as I/O instead of writing tedious scaffolding code (try/catch/finally)

I recommend you trying to experience with groovy, thereby finding your answer for your question.

Regards,

Lam

[Karl Auer]

On Sat, 2011-03-26 at 13:26 +0800, lam wrote:
> In my opinion, here are some Groovy "cultures"  (as opposed to Java):

I recently had to do a project in Groovy. I like closures. But Groovy
seems to have thrown out bucketloads of compile-time safety.

*Aside from convenience*, why should I choose Groovy over Java? Saving
lines of code is no saving if those lines of code cannot be compile-time
checked. Even convenience is no positive if it is at the cost of
readability.

I'm not trying to start a war here! I am genuinely puzzled at Groovy's
popularity; I must be missing something, and would genuinely like to be
informed. Off list if you fear I am a troll...

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])                   [phone] (h)
http://www.biplane.com.au/kauer/                   [phone] (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

[Wilson MacGyver]

The first question is, are you a static type kind of guy? Static vs
dynamic is an age old debate. If you dislike dynamic strongly,
nothing I say can change your mind.

I make heavy usage of both, and believe both have their place,
And this is coming from someone who likes Haskell,
which is probably the strictest type language ever invented on
the face of this planet. :)

Groovy is more concise. Take null safety for example.
In java, you'd have to check or do try catch.
In groovy, you can just do a?.doStuff()

Both the compile time meta programming and MOP allow
you to extend code in very non-trivial ways.

And then there is @Grab, I can write a 3 line script to automate
FTP process, using grab to setup all the deps. So I can just scp
the groovy file somewhere, run it by doing groovy download.groovy
without worrying about jars.

Just convenience? Perhaps. But when you run this type of
scripts on a few hundred machines, this is a very nontrivial
benefit.

And then there is the built in XML slurper/builder, as well as the
upcoming JSON slurper/builder.

Looking at it from another angle, one of the major strength of gradle
as a build system is, the build.gradle is in fact a groovy file, which
allow you to use any groovy code in the build file. This is so useful
even pure java projects are switching from mvn to gradle. It's far more than
just connivence.

Thanks

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[HamletDRC2]

I think the answers given so far are correct but miss the point of the question.

Here is my statement on Groovy culture:

"Make it easy."

If you want a further explanation, then here are a few more:

"Make it easy to leverage your Java know-how"
"Make it easy to accomplish common tasks like working with XML, Files, Strings, Lists, and Maps"
"Make it easy to dynamically change your program at runtime (metaprogramming)"
"Make it easy to learn"

Here are some statements that are *not* Groovy culture, but are the culture of other languages:

"Make it type-safe"
"Make it consistent"
"Make it minimal"

I think these types of statements are what the OP is seeking.

--
Hamlet




----- Original Message -----

> The first question is, are you a static type kind of guy? Static vs
> dynamic is an age old debate. If you dislike dynamic strongly,
> nothing I say can change your mind.
>
> I make heavy usage of both, and believe both have their place,
> And this is coming from someone who likes Haskell,
> which is probably the strictest type language ever invented on
> the face of this planet. :)
>
> Groovy is more concise. Take null safety for example.
> In java, you'd have to check or do try catch.
> In groovy, you can just do a?.doStuff()
>
> Both the compile time meta programming and MOP allow
> you to extend code in very non-trivial ways.
>
> And then there is @Grab, I can write a 3 line script to automate
> FTP process, using grab to setup all the deps. So I can just scp
> the groovy file somewhere, run it by doing groovy download.groovy
> without worrying about jars.
>
> Just convenience? Perhaps. But when you run this type of
> scripts on a few hundred machines, this is a very nontrivial
> benefit.
>
> And then there is the built in XML slurper/builder, as well as the
> upcoming JSON slurper/builder.
>
> Looking at it from another angle, one of the major strength of gradle
> as a build system is, the build.gradle is in fact a groovy file,
> which
> allow you to use any groovy code in the build file. This is so useful
> even pure java projects are switching from mvn to gradle. It's far
> more than
> just connivence.
>
> Thanks
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Ben Tilford]

Even with type safety all the boiler plate code you are forced to repeat over and over again is more likely to contain bugs and introduce maintenance issues than a dynamic lanaguage that provides sane defaults (also reducing the number of lines you are capable of introducing bugs in). Compile time checks are a very rudimentary (not that the compiler is rudimentary) "feel safe" way of thinking your have prevented bugs that are very obvious. 

Also it's not like you can't declare types with groovy if you feel like it.

On Fri, Mar 25, 2011 at 11:45 PM, Karl Auer <[hidden email]> wrote:

On Sat, 2011-03-26 at 13:26 +0800, lam wrote:
> In my opinion, here are some Groovy "cultures"  (as opposed to Java):

I recently had to do a project in Groovy. I like closures. But Groovy
seems to have thrown out bucketloads of compile-time safety.

*Aside from convenience*, why should I choose Groovy over Java? Saving
lines of code is no saving if those lines of code cannot be compile-time
checked. Even convenience is no positive if it is at the cost of
readability.

I'm not trying to start a war here! I am genuinely puzzled at Groovy's
popularity; I must be missing something, and would genuinely like to be
informed. Off list if you fear I am a troll...

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])                   [phone] (h)
http://www.biplane.com.au/kauer/                   [phone] (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

[paulk_asert]

On 26/03/2011 3:45 PM, Karl Auer wrote:
> On Sat, 2011-03-26 at 13:26 +0800, lam wrote:
> *Aside from convenience*, why should I choose Groovy over Java? Saving
> lines of code is no saving if those lines of code cannot be compile-time
> checked. Even convenience is no positive if it is at the cost of
> readability.

Well with decent IDE support (both Eclipse and IDEA do well here) you
get type-time type inference feedback for the bulk of silly typo style
errors or incorrect API usage errors. No need to wait until compile-time.
Plus with tools like CodeNarc and some decent coding conventions, you
can certainly write very maintainable high-quality code. Languages like
Haskell provide you with certain language capabilities to obtain additional
compile-time feedback but often to get the extra feedback there is some
significant cost involved.

Cheers, Paul.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Wilson MacGyver]

In that vein, I'd add "make it practical to solve real world problem"

On Mar 26, 2011, at 1:51 AM, Hamlet DArcy <[hidden email]> wrote:

> I think the answers given so far are correct but miss the point of the question.
>
> Here is my statement on Groovy culture:
>
> "Make it easy."

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Brian Schlining]

So if I have to explain to someone new to Groovy, how would I describe Groovy's culture?

I would describe Groovy's culture as very pragmatic. If you look over threads in the mailing list the questions tend to be about how to get something done. Compare this to threads in say, Scala, which tend toward more towards academic discussions and  debates over monads, endos, type theory, etc. [BTW, That's not a knock against Scala, which I think it's a a beautiful and well thought out language.]

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
[hidden email]

[Weiler-Thiessen, David, SASKATOON, Engineering]

Hi

 

I would build on that by saying that Groovy is the voice of Java experience.  Having been a Smalltalk developer prior to doing Java, Groovy comes across as how Java should have been implemented.  Groovy, and hence people that form the culture have taken the pragmatic, practical principles of software development and have chosen to fix the issues by breaking out of the strictures imposed by Java to come up with an out of the box solution that leverages Java where it makes sense, and allows alternatives where the alternative approach makes more sense.

 

David Weiler-Thiessen
Nestlé Purina PetCare
phone: [phone]
cell: 306-291-9770

This e-mail, its electronic document attachments, and the contents of its website linkages may contain confidential information. This information is intended solely for use by the individual or entity to whom it is addressed. If you have received this information in error, please notify the sender immediately and promptly destroy the material and any accompanying attachments from your system.

From: Brian Schlining [mailto:[hidden email]]
Sent: Saturday, March 26, 2011 11:00 AM
To: [hidden email]
Subject: Re: [groovy-user] What's Groovy's Culture?

 

So if I have to explain to someone new to Groovy, how would I describe Groovy's culture?

 

I would describe Groovy's culture as very pragmatic. If you look over threads in the mailing list the questions tend to be about how to get something done. Compare this to threads in say, Scala, which tend toward more towards academic discussions and  debates over monads, endos, type theory, etc. [BTW, That's not a knock against Scala, which I think it's a a beautiful and well thought out language.]

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
[hidden email]

[darrencruse]

Liked Hamlet's reply - to me that seemed closest to the intent of the OP's question.  

But I also liked the reference to Smalltalk and wanted to say that, broadly speaking, it feels to me that the *culture of Java* is the "tribal legacy" handed down from the cultures of:

     C --> C++ --> Java

Where these cultures were about optimizing machine performance, catching problems at compile time over run time, compilers over interpreters.  And yes I know I'm selling Java short a little bit due to it's incorporation of reflection and garbage collection...   but:

By comparison, the *culture of groovy* seems to me the "tribal legacy" of:

     Lisp ->

       Smalltalk ->

           Ruby ->

              Groovy

Where I hesitated to put them in one line like for Java I don't think things are as simple...

But Lisp started the MOP idea, the compile time metaprogramming stuff for Groovy seems at least conceptually connected to Lisp macros, and Groovy DSLs seem connected to the Lisp idea of "homoiconicity" i.e. that "code is data".  And of course I shouldn't forget closures.  Smalltalk started OO in a dynamic language and from what I've read Alan Kay did look to the Lisp MOP for inspiration for certain things, and I've heard people refer to Ruby as a modern variant on Smalltalk with a different syntax, and I assume/I think the success of Ruby and ROR influenced Groovy happening when it did - as something similar with a more java friendly syntax and interoperability.  

But though groovy has a java friendly *syntax*, it seems to me the "culture" or "semantics" of groovy embrace programmer performance being more important than machine performance, allowing type checking to occur at run time over compile time, with the optional types and closures and DSL'ish builder stuff all working to create shorter more readable code that does more with less.

I might add too that I think it's fair when people criticize Groovy's IDE code completion/type checking/refactoring support stuff compared to Java's (as I was thinking about as I did a big refactoring of some java code in Eclipse and wondered how groovy would have compared).  But it also seems ironic/unfair in that when you look at the "IDEs" of these dynamic languages like e.g. the source browser/inspector/debugger thingies in something like Squeak Smalltalk, the worked by actually handing the thread of interpretation of the actual program over to the debugger.  So that you are actually inspecting the variables, available methods, etc. of the *running program*.  Certainly the early groovy IDE support I don't think could do this and I won't claim the smarts enough to know if the latest is doing so.

But it's an example where when people are so hard on groovy saying e.g. "auto completion is a problem", I feel like it's applying the static typing assumptions coming out of the java world and from the IDEs written for java, to a language that just happens to run on java but really comes out of a different heritage.  The answer is to write a really good Smalltalk like debugger that works for groovy not to trash the language.   

Anyway, in short, I don't know whether I've got every historical detail correct, but it's tempting for me to think the culture of Java is the legacy of the culture of C, and the culture of groovy is the legacy of the culture of Lisp.

Where from everything I've read, John McCarthy the inventor of Lisp was probably truly a genius like Einstein.

And where the folks on the C/C++/Java side, the folks at AT&T, Bjarne Stroustrup, and James Gosling are obviously smart folks too.

But I hope you caught my point what I said - the culture of groovy is the culture of *genius*. :)

On Sat, Mar 26, 2011 at 12:07 PM, Weiler-Thiessen,David,SASKATOON,Engineering <[hidden email]> wrote:

Hi

 

I would build on that by saying that Groovy is the voice of Java experience.  Having been a Smalltalk developer prior to doing Java, Groovy comes across as how Java should have been implemented.  Groovy, and hence people that form the culture have taken the pragmatic, practical principles of software development and have chosen to fix the issues by breaking out of the strictures imposed by Java to come up with an out of the box solution that leverages Java where it makes sense, and allows alternatives where the alternative approach makes more sense.

 

David Weiler-Thiessen
Nestlé Purina PetCare
phone: <a href="tel:[phone]" target="_blank">306-933-0232
cell: <a href="tel:[phone]" target="_blank">306-291-9770

This e-mail, its electronic document attachments, and the contents of its website linkages may contain confidential information. This information is intended solely for use by the individual or entity to whom it is addressed. If you have received this information in error, please notify the sender immediately and promptly destroy the material and any accompanying attachments from your system.

From: Brian Schlining [mailto:[hidden email]]
Sent: Saturday, March 26, 2011 11:00 AM
To: [hidden email]
Subject: Re: [groovy-user] What's Groovy's Culture?

 

So if I have to explain to someone new to Groovy, how would I describe Groovy's culture?

 

I would describe Groovy's culture as very pragmatic. If you look over threads in the mailing list the questions tend to be about how to get something done. Compare this to threads in say, Scala, which tend toward more towards academic discussions and  debates over monads, endos, type theory, etc. [BTW, That's not a knock against Scala, which I think it's a a beautiful and well thought out language.]

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
[hidden email]

[Ken Tanaka]

Brian Schlining wrote:

>
>>
>>     So if I have to explain to someone new to Groovy, how would I
>>     describe Groovy's culture?
>
>
> I would describe Groovy's culture as very pragmatic. If you look over
> threads in the mailing list the questions tend to be about how to get
> something done. Compare this to threads in say, Scala, which tend
> toward more towards academic discussions and  debates over monads,
> endos, type theory, etc. [BTW, That's not a knock against Scala, which
> I think it's a a beautiful and well thought out language.]
> --
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> Brian Schlining
> [hidden email] <mailto:[hidden email]>

I haven't found the less strict typing in Groovy to be a problem at all,
but then I've also been a long time Perl programmer too (before I
learned Java), and have always found it natural and easy to get less
strict languages to do what I want in that regard.

For me the real benefit is accomplishing common tasks in fewer lines of
code, which to me makes the meaning much clearer. Since Groovy provides
getters and setters, that's less code-pollution that obscures the real
purpose of the classes. Good variable names and proper commenting keeps
compact code from being cryptic.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Brian Schlining]

I haven't found the less strict typing in Groovy to be a problem at all, but then I've also been a long time Perl programmer too (before I learned Java), and have always found it natural and easy to get less strict languages to do what I want in that regard.

I agree, Groovy is a great adjunct/replacement for Perl. Personally, when writing larger systems/applications I prefer static typing, but as I said, that's a personal preference. My biggest issue with Groovy is still it's performance for the some of the stuff I write (numerical analysis). [And please don't mistake that comment as a complaint against Groovy as for many things Groovy's performance is just fine. Rather, it's just the reality of the overhead incurred for all of Groovy's dynamic magic.]

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
[hidden email]

[Jochen Theodorou]

Am 28.03.2011 20:17, schrieb Brian Schlining:
[...]
> I agree, Groovy is a great adjunct/replacement for Perl. Personally,
> when writing larger systems/applications I prefer static typing, but as
> I said, that's a personal preference. My biggest issue with Groovy is
> still it's performance for the some of the stuff I write (numerical
> analysis). [And please don't mistake that comment as a complaint against
> Groovy as for many things Groovy's performance is just fine. Rather,
> it's just the reality of the overhead incurred for all of Groovy's
> dynamic magic.]

out of interest... if you do numerical analysis, then you do most
operations on primitive numbers? If so, what types do you usually use?

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Tim Yates]

I do large biological analyses and tend to use doubles for the extra precision when dealing with very small variations

On 28 March 2011 20:59, Jochen Theodorou <[hidden email]> wrote:

Am 28.03.2011 20:17, schrieb Brian Schlining:
[...]

I agree, Groovy is a great adjunct/replacement for Perl. Personally,
when writing larger systems/applications I prefer static typing, but as
I said, that's a personal preference. My biggest issue with Groovy is
still it's performance for the some of the stuff I write (numerical
analysis). [And please don't mistake that comment as a complaint against
Groovy as for many things Groovy's performance is just fine. Rather,
it's just the reality of the overhead incurred for all of Groovy's
dynamic magic.]

out of interest... if you do numerical analysis, then you do most operations on primitive numbers? If so, what types do you usually use?

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

[Brian Schlining]

 My biggest issue with Groovy is
still it's performance for the some of the stuff I write (numerical
analysis). 

out of interest... if you do numerical analysis, then you do most operations on primitive numbers?

Yes.

 

If so, what types do you usually use?

Probably 99% of the primitives I use will be int for indices and double for everything else.

 

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
[hidden email]

[Brian Schlining]

If so, what types do you usually use?

Probably 99% of the primitives I use will be int for indices and double for everything else.

Oh, and double[], lots and lots of double[]

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
[hidden email]

[Wilson MacGyver]

On Mon, Mar 28, 2011 at 3:59 PM, Jochen Theodorou <[hidden email]> wrote:
> out of interest... if you do numerical analysis, then you do most operations
> on primitive numbers? If so, what types do you usually use?

in our case for gaming, it tends to be ints and floats. lots of floats.

--
Omnem crede diem tibi diluxisse supremum.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Tim Yates]

Oh yeah, double[] galore over here too...

On 28 March 2011 21:23, Brian Schlining <[hidden email]> wrote:

If so, what types do you usually use?

Probably 99% of the primitives I use will be int for indices and double for everything else.

Oh, and double[], lots and lots of double[]

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
[hidden email]

[Wilson MacGyver]

On Mon, Mar 28, 2011 at 3:59 PM, Jochen Theodorou <[hidden email]> wrote:
> out of interest... if you do numerical analysis, then you do most operations
> on primitive numbers? If so, what types do you usually use?

since we are actually specifying container, yes, we use lots of float[] :)


--
Omnem crede diem tibi diluxisse supremum.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email