Disclaimer: I don't know anything about Julia, except from reading a couple simple programs just now, and seeing that it uses syntax that looks somewhat like Algol.

I don't think there's any inherent contradiction between the two, depending on what you mean by "the power of homoiconicity" (1). Homoiconicity doesn't mean you need to use lists: you could make a language like C but with native structures to hold all of the syntax. It's just that "cons cell and symbol" happen to be a really simple set of tools from which you can build everything you need.

I suspect that languages that try to have both do it by sacrificing simplicity. They have syntax that looks like C, and then make it homoiconic by building essentially a DOM for all of that syntax. Perhaps the idea is that writing and reading "x = y + z" is deemed sufficiently common that they're OK with making metaprogramming more complex if they get to keep Algol syntax.

(1) By "depends on what you mean", I meant: is simplicity requisite for power? I would say "yes", but I can imagine there's someone who would say "no" and consider Algol-plus-DOM (is that what Julia is?) to be as powerful as simpler languages.

A DOM would give the benefits of homoiconicity, though the quote is We want a language that’s homoiconic. As an example, recent versions of Java include the compiler in Java, and therefore the classes for the AST (though undocumented). That's a DOM; you can use it to implement macros. (There's also ANTLR and BCEL to do AST twiddling - just consider them part of the standard classes of a Java variant).

But I think to be homo- (same) iconic (symbols), the language has to be those symbols. By this strict definition, it has to be a lisp. Maybe there's a looser definition possible, between a DOM and Lisp. I think a parallel lisp-syntax would do it (i.e. you can write everything using a lispy syntax; but there's also a friendlier syntax.

hmmmm, you could do this for any language, provided a AST representation (i.e. lispy) syntactically unambiguous with the rest. That subset of the language would then be homoiconic. e.g. add a first-class AST syntax to Java. Is that the kind of DOM you were thinking of?

Good point. I guess I'd agree that it "has to be those symbols", but not that it has to be a Lisp. I don't know Java's new AST classes, but if I could say something like:

    public class HelloWorldApp {
      public static void main(String args[]) {
        System.out.println("my class name is: " + HelloWorldApp.Ast.Name);
        System.out.println("i have " + HelloWorldApp.Ast.Methods.Length + " method(s)");
      }
    }

then I would consider that "homoiconic": the things I'm defining are objects in the language itself. It doesn't sound like Java does that. My guess is that the AST is only available for text you pass to the compiler at runtime.

That's a problem, in Java: the compilation model is so constrained that even if you could write this, I don't think you could use it to make macros, since there's no way to control "read-time" versus "compile-time" versus "run-time" as you can in Lisp. So perhaps homoiconicity isn't enough: you need that, plus something like EVAL-WHEN.

That's your DOM idea; I'd argue it's not homoiconic, because it's too indirect. But I wouldn't argue very strenuously as I don't know the actual definition of homoiconic. :-)

You're right that the AST is available only for passed text; I hadn't thought of that as a limitation, but you're right. I was thinking of macros, that you define and manipulate within a program: the limitation doesn't affect this use case. Doing it this way, you also get control of {read,compile,run}-time.

I think it's fair to say there are degrees of homoiconicity; you can get some of the benefits by having just a subset of the features. I conject that "a language with full homoiconicity" is identical with "a lisp" - but it doesn't really matter, if we're interested in benefits.