8 ms·
In my opinion, this article puts too much emphasis on reading, and too little emphasis on actually reasoning about programs in homoiconic languages like Prolog
by zmonx 9y ago
In my opinion, this article puts too much emphasis on reading, and too little emphasis on actually reasoning about programs in homoiconic languages like Prolog and Lisp, and due to this imbalance the conclusion is not sufficiently justified.
It is true: Being able to "read without parsing" is definitely nice.
But that is only a subset of those advantages that a homoiconic language gives you. An at least equally important advantage is due to the fact that programs in homoiconic languages are typically very easy to reason about by built-in mechanisms in that language.
For example, Prolog programs are readily represented as Prolog terms, and can be easily reasoned about by built-in mechanisms such as unification.
Since I regard it as a key advantage of homoiconic languages that their abstract syntax is completely uniform and can typically be easily reasoned about within such languages, I disagree with the main point that the article is trying to make.
One interesting fact about homoiconicity is that extremely low-level languages (like assembly code) and extremely high-level languages (like Prolog) are homoiconic, yet there is a large gap "in the middle", where there are many languages (like Java, C, Python etc.) that lack this property.
- icebraining 9y agoAgreed; I've written Python code that processes Python code (both using ast and redbaron), and the result was quite opaque, unlike my metaprograms in Prolog. In fact, the macropy project[1] offers the "read" step (by abusing the import system), and while using them is pretty cool, I don't think the implementation of the macros is very nice. [1] https://github.com/lihaoyi/macropy https://github.com/lihaoyi/macropy
- kkylin 9y agoJulia is homoiconic but has much more complex syntax than Lisp. I personally find Julia macros harder to think about than Lisp or Scheme macros, partly for that reason.
- zmonx 9y agoPlease note that the creators of Julia no longer call it homoiconic [1]. The fact that you can access the AST in a language is not sufficient to make it homoiconic. There are several programming languages like Julia that let you access the AST yet are not (conventionally) considered homoiconic. [1] https://stackoverflow.com/questions/31733766/in-what-sense-are-languages-like-elixir-and-julia-homoiconic https://stackoverflow.com/questions/31733766/in-what-sense-a...
- kkylin 9y agoOh, I didn't realize that. Thanks!
- fao_ 9y ago> One interesting fact about homoiconicity is that extremely low-level languages (like assembly code) and extremely high-level languages (like Prolog) are homoiconic, yet there is a large gap "in the middle", where there are many languages (like Java, C, Python etc.) that lack this property. There are languages like picolisp and guile that try and fill that gap a little :)
- ASipos 9y agoI'd like to know more examples of this
- fao_ 9y agohttps://picolisp.com/wiki/?home https://picolisp.com/wiki/?home http://rosettacode.org/wiki/Category:PicoLisp http://rosettacode.org/wiki/Category:PicoLisp http://picolisp.com/wiki/?PilOS http://picolisp.com/wiki/?PilOS
- divs1210 9y agoHave you not heard of Clojure? https://clojure.org https://clojure.org
- catnaroek 9y ago> very easy to reason [sic] about by built-in mechanisms in that language. Languages allow you to express your reasoning, but they don't do the reasoning by themselves. Also, there is no conclusive evidence that homoiconic languages have simpler semantics, especially of the denotational kind.
- taeric 9y agoI think the meaning is that fewer things are implemented by bringing in outside capabilities. In lisp, everything's can be expressed in terms of other lisp code. Typically directly so. In other languages that are not as macro friendly, most keywords get the explanation of "this is how the computer will act" and then explanations of new behaviors.
- catnaroek 9y ago> In lisp, everything's can be expressed in terms of other lisp code. Um, and how exactly are primitive forms defined? > most keywords get the explanation of "this is how the computer will act" and then explanations of new behaviors. Have you heard of Hoare logic? The meaning of ordinary ALGOL-style imperative programs can be given in terms of relating preconditions to postconditions. Suppose that you have the Hoare triples: {P} foo {Q} {Q} bar {R} Then you can derive the Hoare triple: {P} foo; bar {R} Note that `Q` is not mentioned at all. Hence, any implementation is free to translate the program foo; bar into something that doesn't have `Q` as an intermediate state.
- taeric 9y agoYou seem to be arguing past me. If you are just upset that I said everything instead of most things, yeah, obviously some things are defined elsewhere. To that end, how things are actually implemented takes a trip to assembly. (I mainly blame that I'm writing in my phone. Often while in the bus.) My point was that you don't typically see c constructs explained in terms of other c constructs. This is quite common in lisp. To see lisp constructs explained in terms of other lisp constructs. In large because there are few constructs. You showing me that you can explain using other logic is kind of my point. It is awesome that you can do this. I recommend the skill. It is still not showing c or Java or Haskell or whatever in terms of themselves. Note that I think you actually can do this, in large. It is not typically done, though.