« Return to Thread: Groovy performance: what to do
Re: Groovy performance: what to do
by Patric Bechtel-2
::
Rate this Message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Guillaume Laforge schrieb am 19.02.2008 12:25:
Hi,
> This is an interesting experiment.
>
> However, as this has been discussed on this list a few times already
> or at the last Groovy Developer Conference, it's better and saner to
> make Groovy the fastest dynamic language possible on the JVM by
> creating the best second generation MOP, rather than by adding a few
> hacks to make Groovy a more statically typed language.
>
> What would happen if such a proposal was committed?
> In a few months from now, all Groovy code samples we would come across
> would be littered with @Typed annotations all around -- who remembers
> the ugly @Property annotation making your Groovy beans ugly?
> A few months later, and people will wonder why this is not the default
> behavior and be applied to all possible methods or classes.
> Groovy will become more and more statically typed, and for
> "performance sake", we'd imagine other such hacks to make Groovy less
> and less dynamic over time, or littered with ugly annotations.
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.
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?
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...
- --
Patric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.5.2
iD8DBQFHutQafGgGu8y7ypARAjJcAKCyBCk38eMcpWKONXpMXjVoQySzgQCfU9D9
i8PgPw8Us0MoIlRDnHweBPs=
=Nxy3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Hash: SHA1
Guillaume Laforge schrieb am 19.02.2008 12:25:
Hi,
> This is an interesting experiment.
>
> However, as this has been discussed on this list a few times already
> or at the last Groovy Developer Conference, it's better and saner to
> make Groovy the fastest dynamic language possible on the JVM by
> creating the best second generation MOP, rather than by adding a few
> hacks to make Groovy a more statically typed language.
>
> What would happen if such a proposal was committed?
> In a few months from now, all Groovy code samples we would come across
> would be littered with @Typed annotations all around -- who remembers
> the ugly @Property annotation making your Groovy beans ugly?
> A few months later, and people will wonder why this is not the default
> behavior and be applied to all possible methods or classes.
> Groovy will become more and more statically typed, and for
> "performance sake", we'd imagine other such hacks to make Groovy less
> and less dynamic over time, or littered with ugly annotations.
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.
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?
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...
- --
Patric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.5.2
iD8DBQFHutQafGgGu8y7ypARAjJcAKCyBCk38eMcpWKONXpMXjVoQySzgQCfU9D9
i8PgPw8Us0MoIlRDnHweBPs=
=Nxy3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: Groovy performance: what to do
| Free embeddable forum powered by Nabble | Forum Help |
