7 ms·

End user Lisp deployment is little, but Lisp use in commercial and scientific environment is not. It does not have the recent momentum spike that some other th

by gkya 10y ago

End user Lisp deployment is little, but Lisp use in commercial and scientific environment is not. It does not have the recent momentum spike that some other things have or had, but it has a stable-and-slightly-increasing momentum that it had since the beginning. Ruby has RoR and Go has cool guys and Google, but Lisp has been doing good without any of these all along. I don't see why Clojure is not Lisp. The only major problem with it is its memory demand, which is a problem it you don't have RAM in abundance. But it's been the first Lisp widely deployable thanks to Java, and thus all the deserved hype around it. The one big trouble in Scheme is the too-late standard module system. In absence of a standard, everybody created their own, so intercompiler portability is hard (although I'm not all that familiar, maybe I'm mistaken). Another problem is the name, as I can't say it without a blush here in Turkey :)

qwertyuiop924 10y ago
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.

by gkya 10y ago

qwertyuiop924 10y ago

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.