19 December 2012Tweeter
It’s a long time since I last blogged. I’ve been quite busy of course, but it doesn’t give me a good reason not to maintain this blog!
Last week, I spoke at the Groovy&Grails eXchange 2012. It was a really pleasant experience and I wanted to share some feelings with you.
There is something very funny when I meet people now. One or two years ago, people knowing my name were just a few, focused, guys on the mailing list. Now, with the work I’ve done in Groovy 2, that is to say static type checking and static compilation, more and more people recognize me and even those who knew me before start to think of me as the “static guy”.
The truth is that while it’s correct that my main focus was to develop those features and that I really enjoy it, I spent a lot of time working with Groovy before, and advocating its dynamic nature to my coworkers. The dynamic nature of the language helped us a lot and it’s definitely the main focus of the language. This means that in the dynamic vs static language war, I’m in the middle camp: I like both!
This directly drives me to the most surprising talk given at the Groovy&Grails eXchange, I mean “Why Groovy when Java 8 or Scala or…” by Russel Winder. When I say surprising, I mean that it’s not often that you can hear “War Pigs” from Black Sabbath before the talk begins, and it’s not often either that in a Groovy conference, a speaker tries to demonstrate that Groovy is no longer necessary. At least, he tried to, because knowing him as one of the best Groovy advocates in town, I was just wondering all the short 45 minutes session along, when turnaround would occur. It did not. Maybe because Russel expected the session to last 1 hour, but even with 15 more minutes, I’m not convinced that he would, because if I understood him well, he wanted by this talk to conduce the Groovy community to be more active in the JVM community in general, by proving by the fact that Groovy is a major language, not just a poor substitute to Java 8.
I think I’m not too far from the truth when I read this very funny comment about me in his blog post: Cédric Champeau the person driving the static type checking and compilation was in the audience and I survived. Perhaps I wasn’t contentious enough.. I’m sorry if I disappointed you, Russel, but as I’m not in particular the “static guy” people think I am and that I have a very clear idea of what static compilation in Groovy is good for, I think it makes it difficult to make me unconfortable on the subject. In fact, I’m most worried about what people would think of this talk just reading the slides! Another thing, maybe, is that humour and cultural references in this talk were very british centered (that makes sense, we were in London after all) and that it was sometimes difficult to follow for me.
Let me explain again why we introduced static type checking and static compilation in Groovy:
Groovy as a better Java: Groovy syntax is more concise, Groovy has closures, learning curve is close to zero. Ah, but Groovy is a dynamic language. Period. @TypeChecked to the rescue!
Performance. You always have to be careful here, because as I always explain, Groovy is not slow (anymore). It even perfoms really good when you think of all the wonders it does before invoking methods. But in some situations, it is significantly slower than Java. For those cases, you can use @CompileStatic and have generated bytecode very close if not equal to what Java produces, so acheive the same level of performance.
What is interesting regarding performance is what Russel said in his talk: Java 8 will have lambdas, type checked lambdas (and using the new collections APIs the type checked syntax can even be more concise than the Groovy one, that’s a problem we must address) and for it, it makes use of the invoke dynamic feature that was introduced in Java 7. As you know, Groovy 2 introduced usage of invoke dynamic too, and Groovy 2.1 pushes it further enough that performance of dynamic Groovy is close to what Java offers (as always, be careful with figures, even more when talking about invokedynamic because from one VM to another you can have very different results). But that’s what we hoped from day 1 when adding invoke dynamic support to Groovy: we seriously hope that performance of dynamic languages, and here Groovy, will become close to the performance of static languages. So if performance is close to Java, why did we introduce static compilation in the same version as invoke dynamic? There are various reasons for that:
unfortunately, people will not use Java 8 in production before years. Java 7 in production is still rare, most people are stuck with Java 6. We had to offer performance for those people too.
type checking: as explained before, even if you use a dynamic language, some people just want compilation errors
enforced semantics: statically compiled code is immune to monkey patching. Any code compiled with invoke dynamic support will have the same behaviour as dynamic groovy, so will go though the meta-object protocol. This is not a problem, this is what we want and the good thing is that indy (invoke dynamic) makes it fast, but it can be a problem for framework creators, for example, that do not want their code to be subject to metaclass changes in a third party library.
Russel’s talk echoed to the last talk from day 1, which was an open discussion with the Groovy community. One of the covered subjects was why would people use static type checking or static compilation for Groovy. There were a lot of interesting comments but one of them shocked me: developers were saying that static type checking wasn’t necessary because you write unit tests. Ok, let me be very clear on the subject: I’m not against test-driven development (though I usually prefer writing unit tests as I implement things), but I seriously think that focusing on unit tests is a very big error:
static type checking is about catching errors early, without having to run code. This is very important to understand
people do not write tests, and if they do, it’s always not enough. If you do, you can only write tests for what you think of. Just as well as 100% code coverage doesn’t mean no bugs, thousands of unit tests doesn’t guarantee you’re covering all cases.
DSLs: Groovy is a platform of choice for implementing DSLs. The thing is that a lot of DSLs are not aimed at developers. They are often aimed at people that know business rules and can focus on some formalism to describe them. Those people are not developers and you cannot expect them to write unit tests. That doesn’t mean we can’t do anything for them, and that’s also what my talk was about
To be short, Groovy puts itself in the middle of the dynamic vs static war for very good reasons. One of them is choice. I like to have the choice to use the best strategy for my needs. If it’s dynamic code, let’s do it. If it’s static code, do it too. If you absolutely want type checking, you can, and if you want to use dynamic Groovy and still be able to throw errors at compile time for people using your DSL, now you can too… Because if you ever want to compare Groovy with Java 8, never ever forget that Groovy is more than statically compiled Groovy compared to Java 8. It offers both runtime and compile-time programming which makes it unavoidable if you want to implement a DSL on the JVM…
GGX was the first conference where I talked about a new feature in Groovy 2.1, which is “customizable” type checking. The idea is to help the type checker where it fails, because you know more about your code, what it does, how it is implemented than it does. This allows very nice features, like the ability to throw errors at compile time where Groovy would normally fail at runtime, but using DSLs, independently of their implementation. This is in particular important for people that implement DSLs using dynamic features of the language, because the type checker is obviously totally lost in that situation. Having the ability to check a user script at compile time, report errors before it goes in production is a big win here. You can even have the compiler be smarter than Java (or another statically compiled language) is given your domain.
The talk was rather technical and dealing with such a subject in only 45 minutes was a challenge (that I only half acheived) but I had good feedback. For those who are interested in the subject and missed this talk, you can still attend my session at the Greach conference in Madrid in the end of January. I hope I’ll be able to do it at GR8Conf in an extended version in May too. Of course, you can still watch the recorded session online.
I think this is a very powerful feature that opens a lot of new capabilities just like adding AST transformations to the language drove Groovy to a superior level. I’m eager to see what people will be able to do with it, even if it requires, that’s true, some technical skills, in particular some knowledge about the Groovy AST (abstract syntax tree). For people who are used to writing AST transforms, that shouldn’t be much a problem.
Talking at conferences is always the best way to meet the community and gather feedback and new ideas from actual users. We are not, as Groovy or Grails committers, super heroes. I’m always amazed to see what users manage to do with what we implement in the language and I tend to think you are the real super heroes. At GGX, once again, I was really impressed with what Spock offers, for example. The talk was given by Rob Fletcher who also gave another talk about Grails for Hipsters. Both of his talks were so attended that at this point, the conference could have been named “The Rob Fletcher eXchange”. If you want someone to demonstrate the superiority of dynamic languages over static ones, he’s your man.
Oh wait, did I say dynamic? ;-)
Last word as a special thanks to Peter Ledbrook who left VMware a few weeks ago. He did a lot for this GGX conference but more than that, he was the best Groovy/Grails advocate and we’ll definitely miss him!