7 ms·

The article does not mention clojure, which is an acceptable Lisp.

• ynniv 17y ago
  The article was written before clojure.
  • dagw 17y ago
    Found reading it (again) now in light the ongoing hype surrounding Clojure almost more interesting than I did reading it the first time.
• raganwald 17y ago
  True, although I wouldn't go so far as to say it is "obsolete." That being said, English is a rather ambiguous language. Obsolete might mean it has nothing of value for the reader, and it also might mean there have been some developments since its publication so be sure to do further reading. Given that Clojure is not the only Lisp, I feel the article is still relevant although comments like yours and another poster pointing out the value of Clojure add value for readers.
• andreyf 17y ago
  Clojure is not an acceptable Lisp. It's a step in the direction of Lisp from Java, but is a step backwards from most other Lisps.
  • jamesbritt 17y ago
    How so? I've been pondering Clojure as "Lisp with Java libs! Hooray!", but if there are notable flaws in its Lispiness I'd like to hear about them.
    • jon_dahl 17y ago
      I think the common complaint is that that it isn't really Lisp all the way down - it's Lisp syntax that drives the JVM. Therefore, it is a False Lisp; it dresses like Lisp, and convinces the unwashed that it's Lisp, but it's actually leading us astray. See http://www.loper-os.org/?p=42 http://www.loper-os.org/?p=42 for more.
      • andreyf 17y ago
        it's Lisp syntax that drives the JVM See, this wouldn't bother me so much if it assumed the user knew the JVM instruction set and built up abstractions around it. But no, that's not what it does. It creates another "language", meaning "obscuring abstraction" that isn't friendly to inspection.
    • andreyf 17y ago
      I should have expounded in original post, thanks for asking. There are many points, the one I'm thinking about in particular has to do with what Lisp is. I conced that Cojure is in the family of Lisp languages because it has the s-exp syntax and the macros. However, it's a step back in The Philosophy of Lisp, because it doesn't allow user-defined reader macros. First let me explain what I see the philosophy of Lisp - it is the late-binding of all things. Late-binding, in this sense, means that the system by which you make the computer do the things you want it to (we usually call them "languages") makes as few decisions as possible, and lets the user overwrite and extend them. For example, the Python mailing list every once in awhile has an active debate if anaphoric `aif' should be allowed in the language [0]. This would mean adding a special symbol `it', such that: aif expensive_function_call(): foo(it) is an equivalent to: it = expensive_function_call() if it: foo(it) GvR decided against it, after weighing the needs of the Python community. The late-binding that I see as inherent in The Lisp Philosophy says that decisions like these are personal decisions to be made as late as possible (certainly not when you're designing a system of computational expression), and certainly not for all users. Each user should be able to define aif to mean whatever they feel it does. The current popular counter-argument is that this would shatter languages into a personal dialects that nobody but themselves and their best friend would understand. The Lisp family of languages disagrees, and hence, supports macros. Cojure, for this reason, supports macros [1]. However, there are two kinds of macros Lisp supports for the same reason: "syntax macros" which let you late-define how syntax is interpreted, and "reader macros", which let you define how the parser interprets your syntax (the Lisp parser is called the reader). For example, the reader of Clojure translates '(foo) into (quote foo), #{:x} into (hash-set :x), [x y z] into (vector x y z), etc. However, the rules by which the reader translates those "special" deviations from normal s-expression syntax into s-expressions is closed off from modification. This goes against The Lisp Philosophy, and is not so in other Lisps [2]. The only case for this I've heard (in Stuart Halloway's "Programming Clojure") is that this would allow people to dilute the language into something which is no longer Clojure. This explicit early binding is a step back in what I see as the Philosophy of Lisp because brings us back to the religious tribalism of "this is Clojure, and the language decisions that were made are good decisions, and if you don't like them go fuck yourself". 0. http://en.wikipedia.org/wiki/Anaphora_%28linguistics%29 http://en.wikipedia.org/wiki/Anaphora_%28linguistics%29 1. The analogy I like best here is to mathematics. Any mathematician can create his own definitions to explain his ideas (as they usually do), and yet, mathematics doesn't break up into dialects that nobody can understand. Instead, mathematical language evolves as people participate - if you have a pet definition you like (maybe one you thought up all on your own!) you don't need to convince Guido or some council of language makers to be able to use it. You use it, and if your paper is worth reading, maybe you can convince other people to accept it. That way, mathematics as a language evolves, not by design, but by social interaction. The formal languages of computation can (and should) do the same. 2. http://www.psg.com/~dlamkins/sl/chapter03-12.html http://www.psg.com/~dlamkins/sl/chapter03-12.html