62 messages in org.codehaus.groovy.devRe: [groovy-dev] Groovy performance: ...
FromSent OnAttachments
Alex Tkachman19 Feb 2008 02:09 
Steven Devijver19 Feb 2008 02:37 
Alexandru Popescu ☀19 Feb 2008 02:57 
Alex Tkachman19 Feb 2008 03:03 
Patric Bechtel19 Feb 2008 03:12 
Guillaume Laforge19 Feb 2008 03:25 
Guillaume Laforge19 Feb 2008 03:26 
Patric Bechtel19 Feb 2008 05:05 
Gavin Grover19 Feb 2008 05:51 
Steven Devijver19 Feb 2008 05:52 
Guillaume Laforge19 Feb 2008 05:54 
Tom Nichols19 Feb 2008 06:26 
Alex Tkachman19 Feb 2008 06:28 
Guillaume Laforge19 Feb 2008 06:35 
Tom Nichols19 Feb 2008 07:03 
Guillaume Laforge19 Feb 2008 07:38 
Chanwit Kaewkasi19 Feb 2008 07:52 
Charles Oliver Nutter19 Feb 2008 08:49 
Steven Devijver19 Feb 2008 10:03 
Charles Oliver Nutter19 Feb 2008 11:38 
Steven Devijver19 Feb 2008 12:11 
Alex Tkachman19 Feb 2008 12:39 
Alex Tkachman19 Feb 2008 12:48 
tugwilson19 Feb 2008 13:36 
Alex Tkachman19 Feb 2008 20:51 
Guillaume Laforge20 Feb 2008 02:10 
Jochen Theodorou20 Feb 2008 09:46 
Martin C. Martin20 Feb 2008 17:25 
Guillaume Laforge21 Feb 2008 01:35 
Tom Nichols21 Feb 2008 04:15 
Martin C. Martin21 Feb 2008 05:44 
Tom Nichols21 Feb 2008 06:22 
Smith, Jason, CTR, OASD(HA)/TMA21 Feb 2008 06:34 
Martin C. Martin21 Feb 2008 06:43 
Guillaume Laforge21 Feb 2008 06:48 
Guillaume Laforge21 Feb 2008 07:04 
Smith, Jason, CTR, OASD(HA)/TMA21 Feb 2008 07:18 
Charles Oliver Nutter21 Feb 2008 07:38 
Guillaume Laforge21 Feb 2008 07:42 
Martin C. Martin21 Feb 2008 08:36 
Martin C. Martin21 Feb 2008 08:48 
Pascal DeMilly21 Feb 2008 17:35 
Gavin Grover21 Feb 2008 18:21 
Jochen Theodorou22 Feb 2008 04:31 
Tom Nichols22 Feb 2008 04:49 
Charles Oliver Nutter22 Feb 2008 23:43 
Guillaume Laforge23 Feb 2008 00:28 
Martin C. Martin23 Feb 2008 03:51 
Jochen Theodorou23 Feb 2008 14:49 
Jochen Theodorou23 Feb 2008 14:53 
Charles Oliver Nutter24 Feb 2008 02:01 
Martin C. Martin24 Feb 2008 03:56 
Martin C. Martin24 Feb 2008 04:11 
Charles Oliver Nutter24 Feb 2008 05:12 
Jochen Theodorou24 Feb 2008 15:17 
Jochen Theodorou24 Feb 2008 15:31 
Alexandru Popescu ☀24 Feb 2008 15:36 
Martin C. Martin26 Feb 2008 14:20 
Martin C. Martin26 Feb 2008 15:15 
Jochen Theodorou27 Feb 2008 02:38 
Jochen Theodorou27 Feb 2008 03:03 
Martin C. Martin02 Mar 2008 17:21 
Subject:Re: [groovy-dev] Groovy performance: what to do
From:Guillaume Laforge (glaf@gmail.com)
Date:02/19/2008 05:54:08 AM
List:org.codehaus.groovy.dev

On Tue, Feb 19, 2008 at 2:05 PM, Patric Bechtel <patr@gmail.com> wrote:

[...] I'm not sure if this is really true. So far, there's plenty of Java programmers out there who would *love* to use Groovy if there was more compile time checking involved. But, and I understand that, that's not possible as long as everything is super-dynamic. It's not that I don't appreciate that, it's very very nice. Really. But as even a typo in a variable goes unnoticed by the compiler, it's annoying compared to Java to prototype an algorithm. So, sometimes, it would be nice to make the compiler more strict, so that less things go unnoticed into runtime failures. I can speak only for my colleagues and me, as we currently use yet another "alternative" language for Java development, and as syntax is already very similar, a switch to or coexistence with Groovy would be, given the possibilities of Groovy, very nice.

Regarding more 'strictness', I think you'd be more interested in this approach suggested by Graeme recently: http://groovy.markmail.org/message/b65lr6u3ejkwt3kq

To emphasize my point: It's less the speed (though welcome, but we are not doing raw numeric calculations anyway), it's the convenience and the confidence of getting the source through compile stage (we are not using an IDE) and being able to concentrate onto the algorithm itself. Maybe we should think about the @Typed annotation as tip to the compiler for stricter checks? Or we rename it and leave it to future compiler versions to optimize differently according to this setting?

These kind of checks are also the job of the IDE, so that it gives you warnings where you're doing something which is off the usual static typing limits that Java developers are used to. The compiler could also provide some additional checks, when certain flags or options are activated. Although in those cases, it's probably because you're coding Java in Groovy :-)

At least, we have to pick up the majority of java programmers where they currently are, and not where you wish them to be. I'm a strong advocate of Groovy and use it wherever I can and urge others to do the same. But given a bridge to static typed minds to get to Groovy dynamic worlds would help them come over...

Groovy is not just Java plus a couple of features like closures or native syntax for lists and maps. Groovy's goals go further than this, and if we would limit its abilities to stay within the usual limits, we wouldn't have frameworks like Grails, or we wouldn't be able to create Domain-Specific Languages. Fortunately, Groovy gives Java developers a rather flat learning curve, and as you learn Groovy, you come to use and love more advanced features and capabilities.

-- Guillaume Laforge Groovy Project Manager G2One, Inc. Vice-President Technology http://www.g2one.com

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

http://xircles.codehaus.org/manage_email