Yeah, I've been using this trick to implement a hot reload library, to only update the specific functions that are changed without re-executing modules: https://github.com/breuleux/jurigged
I also use it in a multiple dispatch library (https://github.com/breuleux/ovld) to replace the entry point by specialized dispatch code in order to cut some overhead.
It's fun.
Also, why is every damn post these days somehow framed in an AI context? It's exhausting.
> Also, why is every damn post these days somehow framed in an AI context? It's exhausting.
Every 5/10-year segment of my life has somehow had one or two "This is the future"-hypes running concurrently with my life. Previously it was X, now it's Y. And most of the times, everything else is somehow connected to this currently hyped subject, no matter if it's related or not.
The only thing I've found to be helpful is thinking about and changing my perspective and framing about it. I read some article like this which is just tangentially related to AI, but the meat is about something else. So mentally I just ignore the other parts, and frame it in some other way in my head.
Suddenly people can write their articles with attachments to the hyped subject but I don't mind, I'm reading it for other purposes and get other takeaways that are still helpful. A tiny Jedi mind-trick for avoiding that exhaustion :)
I also find it useful to keep in mind (often more junior) people are learning new things and expressing their joy, which is a good thing. and most (junior) people learning things in tech right now are doing so in the context of AI, for better or worse
(idk if this author is “junior” per se, mostly just agreeing the shift in perspective is helpful to not get burnt out by things like this)
AI, block chain, rust, go, serverless, nosql, ruby on rails..... The list goes on and on :-)
Some of it gets really annoying on the business side, because companies like Gartner jump on the trends, and they have enough influence that businesses have to pay attention. When serverless was a thing, every cloud provider effectively had to add serverless things even if it made zero sense and no customers were asking for it, simply to satisfy Gartner (and their ilk) and be seen as innovating and ahead of the curve. Same thing happened with block chain, and is currently happening with AI.
wheels get reinvented again again again and again … this is quite unique to info tech … imagine mathematicians do the same, the world would be in chaos …
> wheels get reinvented again again again and again
And yet, it took us (humans) a long time to turn the wheel around and using it for transportation, so maybe we need reinvent even more things, turn them around and such :)
Oh that is really interesting, I was just aware of IPython's autoreload extension, I hadn't found your library. I'm also working on hot reload for python as I'm working on a development environment for python that aims to give it a development experience closer to lisp: https://codeberg.org/sczi/swanky-python/
Some minor details. You currently aren't updating functions if their freevars have changed, you can actually do that by using c-api to update __closure__ which is a readonly attribute from python:
Also I think you should update __annotations__, __type_params__, __doc__, and __dict__ attributes for the function.
Rather than using gc.get_referrers I just maintain a set for each function containing all the old versions (using weakref so they go away if that old version isn't still referenced by anything). Then when a function updates I don't need to find all references, all references will be to some old version of the function so I just update that set of old functions, and all references will be using the new code. I took this from IPython autoreload. I think it is both more efficient than gc.get_referrers, and more complete as it solves the issue of references "decorated or stashed in some data structure that Jurigged does not understand". The code for that is here: https://codeberg.org/sczi/swanky-python/src/commit/365702a6c...
hot reload for python is quite tricky to fully get right, I'm still missing plenty parts that I know about and plan on implementing, and surely plenty more that I don't even know. If you or anyone else that's worked on hot reload in python wants to talk about it, I'm happy to, just reach out, my email is visible on codeberg if you're signed in.
Thanks for the tips, I'll try to look into these when I get some time! Didn't know you could modify the closure pointer.
I'm not sure what you mean by "maintaining a set of old versions". It's possible I missed something obvious, but the issue here is that I have the code objects (I can snag them from module evaluation using an import hook)... but I do not have the function objects. I never had them in the first place. Take this very silly and very horrible example:
def adder(x):
def inner(y):
return x / y
return inner
adders = {}
def add(x, y):
adders.setdefault(x, adder(x))
return adders[x](y)
The adders dictionary is dynamically updated with new closures. Each is a distinct function object with a __code__ field. When I update the inner function, I want all of these closures to be updated. Jurigged is able to do it -- it can root them out using get_referrers. I don't see how else to do it. I quickly tested in a Jupyter notebook, and it didn't work: new closures have the new code, but the old ones are not updated.
Oooh now that is interesting. What I by mean stuff I don't even know that I don't know :)
Yes mine doesn't handle that, it is the same as jupyter there. Smalltalk is supposed to be best at interactive development, I wonder if it will update the old closures. I don't know it to try, but I do know Common Lisp which is also supposed to be quite good, and fwiw it behaves the same, new closures have the new code, but the old ones are not updated:
Interesting. It appears that not many systems have been designed to enable hot reload in a thorough way.
Here's another fun complication: what if I have a decorator that performs a code transform on the source code of the decorated function? If the code is changed, I would like to automatically re-run the transform on the new code. I made a (kind of awkward) protocol for this: https://github.com/breuleux/jurigged?tab=readme-ov-file#cust.... It's a little confusing even for me, so I should probably review it.
Wow it looks like you are taking reloading to another level I hadn't even considered.
For example in your elephant:main.py test, in swanky python I run do(3):
['Paint 3 canvasses', 'Sing 3 songs', 'Dance for 3 hours']
change songs to songz, and now do(3) is:
['Paint 3 canvasses', 'Sing 3 songs', 'Dance for 3 hours', 'Sing 3 songz']
Rather than changing the earlier songs to songz as jurigged manages to. But any lisp environment would behave the same, we don't have the idea of:
> 3. When a file is modified, re-parse it into a set of definitions and match them against the original, yielding a set of changes, additions and deletions.
We are just evaling functions or whatever sections of code you say to eval, not parsing files and seeing what was modified. So in some cases we might need to make a separate unregister function and call that on the old one. Like in emacs if you use advice-add (adds before, after, and other kinds of hooks to a function), you can't just change the lines adding an advice and save the file to have it modify the old advice, you need to explicitly call advice-remove to unset the old advice, then advice-add with your new advice, if you want to modify it while running without restarting.
When I eval a function again I am evaling all decorators again, in your readme you write the downsides of that:
> %autoreload will properly re-execute changed decorators, but these decorators will return new objects, so if a module imports an already decorated function, it won't update to the new version.
But I think I am handling that, or maybe you have other cases in mind I am missing? ie in a.py:
Then in b.py, from a import reload_me, change reload_me in a and slime-eval-defun it, and b is using the new version of reload_me. Basically for all (__module__, __qualname__) I am storing the function object, and all old versions of the function object. Then when there is a new function object with that name I update the code, closure and other attributes for all the old function objects to be the same as the new one.
I'll look into maybe just integrating jurigged for providing the reloading within swanky python. I was using the ipython autoreload extension at first, but ran into various problems with it so ended up doing something custom still mostly based on ipython, which is working for me in practice for now. So as long as I don't run into problems with it I'll focus on the many other parts of swanky python that need work, but sooner or later when I inevitably run into reloading problems I'll evaluate whether to just switch reloading to use jurigged.
> Lisp and Smalltalk addressed this by not unwinding the stack on exceptions, dropping you into a debugger and allowing you to fix the error and resume execution without having to restart your program from the beginning. Eventually I'd like to patch CPython to support this
yea i've been meaning to do this for a while as well...
I haven't started really looking into it yet, but I found this blog that looks like a good description of what exactly happens during stack unwinding in python and gets a large part of the way to resuming execution in pure python without even any native code: https://web.archive.org/web/20250322090310/https://code.lard...
Though the author says they wrote it as a joke and probably it is not possible to do robustly in pure python, but I assume it can be done robustly as a patch to CPython or possibly even as just a native C extension that gets loaded without people needing a patched build of CPython. If you know any good resources or information about how to approach this, or start working on it yourself, let me know.
Jurigged is awesome. It works really well and saves me tons of time. Thank you for making it!
I do wish there were callbacks I could subscribe to that would notify me whenever my file changed or whenever any code changed, so I could re-run some init.
My other feature request would be a way to replace function implementations even when they are currently on the stack, as some other hot reload implementations can. But I certainly understand why this would be difficult.
I use jurigged in conjunction with cmd2 to make command line driven tools. The combination works well because I can issue a command, watch the output, make a change, hit up-return and see the change just like that.
Thank you a bazillion for making it. It works quietly in the background without fuss, and I'm grateful for it every time I use it.
In some respects that's even nicer to use than a typical editor-integrated live-coding REPL, because one doesn't have to think about what code needs (re)sending from the source to the REPL. Just save the file and it'll be figured out which parts meaningfully changed.
And wouldn't it be nice if that Python code, instead of a string, was just more python? Then you could use your existing Python code to append, or transform sections of your code!
That's what Lisp is!
Once you see how cool that is, then you can begin to appreciate why Lisp was the defacto standard for AI programing all the way back in the 1960s!
Ah, so in Python, you have "normal code" then you have AST code. Imagine that they were exactly the same, and whenever you're writing "normal code", you're at the same time writing AST code and vice-versa.
So whenever you want, you can start using "normal code" for manipulating the "normal code" itself, and hopefully now we have yet another perspective on the same thing, for why Lisps are so awesome :)
S-expressions are a nice gimmick, but it’s not the fundamental reason why some Lisps support dynamic patching of code at runtime. Indeed you can easily imagine Lisp written in M-expressions and still support that. Or you can imagine other dynamic languages with reflection gaining this capability with a bit of will, like… check notes… Python.
S-expressions make the user interface to code generation, a component to hot-reloading, more facile. It's not a triviality or gimmick in this context.
We can see from OP that it's actually quite annoying to specify code in a non-S-expression language (or really any language lacking a meta-syntax), usually requiring either
- stuffing and interpolating strings
- building ASTs with API functions provided by the implementation in a tiresome or verbose manner
But you're right that there are more aspects to hot-reloading than just the syntax and data structure.
Common Lisp gets away with it because it actually defines the semantics of redefinition of functions and classes. For instance, the standard says what will happen to all existing FOO object instances in memory if I change
and even lets the programmer customize the behavior of such a redefinition.
Few if any languages go through the trouble of actually defining these semantics, especially in the context of a compiled language (like Common Lisp), making all but the simplest instances of reloading code well defined.
I think there is potential to do something like that with template strings [1] (upcoming feature in Python 3.14). The choice of {} for interpolation isn't ideal because any code with dict and set literals becomes super awkward, but besides that, it could be super interesting for codegen.
I think what I was getting at, is the power this homoiconicity gives you when combined with macros, and I'm not sure how template strings would help with either. Say you want to have a function that receives the code passed into it, instead of whatever the code evaluated to return, could I somehow achieve that with AST and/or template strings in Python?
Say I want `what-code(1 + 1)` to receive `1 + 1` as the argument, not `2`, would either of those things let me do that? At a glance, and without diving deeper, the Ast module could make it so `what-code("1 + 1")` would let the function parse the string and get an Ast, which we could do stuff with, but it pretty much ends at that and is non-ideal for many reasons.
Well... what are you trying to do with "1 + 1"? Lisps are "homoiconic" in the sense that everything is a list, but honestly? When I worked with Scheme in the past, I almost never manipulated code as actual lists. It's not robust. I used match and quote/unquote. What's where I see template strings.
So what you could do is something like this:
addition = "1 + 1"
multiplication = t"{addition} * 7"
result = eval(multiplication) # result is 14
Instead of inserting addition as an exact string, producing "1 + 1 * 7" which is 8, it would parse as an AST and insert the addition node as a unit, so that you get the intended result. You could also do an alpha conversion if the injected code declares variables to avoid name clashes.
It wouldn't let you do true macros, but it would make codegen easier and less error-prone.
> Lisps are "homoiconic" in the sense that everything is a list, but honestly?
That's not how I understand homoiconicity, "everything is a list" or not has nothing to do with it. The point is that whatever structure the compiler uses to understand the code (slightly loose), is the same code you write, since code is represented as data. But if it's maps, lists, booleans or whatever isn't the important takeaway from that.
In your example, how would I, after the multiplication line but before the result line , manipulate "1 + 1" to read something else like "2 + 1"? In Clojure for example, it would be (+ 1 1) so if you wanna change 1 to 2, you use the typical "replace item in list by index" function, but with Python you're either stuck with AST or "code-as-strings". I think that's where a lot of the complexity and error-proneness gets in.
Okay, but even in Lisp, I'm not sure that's a good way to go about it. What do you want to do when you manipulate code, generally? Oftentimes you seek to find all instances of a specific pattern and modify part of that pattern. So why not do something like this:
If you give me a primitive like that in Lisp, I'm going to use it. It's a lot more trustworthy than "replace item in list by index". Because it's nice and all that everything is a list in Lisp, but manipulating code as lists (or maps or whatever) like you describe isn't going to get you very far. If you want to do something as simple as replacing all calls to (f x) by (f x 1), you better hope you don't come across code like (let ((f 123)) ...), for example. Outside of toy cases and examples, you need robust primitives that understand the code's semantic structure.
There's actually a library called ast-grep which does something very similar to what you're describing. They have an example in their introduction which performs a find and replace operation on a JS AST using a pattern:
Is there a good way to verify self-modifying code - in Lisp, or Combo (MOSES), or Python - at runtime against a trusted baseline at loader time?
Dynamic metaprogramming is flexible but dangerous. Python is also "dynamic", meaning that code can be changed at runtime instead of only being able to accidentally pass null function pointers.
Python's metaclasses function similarly to Lisp's macros but in a consistent way: most Python code uses the standard metaclasses so that the macros don't vary from codebase to codebase. The Django "magic removal" story was about eliminating surprise and non-normative metaclassery, for example.
Does this tool monkey patch all copies of a function or just the current reference? There are many existing monkey patching libraries with tests
I get that it works, and it's actually pretty cool that you can do this. But honestly, it feels like it would good, readable code into a tangled mess pretty fast.
> it feels like it would good, readable code into a tangled mess pretty fast
It definitively can, no doubt about it. But used sparingly and only when there is no other way, it can help you remove enormous amount of boilerplate and other things, in a relatively simple, fast and safe way. In my codebases, it does lead to a lot less code, even when most projects just have 2 or 3 macros at most.
Just as one basic example that comes to mind just because I had to do it today: imagine you have a testing suite. When some assertion fails, you'd like to display what value was expected, what value it actually got, and what the exact code was. In JavaScript, I think the most you'd be able to get without involving 3rd party compilers, reading source code from disk or whatnot, would be some functions name (`myfn.toString()`), while in Clojure your macro could capture the entire source code within it, and print it, trivially.
Basically, if you want a function that can take the arguments without evaluating them before executing it, you can do so with macros but without macros you cannot do that. Personally, being able to do so leads to me finding simpler solutions, and expressing them in better ways, compared to if I didn't have them available.
In Python in relation to ast, it does seem so yeah.
If you add two numbers in Python code, it looks like `1 + 1`, but if you use the module from `Lib/ast.py` linked above, how would it look like? I think it would be something like `Expression(body=BinOp(left=Name(id='x',ctx=Load()),op=Add(),right=Name(id='y', ctx=Load())))` which at a glance, certainly looks different than `1 + 1` in my eyes :)
In lisps, `(+ 1 1)` is just `(+ 1 1)` regardless if it's source code or AST, they're just the same thing.
I think you are missing my point. My point is that manually building AST data structures instead of taking them from existing code looks different in Lisp too.
Such a wide net though, what exactly constitutes a "remotely useful project" in your mind? Maybe if we figure out what the exact requirements are, we'll be able to help you with your search :)
> ITA Software by Google
Airfare search engine and airline scheduling software. Cambridge, MA. Common Lisp is used for the core flight search engine. The larger Flights project is roughly equal parts CL, C++, and Java.
Read the last sentence AND this company got acquired by Google like 15 years ago. So ya my question still stands.
You asked where Lisp is useful, and I supplied a list of companies that find (or, in some cases of recent history, found) Lisp useful. Your Google example is pertinent, because Google had the resources to wholesale eliminate its use of Lisp any time within the last 15 years, but for some reason worth pondering, hasn't. Instead, they continue to develop the product in Lisp, and continue to contribute to the Common Lisp open-source ecosystem.
But that aside, if you want a fresh look at what people are thinking about with Lisp, maybe check out the talks that were given this year at the 2025 European Lisp Symposium [1,2]. Or perhaps look at how someone shipped a platformer game on Steam with Common Lisp [3,4], and is in the finishing lap porting it to the Nintendo Switch [5].
I realize, though, that this kind of "debate" (?) is never satisfying to the instigator. If it does satisfy though, I will agree with you that—despite all of the claims of alleged productivity and power the language offers—Common Lisp remains far less popular than Python, which I assume is your only real point here.
[1] A presentation about how adding a static type system to Common Lisp à la Haskell helps write mission critical programs in defense and quantum computing: https://youtu.be/of92m4XNgrM
[2] A talk from employees of Keepit, a company that supplies a SaaS backup service, discussed how they train people on Common Lisp when employing them: https://youtu.be/UCxy1tvsjMs?t=66m51s
[4] The actual game that you can buy: https://store.steampowered.com/app/1261430/Kandria/ (This is not intended to be an advertisement and I'm unaffiliated. It's just a demonstration of a recently "shipped" product written in Common Lisp where you might not expect it.)
> Ok now do the part where lisp is actually used for any remotely useful project today...
> So ya my question still stands.
That list has 100 companies using lisp today. Were you actually asking if any new companies write in Lisp? Cuz those exist as well - in the same list...
Not surprising! You didn't make any point you just posted a link to a wikipedia page. Again, sources were posted and you cherry-picked one that still confirmed what you asked about. Nw you're doubling down/moving goalposts. Real companies use lisp, in 2025. It's not that big of a deal.
I really couldn't follow the use case. it looked like, they have a chain of method calls with some kind of `mark_circle().encode().properties()`, OK, so, if you want to make those methods do something different, you reach into OOP wisdom from the 1980s and write an appropriate "impl" used by whatever `alt.Chart()` is.
Someone explain to me, an old, aging programmer old enough to know UML, why this isn't some we presume very young person who has no idea how to write OOP coming up with some horrible convoluted way to do something routine?
Ah, self-modifying code, the more things change the more they stay the same.
Wasn't SMC one of the LISP-associated AI fields a few decades ago? iirc it's been mostly abandoned due to security issues, but some of it survives in dynamic compilation.
Aka I just learned how to modify python code whilst it's running.
Next step, here's how to load modules, resolve a dependency. Handle capabilities and dynamically inject more functionality 'live'.
Patching running machine code in memory for compiled objects is the same but you just need to work around the abstraction that is introduced by languages trying to make the whole stack human parseable.
Any language running on the JVM (Java, Kotlin, etc.) and CLR (C#, VB.NET, etc.). As long as you don't compile directly to native code and you aren't running in a locked-down environment where codegen is disabled, you can generate code at runtime and execute it alongside existing code.
For example, there's java.lang.reflect.Proxy [1] and System.Reflection.Emit [2].
Several! You're correct that Lisps is the most famous, and there's also languages like Erlang that have this as a core functionality. But it's also used in things like game engines for C/C++. You do have your "updateAndRenderFrame()" function in a dynamic library, having it take a pointer to the full game state as an argument. When you want to reload, you recompile your dynamic library, and the main loop can swap out the implementation, and the game keeps running with the new code. I don't see a reason why you couldn't do this in Rust, though I imagine it's trickier.
The use case is not that obvious to me, but I _think_ it's trying to give the LLM more context to write code by dipping into these code objects. Perhaps telling the LLM what modules are already imported or otherwise available?
Creating a debugger for an LLM (not a human) is something I haven't really seen, but seems super useful...?
Neat trick indeed, but I have not yet found a compelling use-case for this that can't be done more sensibly using lambdas.
I once inherited a nice library which made heavy use of such compile/exec pairs. The code looked very convoluted and was very bug prone. I replaced all such pairs with lambda wrappers. This was much more readable: my colleagues who were also working on this code were like "oh is that what that was meant to be doing" after this change.
I did this by accident in bash scripts many years ago when I was just getting into linux. I'd be running a script, and editing the script at the same time. It caused some REALLY weird issues before I figured out what was happening. For instance I'd change the text somewhere and it would change in the running program, or the program would get into states it should never be in. I didn't use it constructively, I just avoided editing running programs after that.
I used live patching of the function byte code to enforce type safety in python as an experiment. It was quite fun, took about a weekend or so :) not something for production though, due to the performance hit.
One of the problem with dynamically loaded code like this is when you raise exceptions in those functions - the traceback will then end with something like `File "<magic>", line 8, in something`, which will at least annoy you when debugging.
I'm not sure what the point of this blogpost was. As far as I can tell, the author discovered eval() but is making it more complicated for no reason? There also isn't any actual patching going on.
I've contemplated patching Python's asyncio package so that the list of funcs isn't a weakref... but it's not that hard! This is way harder than it needs to be.
Yeah, I've been using this trick to implement a hot reload library, to only update the specific functions that are changed without re-executing modules: https://github.com/breuleux/jurigged
I also use it in a multiple dispatch library (https://github.com/breuleux/ovld) to replace the entry point by specialized dispatch code in order to cut some overhead.
It's fun.
Also, why is every damn post these days somehow framed in an AI context? It's exhausting.
> Also, why is every damn post these days somehow framed in an AI context? It's exhausting.
Every 5/10-year segment of my life has somehow had one or two "This is the future"-hypes running concurrently with my life. Previously it was X, now it's Y. And most of the times, everything else is somehow connected to this currently hyped subject, no matter if it's related or not.
The only thing I've found to be helpful is thinking about and changing my perspective and framing about it. I read some article like this which is just tangentially related to AI, but the meat is about something else. So mentally I just ignore the other parts, and frame it in some other way in my head.
Suddenly people can write their articles with attachments to the hyped subject but I don't mind, I'm reading it for other purposes and get other takeaways that are still helpful. A tiny Jedi mind-trick for avoiding that exhaustion :)
I also find it useful to keep in mind (often more junior) people are learning new things and expressing their joy, which is a good thing. and most (junior) people learning things in tech right now are doing so in the context of AI, for better or worse
(idk if this author is “junior” per se, mostly just agreeing the shift in perspective is helpful to not get burnt out by things like this)
AI, block chain, rust, go, serverless, nosql, ruby on rails..... The list goes on and on :-)
Some of it gets really annoying on the business side, because companies like Gartner jump on the trends, and they have enough influence that businesses have to pay attention. When serverless was a thing, every cloud provider effectively had to add serverless things even if it made zero sense and no customers were asking for it, simply to satisfy Gartner (and their ilk) and be seen as innovating and ahead of the curve. Same thing happened with block chain, and is currently happening with AI.
wheels get reinvented again again again and again … this is quite unique to info tech … imagine mathematicians do the same, the world would be in chaos …
> wheels get reinvented again again again and again
And yet, it took us (humans) a long time to turn the wheel around and using it for transportation, so maybe we need reinvent even more things, turn them around and such :)
Oh that is really interesting, I was just aware of IPython's autoreload extension, I hadn't found your library. I'm also working on hot reload for python as I'm working on a development environment for python that aims to give it a development experience closer to lisp: https://codeberg.org/sczi/swanky-python/
Some minor details. You currently aren't updating functions if their freevars have changed, you can actually do that by using c-api to update __closure__ which is a readonly attribute from python:
Also I think you should update __annotations__, __type_params__, __doc__, and __dict__ attributes for the function.Rather than using gc.get_referrers I just maintain a set for each function containing all the old versions (using weakref so they go away if that old version isn't still referenced by anything). Then when a function updates I don't need to find all references, all references will be to some old version of the function so I just update that set of old functions, and all references will be using the new code. I took this from IPython autoreload. I think it is both more efficient than gc.get_referrers, and more complete as it solves the issue of references "decorated or stashed in some data structure that Jurigged does not understand". The code for that is here: https://codeberg.org/sczi/swanky-python/src/commit/365702a6c...
hot reload for python is quite tricky to fully get right, I'm still missing plenty parts that I know about and plan on implementing, and surely plenty more that I don't even know. If you or anyone else that's worked on hot reload in python wants to talk about it, I'm happy to, just reach out, my email is visible on codeberg if you're signed in.
Thanks for the tips, I'll try to look into these when I get some time! Didn't know you could modify the closure pointer.
I'm not sure what you mean by "maintaining a set of old versions". It's possible I missed something obvious, but the issue here is that I have the code objects (I can snag them from module evaluation using an import hook)... but I do not have the function objects. I never had them in the first place. Take this very silly and very horrible example:
The adders dictionary is dynamically updated with new closures. Each is a distinct function object with a __code__ field. When I update the inner function, I want all of these closures to be updated. Jurigged is able to do it -- it can root them out using get_referrers. I don't see how else to do it. I quickly tested in a Jupyter notebook, and it didn't work: new closures have the new code, but the old ones are not updated.Oooh now that is interesting. What I by mean stuff I don't even know that I don't know :)
Yes mine doesn't handle that, it is the same as jupyter there. Smalltalk is supposed to be best at interactive development, I wonder if it will update the old closures. I don't know it to try, but I do know Common Lisp which is also supposed to be quite good, and fwiw it behaves the same, new closures have the new code, but the old ones are not updated:
Interesting. It appears that not many systems have been designed to enable hot reload in a thorough way.
Here's another fun complication: what if I have a decorator that performs a code transform on the source code of the decorated function? If the code is changed, I would like to automatically re-run the transform on the new code. I made a (kind of awkward) protocol for this: https://github.com/breuleux/jurigged?tab=readme-ov-file#cust.... It's a little confusing even for me, so I should probably review it.
Wow it looks like you are taking reloading to another level I hadn't even considered.
For example in your elephant:main.py test, in swanky python I run do(3): ['Paint 3 canvasses', 'Sing 3 songs', 'Dance for 3 hours']
change songs to songz, and now do(3) is: ['Paint 3 canvasses', 'Sing 3 songs', 'Dance for 3 hours', 'Sing 3 songz']
Rather than changing the earlier songs to songz as jurigged manages to. But any lisp environment would behave the same, we don't have the idea of:
> 3. When a file is modified, re-parse it into a set of definitions and match them against the original, yielding a set of changes, additions and deletions.
We are just evaling functions or whatever sections of code you say to eval, not parsing files and seeing what was modified. So in some cases we might need to make a separate unregister function and call that on the old one. Like in emacs if you use advice-add (adds before, after, and other kinds of hooks to a function), you can't just change the lines adding an advice and save the file to have it modify the old advice, you need to explicitly call advice-remove to unset the old advice, then advice-add with your new advice, if you want to modify it while running without restarting.
When I eval a function again I am evaling all decorators again, in your readme you write the downsides of that:
> %autoreload will properly re-execute changed decorators, but these decorators will return new objects, so if a module imports an already decorated function, it won't update to the new version.
But I think I am handling that, or maybe you have other cases in mind I am missing? ie in a.py:
Then in b.py, from a import reload_me, change reload_me in a and slime-eval-defun it, and b is using the new version of reload_me. Basically for all (__module__, __qualname__) I am storing the function object, and all old versions of the function object. Then when there is a new function object with that name I update the code, closure and other attributes for all the old function objects to be the same as the new one.I'll look into maybe just integrating jurigged for providing the reloading within swanky python. I was using the ipython autoreload extension at first, but ran into various problems with it so ended up doing something custom still mostly based on ipython, which is working for me in practice for now. So as long as I don't run into problems with it I'll focus on the many other parts of swanky python that need work, but sooner or later when I inevitably run into reloading problems I'll evaluate whether to just switch reloading to use jurigged.
> Lisp and Smalltalk addressed this by not unwinding the stack on exceptions, dropping you into a debugger and allowing you to fix the error and resume execution without having to restart your program from the beginning. Eventually I'd like to patch CPython to support this
yea i've been meaning to do this for a while as well...
I haven't started really looking into it yet, but I found this blog that looks like a good description of what exactly happens during stack unwinding in python and gets a large part of the way to resuming execution in pure python without even any native code: https://web.archive.org/web/20250322090310/https://code.lard...
Though the author says they wrote it as a joke and probably it is not possible to do robustly in pure python, but I assume it can be done robustly as a patch to CPython or possibly even as just a native C extension that gets loaded without people needing a patched build of CPython. If you know any good resources or information about how to approach this, or start working on it yourself, let me know.
Jurigged is awesome. It works really well and saves me tons of time. Thank you for making it!
I do wish there were callbacks I could subscribe to that would notify me whenever my file changed or whenever any code changed, so I could re-run some init.
My other feature request would be a way to replace function implementations even when they are currently on the stack, as some other hot reload implementations can. But I certainly understand why this would be difficult.
I use jurigged in conjunction with cmd2 to make command line driven tools. The combination works well because I can issue a command, watch the output, make a change, hit up-return and see the change just like that.
Thank you a bazillion for making it. It works quietly in the background without fuss, and I'm grateful for it every time I use it.
> why is every damn post these days somehow framed in an AI context? It's exhausting.
It’s even in the real world now - most of my conversations with people in tech end up at AI eventually.
It kind of reminds me of the 2010s when non-tech people would ask me about crypto at social events.
In some respects that's even nicer to use than a typical editor-integrated live-coding REPL, because one doesn't have to think about what code needs (re)sending from the source to the REPL. Just save the file and it'll be figured out which parts meaningfully changed.
Jurigged is really cool - thanks for the tool!
jurigged is great, love using it for quick GUI prototyping with imgui!
And wouldn't it be nice if that Python code, instead of a string, was just more python? Then you could use your existing Python code to append, or transform sections of your code!
That's what Lisp is!
Once you see how cool that is, then you can begin to appreciate why Lisp was the defacto standard for AI programing all the way back in the 1960s!
https://docs.python.org/3/library/ast.html
Ah, so in Python, you have "normal code" then you have AST code. Imagine that they were exactly the same, and whenever you're writing "normal code", you're at the same time writing AST code and vice-versa.
So whenever you want, you can start using "normal code" for manipulating the "normal code" itself, and hopefully now we have yet another perspective on the same thing, for why Lisps are so awesome :)
S-expressions are a nice gimmick, but it’s not the fundamental reason why some Lisps support dynamic patching of code at runtime. Indeed you can easily imagine Lisp written in M-expressions and still support that. Or you can imagine other dynamic languages with reflection gaining this capability with a bit of will, like… check notes… Python.
S-expressions make the user interface to code generation, a component to hot-reloading, more facile. It's not a triviality or gimmick in this context.
We can see from OP that it's actually quite annoying to specify code in a non-S-expression language (or really any language lacking a meta-syntax), usually requiring either
- stuffing and interpolating strings
- building ASTs with API functions provided by the implementation in a tiresome or verbose manner
But you're right that there are more aspects to hot-reloading than just the syntax and data structure.
Common Lisp gets away with it because it actually defines the semantics of redefinition of functions and classes. For instance, the standard says what will happen to all existing FOO object instances in memory if I change
to and even lets the programmer customize the behavior of such a redefinition.Few if any languages go through the trouble of actually defining these semantics, especially in the context of a compiled language (like Common Lisp), making all but the simplest instances of reloading code well defined.
I think there is potential to do something like that with template strings [1] (upcoming feature in Python 3.14). The choice of {} for interpolation isn't ideal because any code with dict and set literals becomes super awkward, but besides that, it could be super interesting for codegen.
[1] https://peps.python.org/pep-0750/
I think what I was getting at, is the power this homoiconicity gives you when combined with macros, and I'm not sure how template strings would help with either. Say you want to have a function that receives the code passed into it, instead of whatever the code evaluated to return, could I somehow achieve that with AST and/or template strings in Python?
Say I want `what-code(1 + 1)` to receive `1 + 1` as the argument, not `2`, would either of those things let me do that? At a glance, and without diving deeper, the Ast module could make it so `what-code("1 + 1")` would let the function parse the string and get an Ast, which we could do stuff with, but it pretty much ends at that and is non-ideal for many reasons.
Well... what are you trying to do with "1 + 1"? Lisps are "homoiconic" in the sense that everything is a list, but honestly? When I worked with Scheme in the past, I almost never manipulated code as actual lists. It's not robust. I used match and quote/unquote. What's where I see template strings.
So what you could do is something like this:
Instead of inserting addition as an exact string, producing "1 + 1 * 7" which is 8, it would parse as an AST and insert the addition node as a unit, so that you get the intended result. You could also do an alpha conversion if the injected code declares variables to avoid name clashes.It wouldn't let you do true macros, but it would make codegen easier and less error-prone.
> Lisps are "homoiconic" in the sense that everything is a list, but honestly?
That's not how I understand homoiconicity, "everything is a list" or not has nothing to do with it. The point is that whatever structure the compiler uses to understand the code (slightly loose), is the same code you write, since code is represented as data. But if it's maps, lists, booleans or whatever isn't the important takeaway from that.
In your example, how would I, after the multiplication line but before the result line , manipulate "1 + 1" to read something else like "2 + 1"? In Clojure for example, it would be (+ 1 1) so if you wanna change 1 to 2, you use the typical "replace item in list by index" function, but with Python you're either stuck with AST or "code-as-strings". I think that's where a lot of the complexity and error-proneness gets in.
Okay, but even in Lisp, I'm not sure that's a good way to go about it. What do you want to do when you manipulate code, generally? Oftentimes you seek to find all instances of a specific pattern and modify part of that pattern. So why not do something like this:
If you give me a primitive like that in Lisp, I'm going to use it. It's a lot more trustworthy than "replace item in list by index". Because it's nice and all that everything is a list in Lisp, but manipulating code as lists (or maps or whatever) like you describe isn't going to get you very far. If you want to do something as simple as replacing all calls to (f x) by (f x 1), you better hope you don't come across code like (let ((f 123)) ...), for example. Outside of toy cases and examples, you need robust primitives that understand the code's semantic structure.There's actually a library called ast-grep which does something very similar to what you're describing. They have an example in their introduction which performs a find and replace operation on a JS AST using a pattern:
https://ast-grep.github.io/guide/introduction.htmlIs there a good way to verify self-modifying code - in Lisp, or Combo (MOSES), or Python - at runtime against a trusted baseline at loader time?
Dynamic metaprogramming is flexible but dangerous. Python is also "dynamic", meaning that code can be changed at runtime instead of only being able to accidentally pass null function pointers.
Python's metaclasses function similarly to Lisp's macros but in a consistent way: most Python code uses the standard metaclasses so that the macros don't vary from codebase to codebase. The Django "magic removal" story was about eliminating surprise and non-normative metaclassery, for example.
Does this tool monkey patch all copies of a function or just the current reference? There are many existing monkey patching libraries with tests
I get that it works, and it's actually pretty cool that you can do this. But honestly, it feels like it would good, readable code into a tangled mess pretty fast.
> it feels like it would good, readable code into a tangled mess pretty fast
It definitively can, no doubt about it. But used sparingly and only when there is no other way, it can help you remove enormous amount of boilerplate and other things, in a relatively simple, fast and safe way. In my codebases, it does lead to a lot less code, even when most projects just have 2 or 3 macros at most.
Just as one basic example that comes to mind just because I had to do it today: imagine you have a testing suite. When some assertion fails, you'd like to display what value was expected, what value it actually got, and what the exact code was. In JavaScript, I think the most you'd be able to get without involving 3rd party compilers, reading source code from disk or whatnot, would be some functions name (`myfn.toString()`), while in Clojure your macro could capture the entire source code within it, and print it, trivially.
Basically, if you want a function that can take the arguments without evaluating them before executing it, you can do so with macros but without macros you cannot do that. Personally, being able to do so leads to me finding simpler solutions, and expressing them in better ways, compared to if I didn't have them available.
There is not 2 different kinds of code. That's like saying Lisp has normal code and list code.
> There is not 2 different kinds of code
In Python in relation to ast, it does seem so yeah.
If you add two numbers in Python code, it looks like `1 + 1`, but if you use the module from `Lib/ast.py` linked above, how would it look like? I think it would be something like `Expression(body=BinOp(left=Name(id='x',ctx=Load()),op=Add(),right=Name(id='y', ctx=Load())))` which at a glance, certainly looks different than `1 + 1` in my eyes :)
In lisps, `(+ 1 1)` is just `(+ 1 1)` regardless if it's source code or AST, they're just the same thing.
(cons '+ (cons 1 (cons 1 nil))) doesn't look like (+ 1 1).
What about `(+ 1 1) or (quote (+ 1 1)) then?
I think you are missing my point. My point is that manually building AST data structures instead of taking them from existing code looks different in Lisp too.
Ok now do the part where lisp is actually used for any remotely useful project today...
> remotely useful project
Such a wide net though, what exactly constitutes a "remotely useful project" in your mind? Maybe if we figure out what the exact requirements are, we'll be able to help you with your search :)
This site is written in lisp
https://github.com/azzamsa/awesome-lisp-companies
Lololol
> ITA Software by Google Airfare search engine and airline scheduling software. Cambridge, MA. Common Lisp is used for the core flight search engine. The larger Flights project is roughly equal parts CL, C++, and Java.
Read the last sentence AND this company got acquired by Google like 15 years ago. So ya my question still stands.
You asked where Lisp is useful, and I supplied a list of companies that find (or, in some cases of recent history, found) Lisp useful. Your Google example is pertinent, because Google had the resources to wholesale eliminate its use of Lisp any time within the last 15 years, but for some reason worth pondering, hasn't. Instead, they continue to develop the product in Lisp, and continue to contribute to the Common Lisp open-source ecosystem.
But that aside, if you want a fresh look at what people are thinking about with Lisp, maybe check out the talks that were given this year at the 2025 European Lisp Symposium [1,2]. Or perhaps look at how someone shipped a platformer game on Steam with Common Lisp [3,4], and is in the finishing lap porting it to the Nintendo Switch [5].
I realize, though, that this kind of "debate" (?) is never satisfying to the instigator. If it does satisfy though, I will agree with you that—despite all of the claims of alleged productivity and power the language offers—Common Lisp remains far less popular than Python, which I assume is your only real point here.
[1] A presentation about how adding a static type system to Common Lisp à la Haskell helps write mission critical programs in defense and quantum computing: https://youtu.be/of92m4XNgrM
[2] A talk from employees of Keepit, a company that supplies a SaaS backup service, discussed how they train people on Common Lisp when employing them: https://youtu.be/UCxy1tvsjMs?t=66m51s
[3] Discusses technical details of how Lisp was used to implement a game that was actually shipped: https://reader.tymoon.eu/article/413
[4] The actual game that you can buy: https://store.steampowered.com/app/1261430/Kandria/ (This is not intended to be an advertisement and I'm unaffiliated. It's just a demonstration of a recently "shipped" product written in Common Lisp where you might not expect it.)
[5] Technical discussion of the Nintendo Switch port: https://youtu.be/kiMmo0yWGKI?t=113m20s
> Ok now do the part where lisp is actually used for any remotely useful project today...
> So ya my question still stands.
That list has 100 companies using lisp today. Were you actually asking if any new companies write in Lisp? Cuz those exist as well - in the same list...
Not sure you know what your own question is!
> That list has 100 companies using lisp today
https://en.m.wikipedia.org/wiki/Wikipedia:Spot_checking_sour...
Ah yes big lisp propaganda out there trying to convince you of the lie
Don't understand what this has to do with my point - do you think you're supposed to only verify "propaganda" sources?
Not surprising! You didn't make any point you just posted a link to a wikipedia page. Again, sources were posted and you cherry-picked one that still confirmed what you asked about. Nw you're doubling down/moving goalposts. Real companies use lisp, in 2025. It's not that big of a deal.
Emacs is one. Naughty Dog used a lisp for Jak and Daxter. Shows up in CAD software.
I really couldn't follow the use case. it looked like, they have a chain of method calls with some kind of `mark_circle().encode().properties()`, OK, so, if you want to make those methods do something different, you reach into OOP wisdom from the 1980s and write an appropriate "impl" used by whatever `alt.Chart()` is.
Someone explain to me, an old, aging programmer old enough to know UML, why this isn't some we presume very young person who has no idea how to write OOP coming up with some horrible convoluted way to do something routine?
> aging ... UML
Oh don't worry... they still cram that down our throats in CS undergrad in one of the courses.... Forget which one. I did my UG from 2020-24
;)
There is a reason similar approaches are called 'monkey patching'.
Just cause you can do something doesn't mean you should. I send thoughts and prayers for the people debugging programs where this is in place.
Also check the history of monkey patching
https://en.m.wikipedia.org/wiki/Monkey_patch
Ah, self-modifying code, the more things change the more they stay the same.
Wasn't SMC one of the LISP-associated AI fields a few decades ago? iirc it's been mostly abandoned due to security issues, but some of it survives in dynamic compilation.
this will be the next big breakthrough for agents lmao
Aka I just learned how to modify python code whilst it's running.
Next step, here's how to load modules, resolve a dependency. Handle capabilities and dynamically inject more functionality 'live'.
Patching running machine code in memory for compiled objects is the same but you just need to work around the abstraction that is introduced by languages trying to make the whole stack human parseable.
Other than Lisp, is it possible to do this in other languages?
Any language running on the JVM (Java, Kotlin, etc.) and CLR (C#, VB.NET, etc.). As long as you don't compile directly to native code and you aren't running in a locked-down environment where codegen is disabled, you can generate code at runtime and execute it alongside existing code.
For example, there's java.lang.reflect.Proxy [1] and System.Reflection.Emit [2].
[1]: https://docs.oracle.com/javase/8/docs/technotes/guides/refle...
[2]: https://learn.microsoft.com/en-us/dotnet/api/system.reflecti...
Several! You're correct that Lisps is the most famous, and there's also languages like Erlang that have this as a core functionality. But it's also used in things like game engines for C/C++. You do have your "updateAndRenderFrame()" function in a dynamic library, having it take a pointer to the full game state as an argument. When you want to reload, you recompile your dynamic library, and the main loop can swap out the implementation, and the game keeps running with the new code. I don't see a reason why you couldn't do this in Rust, though I imagine it's trickier.
And don't forget smalltalk!
The use case is not that obvious to me, but I _think_ it's trying to give the LLM more context to write code by dipping into these code objects. Perhaps telling the LLM what modules are already imported or otherwise available?
Creating a debugger for an LLM (not a human) is something I haven't really seen, but seems super useful...?
Neat trick indeed, but I have not yet found a compelling use-case for this that can't be done more sensibly using lambdas.
I once inherited a nice library which made heavy use of such compile/exec pairs. The code looked very convoluted and was very bug prone. I replaced all such pairs with lambda wrappers. This was much more readable: my colleagues who were also working on this code were like "oh is that what that was meant to be doing" after this change.
Monkey patching python modules is waaaaay more straightforward than this.
setattr(mod, name, new_func)
Greenspun's tenth rule, restated for Python instead of C/Fortran.
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
I did this by accident in bash scripts many years ago when I was just getting into linux. I'd be running a script, and editing the script at the same time. It caused some REALLY weird issues before I figured out what was happening. For instance I'd change the text somewhere and it would change in the running program, or the program would get into states it should never be in. I didn't use it constructively, I just avoided editing running programs after that.
I used live patching of the function byte code to enforce type safety in python as an experiment. It was quite fun, took about a weekend or so :) not something for production though, due to the performance hit.
One of the problem with dynamically loaded code like this is when you raise exceptions in those functions - the traceback will then end with something like `File "<magic>", line 8, in something`, which will at least annoy you when debugging.
I'm not sure what the point of this blogpost was. As far as I can tell, the author discovered eval() but is making it more complicated for no reason? There also isn't any actual patching going on.
I've contemplated patching Python's asyncio package so that the list of funcs isn't a weakref... but it's not that hard! This is way harder than it needs to be.
Different, but you may find interest in changing function signatures, too: https://github.com/dfee/forge
wait a sec ... i thought you could monkey patch python code. you can only do it by using this technique?
Another use case is applying small patches to a large function or method. Overriding would mean copy pasting largely similar code. It’s a bit ugly.
https://github.com/eidorb/ubank/blob/master/soft_webauthn_pa...
Concurrency?
Imagine if you've lisp to make ide and in a closed loop integration with LLM which extends and tests this IDE to achieve the task at hand.
Would it be much different than a REPL?
[dead]
Python being riddled with security anti-patterns -- or at least security-unfriendly ergonomics -- is one reason I tried to stop working with it.