Tech talk on 'The state of Scala code style and quality' by Jaime Jorge

[Chan Ag]

Heya, All.

There is a Scala tech talk event happening in Los Altos, CA, on the 8th of December. There will be two talks --

The state of Scala code style and quality by Jaime Jorge
TreodeDB (an open source db that's written entirely in Scala ): Replicated, sharded, transactional by Christopher Olson

I'm very interested in the first tech talk (How is Scala code evolving, the state of Scala code and quality).

Is any other JavaRancher attending this event?

Chan.

[Junilu Lacar]

I wish I could attend but it's a 3-day drive from the middle of Ohio. I can tell you the state of Scala code based on my limited view. It's appalling. It's a jumble of case classes and poorly-factored, non-object-oriented, non-functional, just-get-it-done-and-fix-it-later gob of disgusting gastrointestinal by-product.

Now let me tell how I really feel...

I think programmers who would venture into Scala would do well for themselves and especially for others to really understand the responsibility that comes with the great power that comes with wielding a language like this. If you can't write well-factored, well-tested code in Java and you don't have a good grasp of how modularization and loosely coupled code makes for better programs, then please do everyone a favor and stay away from Scala.

[Joe San]

The reason being that Scala is a beast of language features. When there is n ways of producing a piece of code with Java, there are n power n ways of doing that in Scala. The only thing that I benefit in Scala is working with collections and using closures!

[Junilu Lacar]

Joe Harry wrote:The reason being that Scala is a beast of language features. When there is n ways of producing a piece of code with Java, there are n power n ways of doing that in Scala.

Right. And it seems that since there n ways to write ugly Java code, programmers who jump right into Scala find n**n more ways to write even uglier Scala code. Can you imagine having to decipher and maintain a 100+ line Scala function with multiple case classes and multiple calls to functions in other classes? It's a nightmare, I tell you. Now multiply that n**n and imagine having to do this with an entire application and you'll have an idea of my life as the unwilling heir to a 1st generation distributed Scala application.

[Joe San]

If Java was fast enough and evolved at the pace at which C# evolved, I would have never ventured out to another language for the JVM.

Like you rightly pointed out, I could write an entire application in a single Scala file which is sort of alarming!

[chris webster]

Well, as another relative newbie to Scala, I have to agree that it can be pretty challenging to figure out the right way to do something when the language offers so many imaginative ways to do it wrong. But you can write bad code in any language, so that's hardly unique to Scala. Part of the problem is that it's still early days for Scala in the wider industry, and we still need to learn the idioms of this hybrid OO/FP approach for regular application development. Another part of the problem might simply be that we need to choose an OO or FP approach and stick to it, just to cut out half of the options Scala provides for screwing things up!

On the plus side, when you get it right, Scala offers some really nice and elegant solutions to a lot of problems, as well as getting rid of a lot of the kruft that make Java such a pain to write. FP can also help eliminate the need for a lot of common patterns in Java (prior to Java 8 at least) e.g. check out Functional Programming Patterns In Scala And Clojure.

Anyway, I still remember the trauma of working with J2EE and EJB 1.1 over 10 years ago, so I'm happy to take my chances with Scala rather than Java for the time being!

[Junilu Lacar]

chris webster wrote:we still need to learn the idioms of this hybrid OO/FP approach for regular application development. Another part of the problem might simply be that we need to choose an OO or FP approach and stick to it, just to cut out half of the options Scala provides for screwing things up!

I don't see OO and FP being mutually exclusive in Scala. If anything, I would lean towards an OO mindset in general and find the specific places where things like case classes, closures, functions and tail recursion make the code more expressive and elegant. I don't see Scala's many features as things that are provided to screw us up either (I know you probably didn't mean it that way). Having more options is great; it's a lack of understanding of which options to choose that screws us up. As Mark Twain once said, "It ain't what we don't know that gets us in trouble, it's what we know for sure that ain't so."

[chris webster]

Junilu Lacar wrote:I don't see OO and FP being mutually exclusive in Scala.

No, not really. But when you're just trying to figure out how to make Scala do X, it can be confusing to encounter tutorials or other reference materials that offer so many different approaches, some based on OO and others on FP. So I think it can still be helpful to decide your own emphasis - primarily OOP or mainly FP - in how you approach Scala initially, so that you can at least make sure your own code is reasonably consistent and maintainable from the outset. I get the impression that plenty of people start with Scala as "a better Java" i.e. mainly OO, but gradually evolve a more functional style as they become more comfortable with the language.

But, as you point out, whatever approach people take, there's no getting around the need to apply the same good practices as for any other programming language.

[Junilu Lacar]

Seems I'm always relating programming with martial arts and it always seems to go back to Shu Ha Ri.

Problems always arise when people rush to apply a variety of techniques before they've really understood the proper context in which they should be applied. I see this all the time when I work with beginners in the dojo and likewise see it when I review Scala code written by programmers who seem all too eager to use case classes. I keep mentioning case classes because they're everywhere I look in the Scala code I inherited and it's not pretty at all even though I know that when used properly, they can be quite elegant.

[chris webster]

Well, it's 30 years since I last bowed out of the dojo so I guess I've missed out on some of the more philosophical aspects of bushido! But what's wrong with case classes? I agree that you need to organise them sensibly, rather than scattering them randomly through your code. But that's true of most things in Scala, because the code layout allows so much more flexibility than Java in terms of where you put stuff: you can write spaghetti very easily.

So what other problems do you see with using case classes?

[chris webster]

chris webster wrote:...what's wrong with case classes?...

OK, apart from the issues listed here! FWIW I still think the benefits often outweigh the limitations for my purposes so far - I'm trying to stick to the functional end of the FP/OOP spectrum and don't really use inheritance in my own classes. But it's good to know the pros/cons of all these new toys.

[Junilu Lacar]

Here's an abuse case that I see all over the code in a project I inherited (names changed to protect the guilty):

foo match {
  case bar: Baz =>
    // ...

  case bar: Baaz =>
    // ...
    val wtf = blah match {
      case Qux => 
        // more crap
      case Quux => 
        // you know what follows...
      case Quuux => 
        // give you 3 guesses...
    }
  case bar: Baaaz =>
    // ...

  case bar: Baaaaz =>
    // get the idea yet?

} // FML...

This is basically a huge if (foo instanceof Baz) ... else if (foo instanceof Baaz) ... else if (...). Also notice the little nested match that's thrown in there for good measure. Yes, the code truly is like this. This is not even whitebelt code. It's like somebody learned about case classes and pattern matching and started wildly swinging that like a sledgehammer it at every single problem they met.

I open practically any file in this project and this is what I see. This particular file has three functions in it and they're all like this. And this is just a small one with about 200 lines in it! Aaaarrrrrghhhh!!!

[chris webster]

Well, those aren't specifically case classes, just classes used inside a really nasty nested match...case expression where (as you point out) it's just checking if foo is an instance of Baz etc. So it looks like no case classes were harmed during the making of that code snippet. And in fairness to Scala, I get warning messages if I try that kind of thing with simple Baz and Baaz classes (i.e. not case classes), because Scala's type checker will try to figure out what type you're feeding into the matcher in the first place. So if foo is really a Baz, you get this warning from the line checking if it's a Baaz:

- fruitless type test: a value of type Baz cannot also be a Baaz

However, if Baaz is a subclass of Baz, then you don't get this warning, but you still only execute the first matching case branch. Pretty much the same as if you did "if (foo instanceof...)" in Java i.e. the nested logic is the real problem, not the pattern matching.

So yes, you can sort of get this kind of thing to run in Scala, but it's stupid and messy and Scala will at least try to let you know you're being stupid where it can spot this.

I still reckon case classes, match/case expressions, pattern-matching and de-structuring are all really useful in Scala - in the right context of course. After all, you can write plenty of stupid and messy code in Java/Python/C++ etc - I have basically banned myself from ever using C/C++ again because of the havoc I can create with it! A screwdriver is a useful tool for the right job, but that doesn't stop some people sticking it in their ears.

[EDIT]:
Just spotted that Martin Odersky talks about "isInstanceOf" checks on p.281 of "Programming In Scala" (2 ed) and says:

it is not encouraged practice. You are usually better off using a pattern match with a typed pattern."

His example of a pattern-matcher using typed patterns is:

def generalSize(x: Any) =  x match {
    case s: String => s.length
    case m.Map[_, _] => m.size
    case _ => -1 }

[Joe San]

Junilu Lacar wrote:Here's an abuse case that I see all over the code in a project I inherited (names changed to protect the guilty):

foo match {
  case bar: Baz =>
    // ...

  case bar: Baaz =>
    // ...
    val wtf = blah match {
      case Qux => 
        // more crap
      case Quux => 
        // you know what follows...
      case Quuux => 
        // give you 3 guesses...
    }
  case bar: Baaaz =>
    // ...

  case bar: Baaaaz =>
    // get the idea yet?

} // FML...

This is basically a huge if (foo instanceof Baz) ... else if (foo instanceof Baaz) ... else if (...). Also notice the little nested match that's thrown in there for good measure. Yes, the code truly is like this. This is not even whitebelt code. It's like somebody learned about case classes and pattern matching and started wildly swinging that like a sledgehammer it at every single problem they met.

I open practically any file in this project and this is what I see. This particular file has three functions in it and they're all like this. And this is just a small one with about 200 lines in it! Aaaarrrrrghhhh!!!

Which ever person that wrote that code would have done the same thing if he were to implement in Java. The only difference being that he would have used if else-if ladder. In my sense at-least these case blocks are a lot better than if-else-if junk!

[Junilu Lacar]

Joe Harry wrote:Which ever person that wrote that code would have done the same thing if he were to implement in Java. The only difference being that he would have used if else-if ladder. In my sense at-least these case blocks are a lot better than if-else-if junk!

I'm not so sure about that. In Java, it's a fairly well-known rule of thumb to avoid using instanceof since you're probably not using inheritance and polymorphism properly. I've seen some very bad Java code in my day but still don't run into as many cases of instanceof abuse as I have in this Scala code. In this instance with case classes and pattern matching, these programmers seem to have taken them as Scala's license to throw caring about inheritance and polymorphism to the wind and just go dog-got-out-of-the-kennel wild.

[Junilu Lacar]

chris webster wrote:Well, those aren't specifically case classes, just classes used inside a really nasty nested match...case expression where (as you point out) it's just checking if foo is an instance of Baz etc.

Oh yes, they are. I've obviously changed the names but all of them are declared as case classes in this code base. The kicker is that they're not even named like objects. The names are all verbs, e.g.

case class Create(...)
case class Update(...)
case class Merge(...)

Yes, those are the actual names used in the code. Ugh.

Hopefully, now you'll get an idea of where I'm coming from with my ranting about this kind of Scala code.

[chris webster]

Junilu Lacar wrote:
Oh yes, they are. I've obviously changed the names but all of them are declared as case classes in this code base. ...
Hopefully, now you'll get an idea of where I'm coming from with my ranting about this kind of Scala code.

OK. My point was just that this code is bad because of the way it's structured, and exactly the same problems exist if you use regular classes (as I did when trying it out). Case classes in themselves are not the problem here, even if the programmer is (mis-) using them in this rat's nest as well. Either way, I think Joe's right - this would be just as ugly in Java.

Maybe the real problem in your example isn't that the person who wrote it is bad at Scala, or even that Scala somehow makes them write bad code, but simply that they're bad at programming!

[Junilu Lacar]

chris webster wrote:Maybe the real problem in your example isn't that the person who wrote it is bad at Scala, or even that Scala somehow makes them write bad code, but simply that they're bad at programming!

You'll get no argument from me about that. You asked about the state of Scala code and I just gave you my limited world view

Don't get me wrong, I like Scala a lot. It's very powerful and there's a lot of responsibility that comes with wielding that kind of power so I'm doing everything I can to learn how to use it properly.

[Scott Shipp]

This is one of the things I am fretting over lately. It seems like there are more rigid walls around how to implement things in Java, which has the end result of improving maintainability. In Scala, there are certain things that seem messy. The standard practices also lend themself to unmaintainable code. For example: one letter variable names. Yes, it is functional, but what is the amount of time it's going to take to grok that for the junior developer your company hires in three years to maintain your code, as opposed to the same code in Java where readable variable names are emphasized. Also, expressions like "_ + _" ... newbie devs are going to sweat once they inherit the legacy Scala systems of tomorrow!