>>28
There are corresponding challenges in FP, like threading state changes through the program can get verbose, as opposed to modifying it, i.e. side-effects. From what I understand Haskell goes to lengths to make this less inconvenient, where others will let you cheat.
I am put in mind of the decision to scrap the prover in BitC. The conclusion was that proving was unlikely to be taken advantage of by many developers and that it only buys confidence anyway. I feel that way about purity in FP, although it does buy a little more than confidence (some things are more efficient), but it also has a cost (some things are less efficient.) I don't feel that purity is law, but by default it is worth the price. The confidence it buys is quite high for the cost.