Exactly. But the "code-is-data" processing in Lisp mistakenly conflated with homoiconic does not depend on Lisp being interpreted. That interpreted Lisp is homoiconic is of no consequence. It's nothing worth implementing elsewhere.
Homoiconicity is just a poorly optimized, simple language implementation technique for low-resource systems. (Low resource because if you keep the program definitions in the program run-time, you don't need a separate copy in a text editor, which would take up more RAM. This is why old-fashioned line-number BASIC is homoiconic.)
Today, we have no need for it. For values of today being the last 30-40 years.
Source code is kept in the buffers of an IDE; there is no need to have it squirreled away in the run-time. A running image can load compiled code; the goal of redefining the program while it is active doesn't require homoiconicity.
Comments
Exactly. But the "code-is-data" processing in Lisp mistakenly conflated with homoiconic does not depend on Lisp being interpreted. That interpreted Lisp is homoiconic is of no consequence. It's nothing worth implementing elsewhere.
Homoiconicity is just a poorly optimized, simple language implementation technique for low-resource systems. (Low resource because if you keep the program definitions in the program run-time, you don't need a separate copy in a text editor, which would take up more RAM. This is why old-fashioned line-number BASIC is homoiconic.)
Today, we have no need for it. For values of today being the last 30-40 years.
Source code is kept in the buffers of an IDE; there is no need to have it squirreled away in the run-time. A running image can load compiled code; the goal of redefining the program while it is active doesn't require homoiconicity.