Talking Groovy, Programming Languages, and Code Quality with Hamlet D'Arcy
Talking Groovy, Programming Languages, and Code Quality with Hamlet D'Arcy
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
Welcome to the third in a series of interviews dedicated to learning more about JetBrains Development Academy Experts. This time we will interview Hamlet D'Arcy. Hamlet is a Groovy commiter, frequent speaker at Java and Groovy conferences and very active member of Groovy Users of Minnesota group.
Academy Members of the JetBrains Academy are recognized experts in various areas of software development. They contribute to Java and .Net communities by advocating development best practices through formal and informal publications and meetings, and serve as a versatile source of expertise.
Question: Hello Hamlet, can you please tell us something about yourself? Who you are and what are your passions?
Answer: I'm a guy that really loves writing code. Alone, in a pair, at work or home, whatever. It's mentally challenging, and I get a thrill out of seeing ideas implemented and things I write get used by others. I also find it feeds my obsessive compulsive side nicely. I'm quite happy to spend an hour rearranging someone else’s braces or turning tabs into spaces. A few nights ago I ran the IDEA spell checker against the Groovy codebase and spent two hours fixing spelling mistakes. Yeah, it was pretty boring but also strangely satisfying.
Question: So, you are one of Groovy committers. What is your opinion about the future of Groovy?
Answer: I got involved with Groovy because I wanted to learn how a language was implemented. I started by looking at the coverage report and writing test cases for code that wasn't tested. It was a good way to learn Groovy and a good way to contribute back, in case there are people out there wondering how to get involved with open source. Groovy, the language, is quite stable at this point. The upcoming 1.8 release has a lot of "features", but these are really more like library additions than language changes. Groovy has always been focused on removing Java boilerplate, and the new annotations @Synchronized, @WithReadLock and @WithWriteLock, and @AutoClone are good examples of this. These are all Groovy compiler extensions (known as AST Transformations) that affect the .class file produced. I've heard the criticism that these things should be libraries and not part of the language, but that's really a debate about distribution. The interesting part is that the Groovy compiler became extensible and we're seeing more and more frameworks like Spock, GContracts, and Griffon take advantage of this with interesting results. Other than that, technical lead Jochen Theodorou just checked in a whole bunch of performance optimizations for Groovy and I'm pretty excited to see the results. It happened with the Groovy 1.8 Beta 3 release, so this is the newest of the new. It would be great if people could download the release and test their apps with it, even if it is just to run the unit tests.
Question: What is your favorite JVM language beside Groovy and Java and why?
Answer: Easily F#, which is technically a CLR language and does not run on the JVM. Like the rest of the world, I decided to learn a functional language a few years ago. My friend Robert Fischer was a huge OCaml nut at the time but the tooling of vi and command line turned me off. F# looked good because it did have better tooling (Visual Studio), a slightly better syntax, and didn't make many concessions to being an FP-OO Hybrid. I spent a lot of 2009 coding F# on a side project that took over my life for a few months, and I came away deeply impressed. If you learned to program in an OO paradigm then you owe it to yourself to go deep into functional programming for at least a few months. It changes the way you think. My F# project was a Logo programming environment for kids called CrushGraphics and we ended up winning an innovation award from Pearson Educational. Sadly, I haven't touched the codebase in about a year.
Question: I know you are the founder of the world famous Hackergarden How did this idea come into your mind?
Answer: Ha, well I think it is only world famous because I won't shut up about it. Anyway, I moved to a small city in Switzerland last year and the area had strong techies but not many user groups. It seemed the easiest way to solve that was start our own. A group of us get together once a month to write open source code. It's a fun alternative to a traditional user group and we almost always leave with a patch or commit being made against a project. There are actually quite a few groups like this world-wide, and you can probably find one near you through the website http://hackerspaces.org/. If not, then just start your own.
Question: You are strongly involved in open-source projects, so maybe you have suggestions for people wanting to get involved in open-source?
Answer: Getting more involved with Groovy and other open source projects has definitely changed my life for the better. It is a family that opens its arms to almost anyone willing to do a little work. The first patch I submitted to Groovy was a unit test for some DateRange objects. Like I said, I took a look at the test coverage report, saw some low coverage on an object, and wrote a unit test in Groovy. It was pretty simple, and as time progressed I learned more and made bigger contributions. I see a lot of people who don't start small. They want their first contribution to be a new framework, or a new language feature, or something that takes about 100 hours to complete. How about starting with something that takes 1 hour to complete? Like a unit test or better Javadocs. Most Java projects have coverage reports, and if they don't maybe you can add it to the build. My advice is start small. Do the smallest thing possible now and worry about doing more later.
Question: Could you tell us something about your development process? What tools do you use at work?
Answer: Well, we know each other because we're both JetBrains Academy members, which means we're like evangelists light. So obviously, I'm an IntelliJ IDEA user. It's no secret that I'm a tool guy (which is slightly different than just /being/ a tool). Eclipse is what convinced me to leave C++ for Java. I used it during grad school and thought, "Why the heck am I wasting my time with languages that don't have automated refactoring?" It was easy to see that I was more productive in Java and the tooling was a big part of that. The irony is that my first Java job in 2005 was with an IDEA shop.
Anyway, my preferred software development lifecycle starts with napkins and sketches, moves to index cards and whiteboards, and finishes with automated tests and a self documenting system. The big pieces in the middle are IDEs, version control, and continuous integration. I also find frameworks like FindBugs, PMD, the IDEA Inspections, and CodeNarc (for Groovy), which do static analysis of code to locate bugs, are really important for producing idiomatic and correct code. Especially if you're writing concurrent, multi-threaded code, then you need to be using some sort of tools like these. The IDEA threading inspections have saved me many times in the past.
Question: You are also involved in the CodeNarc project. How does it compare to IntelliJ IDEA Groovy inspections?
Answer: Both CodeNarc and IDEA analyze Groovy code for potential bugs and problems. They both work by constructing an Abstract Systax Tree (AST) for source code and then analyzing the contents of the tree. IDEA's inspections are more advanced than CodeNarc's because they have invested more in type inference. Even though the Groovy language is dynamically typed, you can still reasonably know the types of objects. The IDEA code inspections for Groovy (and the refactorings as well) are mature, consistent, and very helpful. CodeNarc is newer and smaller, but growing rapidly. We just put out version 0.12 that contains almost 150 static analysis rules and expect 0.13 in January. Chris Mair (the lead) and I are both big IDEA users, so the CodeNarc rules don't often duplicate IDEA rules. Our type inference is much weaker but we are expanding. For example, 0.12 contains a rule that analyzes return paths and checks for null return values on functions that also return Collection types. The recommendation here is that you should just return an empty collection instead. We infer a lot of types and analyze return paths, and it's really fun code to write, and hopefully useful too! You can try CodeNarc out in your browser because we have a GAE front end for it. Also, there is a request to add CodeNarc support to IDEA if anyone is inclined to vote on a ticket http://youtrack.jetbrains.net/issue/IDEABKL-5903.
Question: I know you also speak at JUGs and Conferences. Do you have anything planned for 2011?
Answer: Absolutely. I just submitted a whole bunch of abstracts for 2011, so hopefully they'll be accepted and I'll be on the road. The only thing booked so far is SDC 2011 in April, 33rd degree in April, the GR8 Conference in May, UberConf and a few NoFluff shows in July, and I expect to be at JAX.de, Confess, and GeeCon as well. If anyone wants a JUG speaker than please contact me at email@example.com. I definitely want to get out and travel a little more next year. GR8 in Denmark was just announced on the web, and it is expanding this year to be several more days and include several tracks. If you're interesting in a Groovy conference then GR8 is definitely the one to be at. I would start pestering your boss about going as soon as you can.
Question: What do you do in your free time?
Answer: I find that an honest answer to this question is horribly boring. Does anyone really want to hear about how I spent Wednesday night running a spell checker against an open source project? Not likely. Let's just leave this question unanswered.
Thank you for your time and best wishes for the coming year!
Opinions expressed by DZone contributors are their own.