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