Why Scala? For Java Team Leaders

[John Mitchell]

Hi,

Thanks to Ken for an very interesting presentation on Macros.

On a slightly different topic, there was some discussion in the
meeting tonight around introducing people to Scala.

Here is a link to the slides I gave to my Java Team Leader.

https://docs.google.com/presentation/pub?id=103nUXojo8NuKsR9eC36-gm2077INHkHviRskdg7BM2c&start=false&loop=false&delayms=3000#slide=id.g2b19763_0_58

I have not had feedback from him yet. :)

Any comments welcome.

Cheers,

John

[Andrew Conway]

John Mitchell wrote:
> ... Here is a link to the slides I gave to my Java Team Leader. ...

Any comments welcome.

To me the biggest argument for Scala is that a Scala program is typically much shorter than an equivalent Java program (I have found about 2-3 times shorter in my personal experience, YMMV), with similar time spent per line developing and debugging. So it improves my productivity by a factor of 2-3. This is huge. That's the bottom line for me, and why I use it.

On the other hand, I think it is quite disruptional. Much less so for a Java team than a non-JVM language, but still significantly. While Scala does interface smoothly with Java, and calling third party libraries is fine, I have found mixed Scala/Java projects to be problematic in practice. I had a large Java program that I was intending to rewrite some of the more buggy sections in Scala, but it ended up with me rewriting the whole thing over the past few months. It has at least meant that I could directly compare the same functions written in Java and Scala.

Also I think the developer retraining is quite significant - Scala has lots of features and it takes time to learn them. The argument that you don't have to learn all of them to start is somewhat true, but doesn't work all that well in a team environment when one person is using them and you try to read and understand someone else's code.

But the increased productivity is huge.

Regards,

Andrew.

[John Mitchell]

Thanks for the benefit of your experience Andrew,

It sounds like I have, at least, two challenges introducing Scala to a
Java team.

Firstly it is very likely my team leader would want to try Scala in a
corner of an existing Java project, thus mixing Scala and Java. From
your experience this could prove problematic, which could turn people
off Scala. A new project solely in Scala sounds best, but it would be
hard to convince my team leader to go this way. :)

Secondly I will need to ensure the developers in the team learn Scala
at a similar pace to keep the code base understandable for all.
Or hold back some to the pace of the slowest; sure to induce
frustration.


Cheers,

John

[Andrew Conway]

The problem with a mixed Scala/Java project largely comes from use of the excellent Scala collections library, which is hard to use from Java.

I have heard that some organisations tried Scala at first by making test cases for existing Java code. At first this seemed to me - test classes tend to be trivial, and so you don't gain much. However, with more experience, I think this is actually a decent idea. The Scala code calls Java code - which tends to work better than the reverse. Also, test cases are significantly easier to write in Scala - I have found the ability to pass code as an argument of a function to be very useful. [ trivial example - if you are testing a computation, pass the computation to some test function as code. Then execute it twice, and make sure you get the same thing each time - and give the .equals function a test out while you are at it. ].

So test cases are a reasonable corner to start with.

Oh, and the interesting experience of learning a new language can give developers motivation to write more unit tests, which is usually hard to motivate.

Regards,

Andrew.

[Gary Khominsky]

I agree with Andrew.

I think, that most important point is to archive agreement that the Scala is _the_ implementation language. Then it is a time to discuss how to travel from point a) [Java] to point b) [Scala]. There are a lot of inputs that could effect your decisions, such as: project delivery schedule, code quality, team capability, management support and etc. Therefore you may start using Scala either for new development (component) or existing one.

However, my experience shows that the best way to start is to use Scala for testing (as Andrew mentioned below). It gives you a chance to start smooth integration Scala into your project and build up language skills and confidence.

Another alternative is to build _internal_ components/tools using Scala.  For example, you may want to build a small tool that would monitor your build servers (application server, database server, etc) and inform you if they are down.

Cheers,
 -- Gary K

--
You received this message because you are subscribed to the Google Groups "Melbourne Scala User Group" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/scala-melb/-/zDGYG-UhUFAJ.
To post to this group, send an email to scala...@googlegroups.com.
To unsubscribe from this group, send email to scala-melb+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scala-melb?hl=en-GB.

--
      -- Gary

A = X + Y + Z
      “If A is success in life, then A equals x plus y plus z.
       Work is x; y is play; and z is keeping your mouth shut.” - Albert Einstein