Well, we basically agree. I grant that there's a better case for numbers being immutable than buses. However, I would say that number "objects" are not meant to

Well, we basically agree. I grant that there's a better case for numbers being immutable than buses. However, I would say that number "objects" are not meant to model real world numbers as objects per se. Because, sure, you don't morph a 3 into a 4 in the real world, but in code you don't generally require numbers as objects for the purpose of representing such constants. Rather, they are variables with some meaning. In other words, you don't generally need: BigDecimal three = new BigDecimal(3); but BigDecimal sum = new BigDecimal(0); Followed by some operation(s). Sure, depending on naming, you can create confusion with mutable numbers, but that's true for immutable objects as well. At the end of the day, I am not saying that immutables have no use and one immutable class outright destroys your OO design. I am saying that there is a tension that exists between the two that can easily be seen if you envision a design with 100% immutable classes in the context of OO's raison d'etre. Bringing it back to the OP, my bigger point was that all of the work involved and "side effects" of layering on immutability are an example of how people assess OO's success through the lens of things that were later added, but were not an intrinsic part of the OO paradigm in the first place.