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 :)
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
(defclass foo ()
((a :initarg :a)))
to (defclass foo ()
((a :initarg :a)
(b :initarg :b)))
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.
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.
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.
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.
transform = Replace(pattern="$x + $y", replacement="($x + 1) + $y")
transform("1 + 1") # "(1 + 1) + 1
transform("3 + 4 + 5") # "(((3 + 1) + 4) + 1) + 5
transform("10 * 1 + 1") # no change, because the expression is actually (10 + 1) + 1
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. ast-grep --pattern 'var code = $PAT' --rewrite 'let code = $PAT' --lang js
https://ast-grep.github.io/guide/introduction.htmlDynamic 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
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.
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.
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
> 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!
https://en.m.wikipedia.org/wiki/Wikipedia:Spot_checking_sour...