Why I prefer Scala over Groovy

Over the last couple years I've had the opportunity to develop software in Groovy and Scala. Now when coding in Java I always feel like it is so verbose, not a good use of my time, and just down right painful. Programming in Groovy or Scala is worlds better than Java (version 6). I want to briefly give an overview of both Groovy and Scala and why I prefer Scala.

A few benefits of both Groovy and Scala:

• Closures
• Functional Programming
• Built in Singletons
• Concise Syntax
• Traits/Mixins

A few benefits of Groovy:

• Dynamic language
• Can easily test private methods
• Seamless integration with Java libraries
• AST Transformations

A few benefits of Scala

• Static language
• Pattern Matching
• Options
• Immutability built into language

I find that Groovy is really just a better syntax for Java with a little functional programming sprinkled in. Groovy has some AST transformations which allow you to create singletons however it does not allow for constructors. Groovy does not do anything to allow you to easily write multithreaded and functional code without side effects because it promotes POJOs with mutable state. If you try to refactor dynamic Groovy code you will not get a lot of IDE help and will have to rely on tests to catch everything. If I'm trying to figure out what methods are available on a Groovy class reference by a def then I will need to actually go and find the type which leads to a lot of switching back and forth. I also find people creating interfaces which don't specify proper parameter types or return types on the methods. I'm sorry but I don't want to have to dig into the code or tests to figure out how to make a call. Groovy also provides you a convenient question mark (?) operator which allows you to not have to do null checks however I find they litter the code.

Scala is harder to learn if you already know Java but promotes a different programming paradigm (a better one). Scala is another programming language and not just better syntax on top of Java so it does has a bit of a learning curve. Scala gives me built in singleton support with it's object type. Immutable object and collections are first class citizens in Scala language and are easy to create and work with. Immutability gives me the ability to not have side effects when doing functional programming and writing multithreaded code. It also makes immutable message passing in Akka easily implemented. I get good IDE refactoring and method suggestion support for Scala. With functional collection mapping and Scala's Option construct it eliminates the possibility of null pointer exceptions. Pattern matching gives me the ability to quickly react to and transform immutable messages.

One thing in Scala which may be a gotcha is the integration with Java packages like hibernate is not the seamless because they expect immutability. However there is usually a replacement Scala library or different way to do the same thing which works just as well or even better. One of the things I hear puts people off of Scala is IDE support but I use IntelliJ Idea and the support is very good.

We use Maven so there is always a plugin to mount in your POM for language support. One of the valid complaints I have for Scala is that it compiles quite slowly. I'd prefer the slow compilation over getting exceptions at runtime/testing time.

Reactive programming is the new thing which is not blocking and holding onto threads when you don't have to. I believe Scala is much better suited for this with for comprehensions used the Spray, Play, and Akka frameworks.

Both Groovy and Scala have trade-offs but in the end Scala offers me more so I prefer Scala.

Pair Programming

Pair programming is something that I've been practicing for over a year now. I had never heard of pair programming before working for my current employer. I remember discussing it in my interview and being nervous as to whether I would really like it every day. Previously I had collaborated with other developers but it was a brief on-demand activity and wasn't a daily activity.

I pair for about six hours every day with a couple hours for personal improvement and administrative tasks. We change pairs every few days so we get a chance to work with everyone. One person will drive and the other person will be the navigator. However at any point in time we may switch roles. Sometimes we choose to not too pair because the task doesn't lend itself to pairing. Sometimes we have team members gone so there are an odd number of people so we'll have one pair and then the odd person out will just develop on his/her own.

Benefits of Pair Programming
Rounding out of skills	I've learned so much by being a navigator. Lots of little things which make developers more efficient like shell commands, shortcuts, and alternative ways of doing things. I've learned a lot about designing and implementation of code and how people have different approaches. The ultimate shadowing experience would be to pair a fresh developer with a more experienced developer.
Automatic code reviews	Never again do I have to worry about having formal code reviews and getting the code refactored after the review. The navigator will automatically suggest things as we go along and refactor as we go which is much easier. Also the navigator writes down a list of things to think about and possibly refactor in a separate commit so we don't try to do too much in any one commit.
Team Building	The more we pair the better we work together and we learn what the other team members have specialized knowledge in. We also tend to grab lunch with the person we are pairing with which gives you a chance to socialize and get a chance to know how them better.
Better Quality	The navigator usually keeps the driver honest and follow proper practices like test driven development and resist the urge to just hack out some code. The navigator can usually spot some outright errors while the driver may be too concentrated on coding and overlook them.
Better Communication	While driving I usually find myself just generally explaining the approach I'm taking. It's a much different skill to be able to explain what your doing to another person. Then as the navigator sometimes if I don't understand the approach or think there might be a better one I'll ask the driver to explain his/her approach which generally leads to some sort of design discussion.
No Single Person Projects	Lets say that John is the only developer who has worked on Project X developing it. This happens on small or old projects which nobody want's to work on them or you have regular turnover. While it's great John has taken on Project X it is also a huge risk if nobody else understands the code. If John get's hit by a bus (or a more positive view he wins the lottery) or leaves the company then the next person who takes it over can be in for some huge pain. Not only the next person but what if the person who takes over for John can't address issues and the system goes down. Then it becomes a business risk depending on the business impact of not having access to Project X. These single person projects also seem to get proper attention and degrade quickly in my experience. These single person projects also give John an elevated feeling of importance because now he's a subject matter expert. By pairing you reduce the risk to the business and to the next developer to take over the project. If John was paring with Brandon and John leaves then Brandon can continue on without him and they should have about the same relative knowledge. Then Brandon and Jim can be the new pair and the cycle continues. Also by pairing I believe you can delay and possibly prevent the degradation and neglect aspect which would eventual lead to some sort of re-write.
More Efficient	It may seem counter-intuitive to have a developer only spend half his time coding which would lead to a fifty percent drop in productivity. This is a rather naive notion because developers do not just develop new code. They also design, fix bugs, mentor, and review code. These activities also need to be done. If you are cutting corners and not doing all these activities then you are getting a false sense of productivity and in the long run you are spending more time and money than you would otherwise. When you pair these activities are an integrated approach instead of an after thought or a step by step approach. Pairing leads to a better design and less defects. This means the apparent drop in productivity early in development is offset by using less time for testing and releasing bug fixes. A better design it leads to the ability to respond to change and incorporate new features without a huge refactoring. A defect that never makes it way to testing or production environments is the cheapest to fix. In considering all the activities a developer does and not just developing new code that you are actually making better use of everyone's time by pairing.

The only downside I can think of is pairing kind of requires both developers to be co-located. I don't know how it would be possible to pair program if you were working in a different locations. If somebody has a good approach for this let me know.

Surprisingly I enjoy pairing and I'm not sure I'd ever want to go back to not pairing. If you can pair then I'd strongly urge you to try it for a year and see how it goes.