The word "homoiconic" was removed from the official docs because it was not very informative and was occasionally contentious.
On Wed, May 7, 2014 at 4:03 AM, Ivar Nesje <[email protected]> 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. > > 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 >>> >>
