I've seen this exact pattern a dozen times when developers move from Java or C# to Scala. They know the syntax, but they're still thinking in "statements." They treat Scala like a slightly fancier version of Java, and that's usually where the friction starts.

def getUserStatus(age: Int): String = {
  var status = "" // Using a mutable variable to hold the result
  
  if (age < 18) {
    status = "Minor"
  } else if (age < 65) {
    status = "Adult"
  } else {
    status = "Senior"
  }
  
  status
}

The Statement-Based Mindset

At first glance, the code above works perfectly. It compiles, and it returns the correct string. But it's fighting the language. The developer is using a var (mutable variable) to "capture" a value across several branches of logic. This is a carry-over from languages where if and match are statements—instructions that tell the computer to do something, but don't return a value themselves.

When you write Scala this way, you're introducing unnecessary mutability. In a larger method, that status variable could be accidentally changed by another piece of logic, making the code harder to reason about and nearly impossible to parallelize safely.

Embracing the Expression-Oriented Design

The core of Scala's design philosophy is that everything is an expression. In Scala, an if/else block isn't just a control flow tool; it's a value. It returns something. Once you realize this, you can delete the mutable variable entirely.

def getUserStatus(age: Int): String = {
  if (age < 18) "Minor" 
  else if (age < 65) "Adult" 
  else "Senior"
}

See the difference? I'm not "setting" a variable; I'm defining the result of the function as the result of the if expression. This is cleaner, safer, and it's exactly how Martin Odersky (the creator of Scala) intended the language to be used. The fix works because Scala evaluates the entire block and returns the final value of the chosen branch.

The "Scalable" Marriage of OO and FP

To understand why this matters, you have to understand where Scala came from. The name "Scala" actually stands for Scalable Language. Odersky wanted to create a language that could grow with the problem, bridging the gap between two worlds that were often seen as rivals: Object-Oriented Programming (OO) and Functional Programming (FP).

• The OO side: Every value is an object. Every operation is a method call. This gives you the structure and encapsulation needed for massive enterprise systems.
• The FP side: Functions are first-class citizens. Immutability is preferred. Expressions are king. This gives you the mathematical correctness and conciseness needed for complex data processing.

I like to think of Scala as a language that gives you a toolbox for both. You aren't forced into a "pure" functional world like Haskell, nor are you trapped in the rigid class hierarchies of early Java. You can use a class to organize your domain and then use a functional pipeline to process the data inside that class.

Why This Hybrid Approach Actually Matters

If Scala were just "Java with better syntax," we wouldn't have things like Option, Either, or the powerful pattern matching we've used in previous lessons. These features exist because the design philosophy prioritizes type safety and immutability.

When you're reviewing your own code, ask yourself: "Am I using a variable to track state, or am I transforming data?" If you're doing the former, you're probably writing Java in a .scala file. If you're doing the latter, you're leveraging the actual philosophy of the language.

📋 Practical Task

Refactoring a Stateful Order Processor

You've inherited a piece of code from a developer who is very comfortable with imperative programming. The following method calculates a discount based on order totals and customer loyalty, but it relies heavily on mutable state and statements. Your task is to refactor this to align with Scala's design philosophy.

def calculateDiscount(total: Double, isLoyal: Boolean): Double = {
  var discount = 0.0
  
  if (total > 100.0) {
    discount = 10.0
  } else {
    discount = 0.0
  }
  
  if (isLoyal) {
    discount = discount + 5.0
  }
  
  discount
}

Requirements:

1. Remove the var discount entirely.
2. Refactor the logic so that the final value is the result of an expression.
3. Ensure the function remains pure (no side effects, no mutable state).
4. (Bonus) Try using a match statement or a concise if/else expression to handle the base discount before adding the loyalty bonus.