[Haskell-cafe] why are trading/banking industries seriouslyadopting FPLs???
ok at cs.otago.ac.nz
Mon Mar 28 01:18:08 CEST 2011
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
More information about the Haskell-Cafe