[mcav]

One of the things that draws me to functional programming* is the relative freedom from side-effects. A poorly designed, tightly coupled system begs to be rewritten, but doing so would come at an enormous cost. If a system is designed to snap together, with easily interchangeable parts, it's easier to be satisfied with evolving the software one piece at a time.

Then, when the urge to rewrite something strikes, you can just rewrite that one component, knowing that everything else should work just fine.

* I haven't actually built anything substantial in a functional language, other than my blog (in Clojure), so I can't back this up with experience. But I think it's true.

[jcromartie]

> Then, when the urge to rewrite something strikes, you can just rewrite that one component, knowing that everything else should work just fine.

I'm pretty sure this was the promise of OOP, too. Or at least the promise of the OOP that was sold to me in (limited) school and on the job.

[naradaellis]

A main reason that it is hard or impractical to refactor a part of an OO system is that you cannot reason about its side-effects on the rest of the system without scouring all of its source.

When you are guaranteed that a subsystem has no side effects, you can gut its internals and as long as the interface behaves the same - your system will behave the same.

edit: a _stateful_ OO system anyway.