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.
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. 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 >> >
