One problem is that modern software architectures are highly coupled and stateful, such that it isn't possible to hot reload a component.
It would require the host (e.g. when using a DLL) to detect a change, save state, unload, reload, load state.
Multi-threading may also make things more difficult, requiring more synchronization during changes.
I agree with your sentiment, but it's really hard to communicate it to the younger generations. I suppose it comes off as being negative, but it's really just melancholia over the loss of something that was fun, simple, and powerful.
well, i think the issue is as least as much that the developers who create these architectures do not start from this pov ---
consider how these architectures would be designed if must-have condition was sub-100ms iteration -- which should be trivial all-but-for codebases of at least 1mil+ lines; them, well, maybe it's 200ms.
This design isnt hard -- what's hard about save_frame(), save_state(), or w/e, and restore_state()?
Only that it would need to be actively maintained and developed -- that is, it would obligate developers to tend to their own ability to work.
What i think here is lost is not, somehow a simple system which can be magic, but the concern of developers to maintain such systems.
Why? Certainly, many reasons. But my comment here today is more to frame the issue: this 'feature' can, and should, be part of ordinary development. It isnt that hard.
Even if save_frame() is no longer a register copy, but somehow, an obscene json serialisation process.
Way back in the 2000-2004 timeframe, I worked along side a team making a game for the OG Xbox that had a daily workflow like:
1. Come in, get coffee, check out latest code from Visual SourceSafe.
2. Hit F5 to start debugging.
3. Edit and Continue in Visual Studio 6.0 all day long.
4. Hit shift-F5 to stop debugging at the end of the day.
5. Go home.
Between that and the OG Pix for Xbox, the development experience has been all downhill from there. A lot of kids these days tried GDB once or twice and then grew up without even understanding the value of debuggers at all. And, by "kids" I mean "graduated 10 or less years ago" :P
I'm sure keeping that workflow working was a fair bit of work. But, it was worth it!
I'm working on a UE5 game right now using Live++. My day is now check out from perforce, hit F5, Ctrl+alt+F11 to hot reload, and for 98% of what I want to do, it works perfectly.
MS-DOS, Windows, .NET and Java development for me, during the last 30 years.
One of my university assignments, in the mid-1990's, was to implement a B-Tree library in C, which I used a OOP based approach, and already back then, gdb was powerful enough to use as a poor man's REPL.
I really don't get why people shy away to learn to use their tools properly.
Components depend on other components, and they all have to support hot reloading. And what about side effects? For example, an open network connection, or a window. You could store the state (handles etc.), but what about callbacks during the reloading phase? They'd have to block and wait.
Ultimately, what you need is a message passing architecture that supports all this. Smalltalk. Alan Kay has been a vocal critic of our modern architecture.
See his talk "Alan Kay at OOPSLA 1997 - The computer revolution hasnt happened yet".
But that architecture is computationally inefficient.
I suspect the problem is that computers weren't fast enough for the last 30 years. So we focused on performant computing. We still do that, with high fps gaming. And adding better quality graphics.
Soon we'll have Apple Vision Pro with a 4k display for each eye.
My personal hope is that WebAssembly and the Component Model will drastically change things, by introducing API virtualization and effectively decoupled modules, but this will require that tree-shaking/deadcode removal is disabled.
I feel like to some extent the problem here is the dynamic linking model that is almost universally used. If programs were designed from the perspective of the linker, then the linker could maintain a graph of function dependencies and have a cascading invalidation upon update. It is hard to retrofit this onto a project that is already a standard make based project.
Look, I'm part of the new generation. I think live plus plus is awesome, but don't really want to pay for it.
If what yout talking about is "not that hard" can you show me how to do it?
If it's not that hard, why aren't you teaching anyone? Why isn't it ubiquitous?
Your comments seem so at odds with reality that I'm inclined to think your missing something. But I'm also intrigued. Is it not that hard? And if it's not hard, why is live plus plus successful?
I agree with your sentiment, but it's really hard to communicate it to the younger generations. I suppose it comes off as being negative, but it's really just melancholia over the loss of something that was fun, simple, and powerful.