Smalltalk and Haskell share an interesting property: they support integer and rational calculations without arbitrary limits. Recording money in cents, 32 bits gives you ±$21,474,836.47, which is not a large sum of money to the industries in question. OK, 64 bits effectively solves that problem, but 64-bit arithmetic hasn't been available in "mainstream" languages all _that_ long. Of course Java provides BigInteger, but not using the same notation as ordinary integer arithmetic. If you are keen on code review, code that you *can* review is important. Smalltalk and Haskell share another property: higher order functions. I was profiling some Smalltalk code the other day and the call stack was regularly about 28 levels deep, thanks to lots of reusable control structures with little lambdas plugged in. It's not _that_ much of a stretch to see Haskell as a strongly typed version of Smalltalk, without the pervasive mutability. There's one enormous difference between Haskell and Smalltalk. If you push hard on a Smalltalk library, whether it's a free Smalltalk like GNU Smalltalk or Squeak, or a commercial one like [I'd better not say], you will find code designed for the *usual* case that doesn't actually work in all the cases you might expect. For example, try h := Heap withAll: #(3 1 4 1 5 9). h addAll: h. There's nothing inherent in Smalltalk that means this _couldn't_ work; in my Smalltalk it does. But that's because I thought about it, instead of taking the usual view "the programmer ought to know better than to try that." I'd expect big-money companies that liked Smalltalk to like stricter/safer functional languages even better, given a good development environment.