Languages that aren't HomoiconicLanguages, because you feel like killing somebody for not adding that feature! ''Why? While homoiconicity is a sometimes useful property; I wouldn't put it on the top ten list of Things A Really Good Programming Language Must Do. Many fine languages are not homoiconic.'' Well, first off, I was joking, but since you seem interested... because languages that allow a style of code where the program itself doesn't get generated until runtime, are just freaking cool. It's like comparing a carpenter with a magician, sure, they could both get a job done, but the magician would do it prettier. Five lines that expand into fifty at runtime is just slicker than those same fifty at compile time. None of those are technical reasons, but who says I need technical reasons, when has cool ever been technical? On the technical side, why shouldn't I be able to extend the language? HomoiconicLanguages make RealMacros possible, allowing the ultimate in flexibility and abstraction. With HomoiconicLanguages and macros, you can extend the language to do anything, who wouldn't want that? ''Managers'' I'm not sure RealMacros are completely related to homiconicity. IoLanguage allows you to change everythin at runtime cause everything is stored as a text tree, but it does not seem homoiconic to me. ''IoLanguage is definitely homoiconic. To pass a chunk of the parse tree to a function, you just write it out:'' myFunction(this is a real parse tree(and so is this) (and this too)) ''Io expressions are modified S-expressions. ''(In fact, they're M-expressions except with parenthesis instead of square brackets.)'' They always take the form X(Y, ...), where X is a member of the list at its lexical level, and Y, ... forms a sub-list from the X AST node. People don't realize it, but Io is a lazily-evaluated language. The compiler will pre-evaluate expressions '''only''' if you explicitly designate a formal parameter in a method or block; if you do not, then you get the raw AST object instead. It is up to you to manually evaluate (or update if you're writing a macro) the express. This is why Io unifies both functions and macros; you can write a macro like if() just as easily as you can write a function, and using the exact same syntax. There is no analog to (defun) versus (defmacro).'' --SamuelFalvo See HomoiconicLanguageDrawbacks