I like the civility of this discussion of what has, on occasion, been a rather contentious topic. It's really the only way to make any progress on these things. David Nolen and I had a similar discussion some time ago and came to the conclusion that homoiconicicity is a bit of a continuum – Lisps are very homoiconic, C is not homoiconic at all, and languages with some level of run-time reflection and code generation are all somewhere in the middle, with Julia being on the rather homoiconic end, but not as far as Lisp – largely because of the greater complexity of syntax to AST mapping.
I answers a slightly related question on stackoverflow the other day: http://stackoverflow.com/questions/23480722/what-is-a-symbol-in-julia/23482257#23482257 What does JavaScript use as symbols? Strings? (If strings, then what does it use to represent strings?) Could something as simple as having a first-class representation of variables be at the crux of the matter? It's the kind of thing that is awkward (but not impossible) to graft on later. > On May 7, 2014, at 3:58 PM, Ivar Nesje <[email protected]> wrote: > > I had never heard the word homoiconic before the discussion about the > documentation of Julia claiming that Julia could be described by that word. > After thinking about the various opinions my hunch is that the problem is > that homoiconic is on the borderline between describing the language design > concept (simple transformation rules from written code -> a AST > representation) and a style of programming (where a program modifies its own > source before evaluating the resulting code). > > The question is not really how do you define homoiconic, but what you use the > word to describe. I don't think it is very useful to describe a language with > such abstract words, and interpret such claims as describing a idiomatic > programming style. You might disagree on that point, and I guess we might > have a different perspective when we use words to describe a programming > language. > > > PS: I got the quizz wrong :( > It was not :call > > > kl. 20:27:46 UTC+2 onsdag 7. mai 2014 skrev Jason Merrill følgende: >> >> >> >>> On Wednesday, May 7, 2014 1:03:53 AM UTC-7, Ivar Nesje wrote: >>> Great! >>> Finally I got a definition of homoiconic that Julia does not fulfill. >>> According to Jason, homoiconicity has nothing to do with language >>> features/standard library features or how you are encouraged to structure >>> your code to get an idiomatic program, but is solely a vague measure of the >>> complexity of the parser for "syntactic code"->AST transformation. >> >> That's a little bit snarky, but I guess it's pretty much a correct >> characterization of what I was saying. The "icon" part of homoiconic is >> supposed to evoke "writing", so I really do think the term was supposed to >> have something to do with how the code is written, i.e. the syntax. >> Specifically, the internal representation is supposed to be "the same" >> (homo) as the way that the code is written (icon). >> >> If you accept that, then everything hinges on what "the same" really means, >> which I agree is a little bit vague. Obviously it can't just mean that there >> is a mapping from syntax to internal representation, because there always >> is. So I think it must mean that the mapping must be unusually simple. >> >> The simplicity of this mapping actually does matter, to some degree. Quick >> quiz: what is the output of >> >> julia> :(x<4).head >> >> Maybe you know the answer already, but you generally have to try these >> things out to find out the answer. In a language like scheme, there is no >> translation layer where you might not know what the AST of some syntactic >> construct looks like. In that way, it's easier to meta-program a language >> like scheme than it is to meta-program a language like Julia that has much >> more diverse syntax. Not to say that it's onerous to meta-program Julia--it >> really isn't--but there definitely is more cognitive overhead along this one >> axis. >> >> There's also an idea floating around that homoiconic means that code can be >> represented (internally?) using the primitive datastructures of the >> language. This seems like a pretty empty requirement to me. What language >> doesn't have datastructures that are up to the task of representing an AST? >> >> Do you prefer some other definition of homoiconic? >> >>> By that definition Julia fails, because the syntax is created to be simple >>> humans to write and read to express ideas, and the AST is designed to be >>> easy for a human to work with through a machine. The transformation between >>> is complex and not one to one. >> >> Yes, exactly. "homoiconic" is not a synonym for "good". It's a tradeoff >> between uniformity and expressiveness, or uniformity and readability, or >> uniformity and familiarity, or something like that. >> >>> Ivar >>> >>> >>> kl. 09:12:44 UTC+2 onsdag 7. mai 2014 skrev Jason Merrill følgende: >>>> >>>> Glad to hear that you've been enjoying picking up Julia. I've felt the >>>> same way about Julia having a more gradual on-ramp than some other cool >>>> languages. You don't have to wrap your head around a new paradigm to get >>>> started, but there are lots of nice advanced features waiting for you when >>>> you're ready. >>>> >>>> Re homoiconicity: I know a lot of people have been saying that Julia is >>>> homoiconic, but I don't really buy it. Is the claim that any language that >>>> gives you access to the parser and eval at runtime is homoiconic? >>>> >>>> Let's consider Javascript for a second. 5 years ago, I don't think anyone >>>> would have said that Javascript is homoiconic. But now there are >>>> javascript parsers like Esprima and Acorn written in javascript, so you >>>> can take a string of JS code, parse it into an AST at runtime, traverse >>>> and manipulate the AST the same way you traverse and manipulate other >>>> objects, and then emit and eval new code. Did JS become homoiconic when >>>> someone wrote Esprima? I don't really think so. >>>> >>>> In my mind, syntax is relevant to homoiconicity. For a language to be >>>> homoiconic, the map from syntax to AST should be very simple; or in other >>>> words, the parser should be fairly trivial. This is true of Lisp, but not >>>> really true of Julia. Incidentally, the parsers of concatenative languages >>>> like Forth are even simpler than for Lisp, and more modern concatenative >>>> languages like Joy and Factor take advantage of this in really cool ways. >>>> >>>> All that said, I think the people who say Julia is homoiconic would be >>>> right if they instead said that Julia gives you the power to do most of >>>> the things that people take advantage of homoiconicity to do in homoiconic >>>> languages. Meta-programming Julia really isn't too bad at all. >>>> >>>>> On Tuesday, May 6, 2014 8:15:36 PM UTC-7, Abram Demski wrote: >>>>> Hi all! >>>>> >>>>> I've been using Julia for a little over a month now, and I thought it >>>>> would be fun/informative to write a little post about my experience. >>>>> >>>>> I'm mostly a Common Lisp guy. I write AI code in an academic setting. >>>>> However, I recently became enthusiastic about Clojure and was trying to >>>>> start a project in that. >>>>> >>>>> Indecisive as usual, I continued poking around looking for the best >>>>> programming language to do the project in, even as I became fairly >>>>> committed to doing it in Clojure. >>>>> >>>>> I had heard about Julia some time ago (looked at it very briefly), but >>>>> looked at it a second time when a friend mentioned it on twitter earlier >>>>> this year. >>>>> >>>>> Looking at it again, I realized that: >>>>> >>>>> 1) Julia is "essentially a Lisp", IE, it is homoiconic (despite not >>>>> appearing so) and has the metaprogramming capabilities I am used to. (I >>>>> don't need these often, but if a language lacks it, I feel like I'm >>>>> missing an essential tool.) >>>>> 2) Julia's type system and multiple dispatch capabilities give me much of >>>>> what I liked about Clojure's multimethods and protocols. >>>>> 3) Julia is significantly faster (at least for many things). >>>>> >>>>> I decided to start hacking out my project in Julia, abandoning the >>>>> Clojure code I had started. >>>>> >>>>> After using it for a bit, I feel like it's been much easier to pick up >>>>> what I need to know than it was with Clojure. Both Julia and Clojure have >>>>> the deep, elegant stuff I like in a programming language; however, it >>>>> seems like Clojure creates a rich, interlocking set of concepts which you >>>>> must learn in order to write very much code, whereas Julia has a gentle >>>>> learning curve, facilitating "normal" programming and allowing the user >>>>> to learn the deeper features as they become useful. At least, that's been >>>>> my feeling. >>>>> >>>>> Monkeying around with the metaprogramming has taught me that it's a bit >>>>> less convenient than Lisp. Thinking about expr.head and expr.args is not >>>>> as intuitive as composing expressions as lists, I think. It's not a big >>>>> obstacle, though. >>>>> >>>>> I've also found it a bit annoying that array access is not the same as >>>>> function application, again a feature of Clojure. Being able to treat >>>>> arrays and dictionaries as functions is convenient for certain >>>>> higher-order functions like map. >>>>> >>>>> Overall, although I admit I'm judging Julia by Lisp/Clojure standards, it >>>>> comes out rather favorably. :) >>>>> >>>>> -- >>>>> Abram Demski >>>>> Blog: http://lo-tho.blogspot.com/ >>>>> Leave anonymous feedback: http://www.admonymous.com/abramdemski
