You could certainly define homoiconicity as "zero syntactical distinction 
between data and code" – Clojure would pass this test because writing code 
and writing a list are exactly the same, whereas Julia would fail it.

This definition is perfectly valid, so the problem isn't that it's 
incorrect so much as that it's a really uninteresting criterion. I for one 
am not nearly as interested in syntax as the ability to produce and 
manipulate expressions, which is something that both languages obviously 
share.

Perhaps a better definition would be "the ability to quote language 
expressions", e.g. '(foo x y) or :(foo(x,y)). Clojure and Julia pass, 
JavaScript does not – and that actually tells you something about the 
abilities of the language.



On Wednesday, 7 May 2014 12:48:03 UTC+1, Isaiah wrote:
>
> 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] <javascript:>
> > 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
>>>>  
>>>
>

Reply via email to