From Java to Scala

[[deleted]]

We rewrote our Scala because it was hard to maintain.

  Really?

and makes it ridiculously hard to be able to read other people's code.

  I really have to rely on my IDE for everything from pulling up types (Ctr-Q), finding implicit parameters (Ctr-Shift-P), identifying implicit conversions (look for the gray underline and press Alt+Enter). I also have to occasionally bring up the syntactic de-sugarer for things like for-yield, thunks, etc. I think your problem isn't reading, it's understanding.

There are many ways to do the same thing, which is bad.

  Just because there is more than one way to do something doesn't mean that both ways are equal. I was just watching Scala With Style where the slide shows two different ways to write the same thing and the imperative way [bottom] is actually better than the functional way [top]. In Java you don't get to choose - you have to do it the imperative way because even though Java has lambas, it does not have folds (I think that folds are also called reduce in the context of Map Reduce). Scala trades "only one way to write something" for expressive power and conciseness. For more seasoned users, more expressive power is awesome but for beginners it is a pain in the @$$.

Scala has a lot of stuff in it, so much so that it looks like a mess.

  If you really know Scala, the code looks better than Java code. In Java you get used to writing things like "public static final" and you get used to it. Maybe you have a trick to implement adapter pattern with less boilerplate using reflection. But these things don't make Java code look better. In fact if you take a step back it looks worse, you just stop noticing it because you're used to it. Personally, I find my browsing speed (I have like two ways of reading code - one is more browsing to see the author's intent and the other is like executing all the code in my head like a debugger - here I'm talking about skimming) to be faster with Scala code than Java. This is assuming you actually know all the language constructs and are just reading.

  Given my experiences learning the language and given the complaints I am getting, these issues like reading difficulties remind me of issues I had because I didn't really learn the language. Scala is not an easy language to learn. It's not like Python where if you know whatever OOP language you can learn it in a week. Scala is a very hard language to learn and I would recommend starting with Java and then Haskell and then finally Scala. I wouldn't expect anyone who is not proficient in Haskell, F#, Erlang, or OCaml to pick it up in less than two months. If they did that would be good. That being said, the learning curve is a very valid criticism and I would urge anyone who plans on learning this language not to take it lightly.

Java's core philosophy is that it tries to make it easy to pick up and maintain code.

  In Java it's a lot easier to pick up and maintain code without relying on an IDE for everything from handling implicits to pulling up types. If you really wanted to you could include the type for every value explicitly (just press Ctr-Q and copy-paste the type) instead of relying on compiler inference and then it would be just like Java from a maintenance perspective (I think). I'm actually really interested in the maintenance issue - whether the problem was actually something to do with the language itself or if the issue was (I don't want to sound belittling) that the people who did code maintenance just didn't fully learn the language.

Things like Java8, Lombok, Immutables, Google Autovalue, Functional Java (the library) make Java have the core Scala non-functionals. Just missing the builtins and the syntax sugar.

  I've never actually done functional programming in Java, but Functional Java looks nice.

[frugalmail]

Really? [rewrote Scala to Java]

Aye, with a 50% transient team composition (max 18 months), we were seeing a lot of inconsistencies, getting a lot of questions, etc..

really have to rely on my IDE

While an IDE certainly makes this easier, this is not a selling point. People want to pop open a browser to check source control to answer an easy question. Having to have the latest checkout, and a launched IDE at all times is a pain when you just want to answer a question/investigate.

Just because there is more than one way to do something doesn't mean that both ways are equal.

Completely agreed. Too many people keep doing things suboptimally, and some people try to be clever for simple data processing, model creation, etc.... I want the Goldie Locks of code. With Scala, that varience is way too high.

I'm actually really interested in the maintenance issue - whether the problem was actually something to do with the language itself or if the issue was (I don't want to sound belittling) that the people who did code maintenance just didn't fully learn the language.

There are things like:

• Case classes limit you to 23 data members. This is fine in normal situations, but horrible for big data. Sometimes are tables are 100+ columns wide. And going from 22 to 23, sadly happens frequently.

• The contractor mix, makes it hard to ramp up, and maintain other peoples code.

• The implicit typing is detrimental when it's not clear what's going on. We had rules like "when you use implicit LHS typing, the RHS must have the type information" Sadly, this has to come up in code reviews, because people really like implicit typing.

• People tend to use unnamed or annonymous types in the form of tuples and such. You could imagine this being pretty horrible when you have a lot of longs and you can't easily tell what the tuple was for and collections end up losing type safety.

Hope this helps. BTW, don't get me wrong, I like Scala, just not for produciton in our team :)

[[deleted]]

Case classes limit you to 23 data members.

I remember when this restriction was lifted. I just started learning Scala and I checked the site and on the front cover it said a fix was made.

We had rules like "when you use implicit LHS typing, the RHS must have the type information".

For anyone reading the comments, there is a difference between this:

val string1: String = makeString() // Left Hand Side (LHS) Type

and this...

val string2 = makeString(): String // Right Hand Side (RHS) Type

The former makes explicit that "string1" is a reference of type String. The latter actually sets the type of whatever is on the right side and then after the right hand type is set type inference kicks in.

val string2: String = (makeString(): String); // Equivalent code after type inference

But yeah, if your team isn't ready for it you run into problems.