scala-logo-small

Prefer types over booleans

In a recent post I represented whether a TV was on or off as an enum in Java and case objects in Scala. Someone asked me why you would do either one when you could simply represent it as a boolean.

The same reasoning would seem to extend to any situation with two choices:

  1. Male/Female
  2. On/Off
  3. In/Out
  4. Active/Inactive
  5. Hot/Cold
  6. Light/Dark
  7. etc..

I have a rule:

prefer types over booleans

This post is about why.

Continue reading “Prefer types over booleans”

Why there aren’t enums in Scala

Why doesn’t Scala have enums like Java?

Java enums are a good solution for the wrong problem. Programmers who came to Java from C/C++ were sick of defining fixed sets of constants as integers and they reached for a solution that gave them the most obvious type-safe replacement. In other words, given an already-existing paradigm, they improved upon it, but they did not stop and rethink it.

You may not remember integer constants in C/C++. Let’s say a TV set had to have ON and OFF states. It would be represented somewhere as follows:

//C/C++
const int ON = 0;
const int OFF = 1;

And elsewhere:

private:
  int state = ON;

public:
 int getState() = {
   return state;
 }

“int getState?” But it should only return 0 or 1! There are no other states! We should not have ON/OFF represented with a type that allows for (generally) 2^32 states.

Given this state of affairs, Java’s language designers decided on the “enum” which looks like the following for the TV example:

enum TvState {
  ON, OFF
}
public class TV {

  private TVState state = TVState.OFF;

  public TvState getState() {
    return state;
  }
}

All of this makes perfect sense if fixed sets of integer constants has been your operating assumption for a number of years.

Except it doesn’t …

javalogo

How Java cut its throat and what we can do about it

There’s no end of people unhappy with programming in Java. It’s pretty obvious why, too. Even Java 8 is a total washout. The other day I had a very typical “find an item in an array” code I came across and I thought what the hell let’s just quickly refactor this to Java 8. Now this is not the exact code, it was much more complex, but it was something close to this in spirit.

Before, in Java 7:

String match;
for(String w : words) {
  if(w.startsWith("w")) {
    match = w;
  }
}

After, in Java 8:

Optional<String> possibleMatch = Arrays.asList(words).stream().filter(w -> w.startsWith("w")).findFirst();
    if(possibleMatch.isPresent()) {
      match = possibleMatch.get();
    }

I mean, that’s messed up is what that is. That’s downright disturbed, right there. The same thing in Scala is:

val match = words.find(_.startsWith("w"))

Now I’m as averse to easy answers as anybody, but at this point there’s just no denying it. If you want to do something about how Java cut its throat, I’m sorry to tell you your only option is to stop using it and move over to another language. I would recommend Scala. Kotlin also makes sense if you want to maintain compatibility and continue to run it on the JVM. Other people are switching to Go and Ruby. That’s my honest answer, because Java is working its way toward extinction. It’s a fossil in the making. It’s a dodo bird. Get out of Java if you can. Unless they decide to hit the reset button very soon, dispense with backward-compatibility, and rewrite the language, then there’s no more talking about it.