2 ms·

> I think titles like 'The problem of Lisp' may need a bit more reflection and patience. Forgive me for the baity title ;) I realise this is not a new discover

> I think titles like 'The problem of Lisp' may need a bit more reflection and patience. Forgive me for the baity title ;) I realise this is not a new discovery. > Python and Ruby use flat strings as input to eval. That's an entirely different thing. I understand this. I was responding to the earlier assertion "Neither Ruby nor Python support the idea of 'code is data'." which is not entirely correct. You can clearly supply code as string data. (Python's namedtuple does make use of this). It's just not nearly as powerful. Thanks for providing the examples. The infix macro is pretty amazing! I will make use of this #I stuff.

lispm 8y ago
> Neither Ruby nor Python support the idea of 'code is data'." which is not entirely correct. You can clearly supply code as string data That's just some kind of eval feature. Many languages can execute strings of code at runtime - for example one could write C code to a tmp file, call the compiler, and load the object file -> that's how some Lisp-to-C compilers work. But it's just the usual C code as text. That's not 'code is data'. Code is data means that code is actually written in a data structure which is serialized and de-serialized. In Lisp code is written as s-expressions. 'code is data' does not mean I can treat code as a string and evaluate it, it means: code is actually read, written and manipulated as structured data - and not as blob of text. Ruby code is written as textual Ruby code, where Lisp is written as Lisp programs in s-expressions. What you tell me is the code is text, which can be somehow executed at runtime, which is an entirely different thing.