3 ms·

> And any time you allow mutability in any form ... Odersky often says that the mutability should be as 'contained' as possible in what is otherwise a largely

> And any time you allow mutability in any form ... Odersky often says that the mutability should be as 'contained' as possible in what is otherwise a largely immutable codebase. If you can reason cleanly about a black box and are sure that the mutable variables within are not going to 'escape', you get the benefits of both 1. easier to implement, imperative algos which have been around for decades. (the alternative in pure FP is to convert stuff to tail recursion, which is not always the easiest thing to do, let's just say.) 2. easier reasoning about state not leaking to the rest of the system. I've found following these guidelines to be very helpful.

pmarreck 10y ago
> Odersky often says that the mutability should be as 'contained' as possible He's 100% correct (at minimum). > the alternative in pure FP is to convert stuff to tail recursion It's a challenge but not THAT difficult, once you get the hang of it. :) I've found conversions fun, actually. Especially when you (of course) have to learn how to trigger TCO. The irony here of course is that at the machine language level, the recursion is converted back to imperative via TCO. But IMHO the resulting recursively functional TCO code is, eh, "more beautiful"