[...] Well, I'm not talking about changing anything in Groovy distribution at all. Not even adding an annotation or a keyword. Guillaume and others have been very clear about that, and I respect that. So don't install a 3rd party patch, it won't affect you.

But I think it's an important question to ask: where can we reduce dynamism and still get all the features we know and love? Is there some other way to write the code that's about as clean, has the same features, but is a lot faster?

Do you think it's worth trying that, at least as an experiment to help drive the evolution of a FastGroovy?

[...] Going through the MOP doesn't need to be a deal breaker, as long as you can interrogate the MOP at compile time and, in common cases, find out what will be called. After all, you, me and the IDEs know (or guess) what myList.each { ... } calls. We rely on that understanding when we're writing code, and if it resolved to something else, we could be quite confused. (There are many valid cases where it could resolve to something else, e.g. a "profiling MOP" that intercepts the method call to increment a counter before doing the call, or for mocking during testing, etc.)