为何函数式语言（如Kotlin、Scala）采用对象实现数据类型？

Great question! This is a common point of confusion when moving from imperative languages (think Java’s split between int and Integer) to functional ones like Kotlin or Scala. While operator overloading and polymorphism are nice perks, the real reasons run much deeper into the core of functional programming principles. Let’s break them down:

1. First-Class Citizens & Functional Abstractions #

Functional programming revolves around treating all values as first-class citizens—meaning they can be passed as arguments, returned from functions, stored in collections, and manipulated with higher-order functions.

Primitive types (like Java’s int) break this uniformity: they can’t implement interfaces, can’t have methods attached, and don’t play nicely with abstractions like functors, monads, or type classes. For example, if you want to use a map function on a numeric value (say, converting an Int to a String), an object-based Int (like Scala’s scala.Int or Kotlin’s Int) can directly support this via extension methods or built-in interfaces. Primitives would require awkward wrapper logic to fit into these patterns.

2. Unified Type System Simplicity #

Functional languages prioritize consistency and minimal cognitive load. Having a single model where every type (even numeric ones) behaves like an object eliminates the need to juggle between primitive and wrapper types.

No more wondering when to use int vs Integer, or dealing with unexpected NullPointerException from unboxed values. Languages like Kotlin handle boxing/unboxing automatically under the hood, so you get the performance benefits of primitives when possible, without sacrificing the object semantics that make functional code clean and predictable.

3. Type Classes & Ad-Hoc Polymorphism #

A cornerstone of functional programming is ad-hoc polymorphism via type classes (think Scala’s implicits or Haskell’s type classes). These allow you to define behavior that can be applied to any type that implements the class—even numeric types.

For example, you could define a Sum type class that lets you add any two values of the same type. With object-based numeric types, you can easily implement this for Int, Double, etc. Primitives would require special-case handling, breaking the elegant abstraction that type classes provide.

4. Immutability & Safety #

Functional programming emphasizes immutable data to avoid side effects. Object-based numeric types naturally enforce immutability (most functional languages make these types read-only by default).

Primitives, while technically immutable in value, don’t encapsulate this behavior in a way that aligns with functional principles. When you pass a primitive around, you’re copying its value, but objects (even value-semantics objects like Scala’s AnyVal) fit better into patterns that track and preserve immutability across your codebase.

Bonus: Operator Overloading & Polymorphism Are Side Effects #

Don’t get me wrong—being able to overload operators (like + for custom numeric types) or use polymorphism with numeric values is useful. But these are secondary benefits enabled by the object-centric type system, not the core reason functional languages choose this approach.

内容的提问来源于stack exchange，提问作者Theis F. Hinz