That can happen, but typically you're not keeping state around for huge periods of time (though you can if you want), it's just a convenience while you rapidly

That can happen, but typically you're not keeping state around for huge periods of time (though you can if you want), it's just a convenience while you rapidly iterate on the design of the code. Once you've got code that seems to hang together well, it's time to start thinking about what the right way to instantiate the objects, to consistently bring them to a correct state. Unit tests are useful for this, and with a brief (ab)use of a global variable, you can often make the tests run against your hand-made object, and verify that the test results are the same as when testing a properly instantiated object. After that you can dispense with your hand-made instance. Somewhat related, you can use unit tests of as-yet unimplemented functionality as a jumping-off point for live-coding your way towards the right implementation, with the debugger acting as a combined code editor and REPL (since the formal parameter names in the code will have real, evaluatable values behind them - as supplied by the test case). Were I a major Test Driven Development adherent, I might claim that this is the non-cargo-cult way of doing TDD.