# Image-Based development and Interactive Experience **URL:** \ **Category:** General\ **Created:** [April 7, 2025, 8:09am UTC](https://racket.discourse.group/t/image-based-development-and-interactive-experience/3679 "2025-04-07T08:09:06Z")\ **Posts on this page:** 1\ **Showing post:** 32
**Author:** ![jryans](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jryans/32/31_2.png) [@jryans](https://racket.discourse.group/u/jryans)\ **Post date:** [May 14, 2025, 2:22pm UTC](https://racket.discourse.group/t/image-based-development-and-interactive-experience/3679/32 "2025-05-14T14:22:28Z")
> [@jbclements](#): > > I'm totally spitballing here, but it seems like you might be willing to accept a line drawn between library code and target code here, no? That is, the ability to edit parts of your own code, but not other existing libraries? What about a setup that just marked all of your own code as reloadable? (Please note that I say this without _any idea_ what the `reloadable` "thing" is...) Well, perhaps for certain projects you can find a good place to draw such a line, but I can imagine situations where it moves over time (e.g. from "just my own code" to "my own code plus this one library"). `reloadable` essentially does what you're describing here I think...? It has you draw the kind of line you are talking about between a "permanent" part and a "reloadable" part of the program. State that you want to preserve across reloads has to be in the permanent side, so you would have to carefully tune where this line falls for your particular project. That's a lot more fiddly than environments like Common Lisp, Julia, Clojure (along with Java and others on the JVM), etc. which allow editing a function's behaviour while retaining surrounding state without needing to draw any boundaries in advance. Now, I am sure attempting bring this form of "surgical" function replacement to Racket would be quite a complex task, especially once you work through the complexities of modules, macros, etc. which are all baked quite deeply into the guts of Racket's core. > [@jbclements](#): > > Or (still spitballing), what if the major change was the ability to freeze and reconstitute large pieces of data? It seems like this is the primary use case for something like this. I realize that in a world where functions are values, this proposal is arguably equivalent to just having image-based programming, but I suspect that you could get a substantial fraction of the desired functionality with only the abiilty to freeze and reconstitute things with easy mappings to (say) s-expressions. Perhaps, but I assume you'd still be drawing lines in advance around specific variables or structs to be reloaded...? I fear there's still lurking complexities in this direction, but I'd be curious to see more if someone tries to go down such a path. --- _[View the full topic](https://racket.discourse.group/t/image-based-development-and-interactive-experience/3679)._