Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I work in an organization that does extensive Java development. Our group is small with a short-lived project, agile development charter. We will leverage existing QA resources of other groups, and potentially contribute code to customers and partners.

The primary arguments against Scala development have been:

  • QA will need Scala experience
  • Customers will need Scala experience

My experience has been that Scala is generally easier to read than Java with minimal exposure to the language, and that the ability to use existing Java tools such as Junit would minimize negative impact to existing testing strategies.

I've estimated that development in Scala could be 25%+ faster than equivalent Java development depending on the problem. This is just a finger in the wind based on my personal experience. If anyone has evidence of efficiency increase, please share.

I would also like to compile a list of major benefits to using Scala over Java. Please share your favorites.

Thanks, John

share|improve this question

migrated from stackoverflow.com Apr 1 '11 at 18:41

This question came from our site for professional and enthusiast programmers.

    
This doesn't belong on StackOverflow; it should be posted on programmers.stackexchange.com –  Onorio Catenacci Apr 1 '11 at 17:13
    
Clojure is way better. –  Job Apr 2 '11 at 2:47
    
John, could you elaborate on why folks think either QA or customers would need Scala experience? –  Sean Corfield Apr 2 '11 at 3:14
    
Sean, the perception is that QA would then be forced to either read Scala code to ferret out problems, or write tests in Scala. True, they might need to read some code, but I personally think it's easier to read Scala than Java. Tests could continue to be written in Java of course. Many of our projects are kickstarted and potentially turned over to partners or open sourced. The management fear is that using Scala will reduce adoption by those communities. –  jxstanford Apr 2 '11 at 19:27
    
Following up on this. We were ultimately successful in getting most of our project done in Scala/Akka/Spray/Scalaxb/Scalaquery. It was a mostly wonderful journey. –  jxstanford Apr 3 '12 at 4:20
add comment

3 Answers

It's easier to actually do a project than it is to get permission to do a project.

Also, all the evidence from outside the organization is trivially deprecated by people who don't want to change. They simply say "that won't work here." (Or worse, "that won't work in the real world.")

You can't really amass enough external, indirect evidence.

However, if you actually do an actual project in Scala, the conversation is very different. You have a track record of success at a lower cost. No one can argue with that.


"Unfortunately we already went down the get permission route, and are now in a less than ideal negotiating position"

Not really.

If you think you're somehow constrained to continue asking for permission, you're essentially doomed.

The point is this: "It's Easier to Ask Forgiveness Than To Ask Permission".

Starting a project can be done any time, no matter what prior politics are (or are not) in place.

You just start the project. Even if you already asked and where rejected once (or a dozen) times.

When you are successful, you ask for forgiveness for being too successful.

share|improve this answer
    
Unfortunately we already went down the get permission route, and are now in a less than ideal negotiating position. If we had it to do over, we definitely would consider this approach. Now I think we'll just start holding Scala brown bags and user groups inside our company and try to infect other teams... –  jxstanford Apr 2 '11 at 19:34
add comment

Show don't tell - build something in Scala. I suggest testing your Java applications. Here's a post I did on setting up Scala Specs as a test framework for Java Maven projects: http://janxspirit.blogspot.com/2011/01/sneaking-scala-through-alley-test-java.html

People are usually comfortable with you writing tests however you like.

The only argument that will ever hold water for management in my experience is that you can get more work done in less time and that it will be higher quality work that costs less in ongoing maintenance. I suggest leaving arguments about the elegance of the language, its expressiveness etc to discussions with developers, not management.

Emphasize that you can use your existing Java libraries (think "leverage existing investment"). Also, if you use Spring or similar, think about Scala implementations of Java interfaces as a way to let those developers who want to try Scala do so without disrupting others.

Most importantly, build something and prove you can. I've taken to building web services in a few hours when the equivalent would have taken much longer in Java - think days. An example of how I've done this is here: http://janxspirit.blogspot.com/2011/01/quick-webb-app-with-scala-mongodb.html

I don't think external statistics will be very convincing, since a developer's ability to work more effectively in Scala than in Java really depends on the developer. But if you can prove it, then you'll definitely gain ground. Good luck!

share|improve this answer
    
Hi Janx, thanks for the comments and references to your blog posts. They are very cool. I was already working on a Scala/Vaadin/MongoDB project, so I've started to look at Scalata as well. Your advice is sound, and we hope to incrementally show more examples of the benefits of Scala. Testing is a good place to start. –  jxstanford Apr 2 '11 at 19:29
add comment

Most management types won't care about the benefits of Scala. They'll be risk-adverse and concerned about the availability of new programmers, the cost of training existing programmers, long-term support prospects for the language, etc.

Worse still, these are the same people who have overseen Java developers, and will believe they've done so very well. To suggest a change might be interpreted as a sleight on their ability.

The trick, then, is to (first and foremost) establish that Scala is fully interoperable with Java, you're building on past success and existing investment here. Then go on to cover how Scala improves on that by mitigating current risks: code maintainance costs, defects in production software, time to market/opportunity costs, etc.

If your manager is very people-oriented (and many are), then it never hurts to point out that Scala is considered a sexy language to be working with. Pretty code is unlikely to impress your manager, but working with something that'll help attract and retain talented developers is certain to attract further interest.

Scala isn't just an alternative to Java, it's a natural progression - the place you go when you've hit the top of your game and want to go further. Being able to make that migration just shows exactly how good you already are, so don't be ashamed to massage a few egos if necessary.

Finally, as already suggested, be proactive! Do something by way of a demo project and get other developers interested in it. A grass roots movement from several people is going to be far more persuasive...

share|improve this answer
    
All good advise. Thanks! –  jxstanford Apr 2 '11 at 19:34
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.