3 ms·

I heard about that. :-D Unfortunately, the module system's not enough. When R7RS-large hits, you'll hopefully finally be able to port between implementations b

I heard about that. :-D Unfortunately, the module system's not enough. When R7RS-large hits, you'll hopefully finally be able to port between implementations by simply cond-expanding your FFI interactions, and adding a makefile. With the the approaching release of Red, it looks like this may finally be happening. Clojure is definitely a lisp, but an odd one. It uses a foreign read syntax, is too close to Java for my tastes (reasonable people my disagree with my irrational hatred of Java), and it screws with Lisp tradition in ways even Scheme doesn't: Ways I don't think are necessarily for the better. () isn't nil, nil is kinda-not-really like scheme's #f, keywords aren't symbols, nil isn't a symbol, `x isn't the same as 'x, ~ is unquote, there are not cons cells, so cons doesn't do what you think it does, car and cdr don't exist afaik, but first and rest do, lambda is fn, which is also defun (or define in scheme), = is the new equal (or equal?), collections are more generic, and the whole thing is lazy. To conclude, the difference in spirit and ideas between Kawa and most other JVM lisps and Clojure is similar to the difference between *BSD and Linux: Clojure is what happens when a bunch of Java hackers write a lisp for the JVM, Kawa/ABCL is what happens when a bunch of Lisp hackers port a lisp to the JVM.

KingMob 10y ago
"Clojure is what happens when a bunch of Java hackers write a lisp for the JVM"? That sounds "clever", but you should be aware that Hickey developed several Lisps before Clojure and was active in the Common Lisp community in the years leading up to it. Also, some of your statements about Clojure are just incorrect; e.g., Clojure is not wholly lazy.
- qwertyuiop924 10y ago
  Well, the laziness yes, thanks for the correction, but much of it was from Clojure's own page about how it is different from other Lisps. And I am aware of Hickey's history. I was trying to provide a summary of the difference in outlook between Clojure and Kawa/ABCL: Clojure is decisively more "java-ey" than either of the others, and very much feels like a lisp for those already familiar with that language, with some FP on the side. I don't know if that's just my interpretation of Hickey's ideas, or if it was a deliberate design decision, or if it fell out of the Java interop. It could be any of them. But the language has a distinctly unlispy feel as a result, even though it IS a lisp, lack of cons cells not withstanding.
  - aidenn0 10y ago
    I always read the history as Hickey wanting first-class Java interop after his experience with FOIL[1]. In addition he wanted Clojure to be specifically for functional programming (something Common Lisp doesn't excel at). IMO, most of the things that make early versions of Clojure different from previous Lisps do fall out from the requirement of first-class Java interop and being opinionated about pure data being the Right Way to do multithreaded. From that point on Clojure is its own thing, and will naturally diverge. 1: http://foil.sourceforge.net/ http://foil.sourceforge.net/
  - lispm 10y ago
    I think we have to get rid of the idea that any language with parentheses is a Lisp. For all practical purposes languages like Scheme, Lisp, Clojure are fully incompatible on all levels: syntax, semantics and pragmatics. All they share are some distant ideas (some form of s-expression syntax, some form of macros, ...) provided in incompatible ways. They share no code, no libraries, no books, no community, ... that's a consequence of being different. Note that this says nothing about their usefulness for developing software.
    - qwertyuiop924 10y ago
      ...And I think we need to get rid of the idea that those differences necessarily precludes them from being Lisps. Because make no mistake, they are all Lisps. You said that they didn't share code, libraries, books, or community. First off, they do share community to some degree: there's a good bit of overlap between all of them. It's not all overlap, but there's plenty there. Second off, you know what other languages don't share code, library, or books with the Common Lisp we know today? MACLisp. Interlisp. Portable Standard Lisp. Lisp 1.5. Emacs Lisp. AutoLisp. ISLISP. Eulisp. Arc. To say nothing of Hy, LFE, MDL, Newlisp, NIL, Picolisp, and yes, Clojure and Scheme. And there are countless others. Lisp has always been a language of many different dialects. Why should we pretend it's any different now?
      - gkya 10y ago
        Second tthis. The term Lisp in CS is like Romance in linguistics, it indicates a family of languages that belong to different similar but not identical cultures which contribute to them and yet still the languages come from a common ancestor and are more similar than not while at times not easily mutually comprehensible.

KingMob 10y ago

"Clojure is what happens when a bunch of Java hackers write a lisp for the JVM"? That sounds "clever", but you should be aware that Hickey developed several Lisps before Clojure and was active in the Common Lisp community in the years leading up to it. Also, some of your statements about Clojure are just incorrect; e.g., Clojure is not wholly lazy.

qwertyuiop924 10y ago
Well, the laziness yes, thanks for the correction, but much of it was from Clojure's own page about how it is different from other Lisps. And I am aware of Hickey's history. I was trying to provide a summary of the difference in outlook between Clojure and Kawa/ABCL: Clojure is decisively more "java-ey" than either of the others, and very much feels like a lisp for those already familiar with that language, with some FP on the side. I don't know if that's just my interpretation of Hickey's ideas, or if it was a deliberate design decision, or if it fell out of the Java interop. It could be any of them. But the language has a distinctly unlispy feel as a result, even though it IS a lisp, lack of cons cells not withstanding.
- aidenn0 10y ago
  I always read the history as Hickey wanting first-class Java interop after his experience with FOIL[1]. In addition he wanted Clojure to be specifically for functional programming (something Common Lisp doesn't excel at). IMO, most of the things that make early versions of Clojure different from previous Lisps do fall out from the requirement of first-class Java interop and being opinionated about pure data being the Right Way to do multithreaded. From that point on Clojure is its own thing, and will naturally diverge. 1: http://foil.sourceforge.net/ http://foil.sourceforge.net/
- lispm 10y ago
  I think we have to get rid of the idea that any language with parentheses is a Lisp. For all practical purposes languages like Scheme, Lisp, Clojure are fully incompatible on all levels: syntax, semantics and pragmatics. All they share are some distant ideas (some form of s-expression syntax, some form of macros, ...) provided in incompatible ways. They share no code, no libraries, no books, no community, ... that's a consequence of being different. Note that this says nothing about their usefulness for developing software.
  - qwertyuiop924 10y ago
    ...And I think we need to get rid of the idea that those differences necessarily precludes them from being Lisps. Because make no mistake, they are all Lisps. You said that they didn't share code, libraries, books, or community. First off, they do share community to some degree: there's a good bit of overlap between all of them. It's not all overlap, but there's plenty there. Second off, you know what other languages don't share code, library, or books with the Common Lisp we know today? MACLisp. Interlisp. Portable Standard Lisp. Lisp 1.5. Emacs Lisp. AutoLisp. ISLISP. Eulisp. Arc. To say nothing of Hy, LFE, MDL, Newlisp, NIL, Picolisp, and yes, Clojure and Scheme. And there are countless others. Lisp has always been a language of many different dialects. Why should we pretend it's any different now?
    - gkya 10y ago
      Second tthis. The term Lisp in CS is like Romance in linguistics, it indicates a family of languages that belong to different similar but not identical cultures which contribute to them and yet still the languages come from a common ancestor and are more similar than not while at times not easily mutually comprehensible.