You could "hot-edit" Lisp (1.85 at BBN) in the 60s (and there were other such systems). Smalltalk at Parc in the 70s used many of these ideas, and went even further.

Development environments should help programmers think (but what if most programmers don't want to think?)

Hot-editing updates behavior while keeping state, causing wildly unpredictable behavior given the way objects are constructed from classes in today's languages. The current approach to OO is to bootstrap fresh state from an external source every time the behavior changes so guarantees can be made about the interaction between behavior and state. It seems to me the equivalent of using a wheelchair because you might stumble while walking, the concern is genuine, but the cure is possibly worse than the affliction.

I don't know what the solution is. Perhaps a language with a fundamentally different view of objects, maybe as an ancestry of deltas of state/behavior pairings, somewhat like prototypes but inheriting by versioning and incrementally changing so that state and behavior always match up but still allowing you to revert to a working version. Likely Alan has some better ideas on what sort of language we need.

I use hot-editing in python by default and I find it incredibly useful (now I feel crippled when I'm on a system without it). There are times when I need to reload the state completely but it's pretty rare (changing something that uses metaclasses, like sqlalchemy, is one such place).

Maybe there's something about the style I've adopted that lends itself more to hot-editing but it's definitely a tool I'd hate to be without.

I'm super interested in how you do that! Can you share at all?

Yes! I can! I quickly made a video with super crappy audio quality last time it came up - https://www.youtube.com/watch?v=k-mAuNY9szI

It's pretty poor quality listening but you should get the point. You can send me an email (see my profile) if you wanted to go through it in more detail.

Redux does this at a library level - http://redux.js.org/docs/introduction/

Yes. I think they have been slowly getting better.

Visual Studio has let you do hot code editing for over a decade now, they call it "Edit and Continue"[0]. Only works for some languages (C#, Visual Basic/C++). It also lets you modify the program state while stopped on a break-point with code of your devising.

Most browsers also let you adhoc compose and run code without modifying the underlying programs.

Thanks to hardware performance counters, profilers are now able to profile code with much less impact on performance (eg: no more adjusting timeouts due to profiler overhead). Network debuggers are getting better at decoding traffic and displaying it in a more human readable format (eg: automatic gzip decompression, stream reassembly, etc).

[0]: https://msdn.microsoft.com/en-us/library/bcew296c.aspx

I don't know in what context "hot editing" was used to start this thread, but what I read in it is the idea that you can change code while it's running. Edit and continue has a different feel to it, because it works by a different method, by literally patching memory that the suspended thread is going to execute. It has the convenience of stopping the execution of the program before the patch is done. What "hot editing" in, say, Smalltalk has been able to do is you can have a live program running, you can call up a class that the thread uses, change the code in a method, compile it, while the thread is still running, and instantly see the change take effect. The reason it can do this is that method dispatch is late-bound. In .Net it's bound early. Late binding allows much more of a sense of experimentation. You don't have to stop anything. You just change it like you're changing a setting in an app., and you can see the change instantly. This gives you the feel that programming is much more fluid than the typical "stop, edit, compile, debug" cycle.

BASIC also did this on pretty much every microcomputer in the 1980s.

Kind of, but it was clunkier. You could Break out of an executing program, edit the code you wanted, and then type CONT to continue execution from the break point. The state from that point forward might not be what you want, though. At least inside VS it tries to revert state so that the revision executes as if the state came into it "clean."