Indeed some of the lisp soul would be amputated in those languages, but that's usually done as a deliberate design and not as an unfortunate restriction. Sort-o

Indeed some of the lisp soul would be amputated in those languages, but that's usually done as a deliberate design and not as an unfortunate restriction. Sort-of-homoiconic languages (as in featuring a direct mapping between it's surface syntax and homoiconic representation, and support for manipulating the surface directly through quote/unquote) like Julia and Elixir (plus Nim, D, Rust, Scala and other languages with powerful macros) don't want macros to be your first thought when facing an issue, nor the second or third thought. In most Lisp your custom syntax is as first class as any standard syntax, which could lead to maintenance problems when every developer in the group could easily end up making his own poorly documented language to solve (even if perhaps optimally) a part of the problem. But in those other languages there is a first class way of doing something (a standard way of looping, standard way of conditional tests...), and macros are either discouraged or have to be annotated every time it's called to warn the user that the syntax ahead is not conventional. And macros are really there for the last resource when the surface syntax is really not expressive enough for the problem, and by then they'll be worth even when dealing with the AST in a much less convenient way.