Equality Broken in Scala

Scala is a programming language that heavily relies on the JVM platform. While there are many reasons to consider this to be an advantage for Scala, it also comes with many downsides given the language design choices. One big problem with Scala is equality, i.e., checking if values are equal.

I consider equality (the == operator) in Java broken because it compares objects, not values (Java is an object-oriented language) for their reference equality, i.e., if they are the same objects in memory. This is a big minus as it forces the programmer to think about low-level programming, which reference management is about. A brief and good demonstration of how equality is broken in Java is given in a blog post Problem of comparing wrapper objects with == operator.

Scala’s authors decided to inherit this brokenness from Java, which makes equality in Scala equally broken. For example, in Scala it is possible to compare an integer 1 to a string “abc”. There are some attempts to make equality in Scala less broken, but the problem won’t go away because of a requirement to maintain backward compatibility. In other words, there is a requirement to stay broken. As Odersky put it, “Scala prides itself of its strong static type system”, yet it cannot get value equality right.

Equality is a fundamental concept in programming. Equality is broken in Scala, which makes software engineering and development in it a painful undertaking. Scala allows for comparing apples and oranges, which is obviously ridiculous.

On the other hand, Haskell features a quite different type system. It seems to me that it brings sanity to programming when it comes to equality. In Haskell, equality is defined via a type class:

class Eq a where
  (==) :: a -> a -> Bool
  (/=) :: a -> a -> Bool

In other words, in Haskell you can test for equality of values of the same type only, i.e., an attempt to compare apples to oranges won’t compile. Therefore, with Haskell you have no funny attempts to fix equality with new operators such as === or even ====!

This is an obvious departure from what I wrote a year and a half earlier in a post titled I’m into Scala and in a post three years earlier, Going with JVM Languages.

2 thoughts on “Equality Broken in Scala

  1. I’ve started to see Scala’s weaknesses. If I had to choose an object-oriented language to work with, it would be Scala as it is far more advanced and pleasant than e.g. Java. But who says an object-oriented language is the way to go? Scala is trying to be both object-oriented and functional programming language with a static type system, but mixing subtyping and parametric polymorphism makes it harder to leverage advantages of the latter. In my opinion that wasn’t such a good language design decision.

    As I hinted it in this post, I’m starting to dislike its type system for allowing to break referential transparency. For example, it is possible that at one point in execution a == b holds, but not at some later point because you can mutate a or b or both. This is a needless energy drain for a programmer as it forces them to build a huge mental map of what can change and when, instead of being able to rely on a simple invariant that a equals b at all times.

Leave a Reply

Your email address will not be published. Required fields are marked *

IMPORTANT! To be able to proceed, you need to solve the following simple math (so we know that you are a human) :-)

What is (5 - 4] + 200?
Please leave these three fields as-is: