6 ms·

I was actually suggesting that I can't believe people still use CL when Clojure exists... I await my lynching. :D

by ibdknox 13y ago

pnathan 13y ago
Well, since you threw that out there... ...I can't believe that people use Clojure-the-language over CL-the-language. It seems to have no reason to exist except as a "I hate parens" Lisp-1. The interesting parts of Clojure (i.e., the sequence abstraction design) are replicatable in CL as a library. Extant issues (e.g., cl's map not mapping over vectors)* can be abstracted over with other tools. While the JVM interop is compelling, I don't understand why the libraries and macros to create similarly compelling interop over ABCL weren't developed instead. Bluntly, I don't know why Clojure was created as a new language instead of an advanced library over Common Lisp. I appreciate the interest it's been able to drum up in the Lisp family, and I deeply appreciate the libraries people have written for it. *: I was wrong: map goes over a variety of types: mapcar, mapcan, etc, are common and only operate on lists. Ignorance uncovered and filled in by knowledge.
- gajomi 13y ago
  >Bluntly, I don't know why Clojure was created as a new language instead of an advanced library over Common Lisp I think you basically answered your own question :) >JVM interop is compelling
  - pnathan 13y ago
    But the thing is, Armed Bear Common Lisp (ABCL) already offers JVM interop. If someone sat down and really massaged it, the currently clunky interop there could be just as shiny as Clojure.
    - loumf 13y ago
      Rich Hickey's previous projects to clojure were all about Lisp<->JVM interop (see http://foil.sourceforge.net/ http://foil.sourceforge.net/, but there is at least one other) -- so I think he found limitations to what you can do.
    - coldtea 13y ago
      >But the thing is, Armed Bear Common Lisp (ABCL) already offers JVM interop. Yes, a half-arsed, barely supported interop. And slow to top. >If someone sat down and really massaged it, the currently clunky interop there could be just as shiny as Clojure. I rest my case.
- enduser 13y ago
  The only reason I can understand for the existence and use of Clojure is interoperation with Java and because Clojure is more actively developed than ABCL. The big question to me is why people who do not need Java interop are using Clojure. Here are some reasons I can think of: - The tooling around Clojure feels more familiar to Ruby/Python/Node programmers. - Ruby/Python programmers need their programs to run slowly so that they can be certain something is happening. - Cult of personality. Rich Hickey has a lot of great videos and conference presentations. Lisp has no apparent technical or thought leader. Followers need leaders. - Hubris. The same stupidity that causes organizations to throw out Robert's Rules of Order and then subsequently reinvent non-standard solutions to the problems RR was created to solve in the first place. P.S. CL's map works with all sequences, including vectors.
  - pnathan 13y ago
    Apologies to CL. I usually use MAP(CAR|CAN). I hadn't investigated MAP itself due to the extra parameter.
  - rayiner 13y ago
    To be fair, unlike Ruby/Python/JS, Clojure actually tries to solve a relevant problem in a new way (concurrency). It is something that probably could have been built on top of Common Lisp, but at the same time, there is something to be said for having a relevant paradigm baked into the standard library from the beginning.
  - Tuna-Fish 13y ago
    Nice way to ignore the big one. It's less than one fifth of the age of CL, yet it has vastly superior libraries. Part of this is the Java interop, but at this point, even Clojure native libraries tend to be just better than CL libraries. The reason for this is probably the common focus on good, sensible defaults and less on "everyone can easily roll their own". Having a set of basic, sensible data structures and abstractions that everyone share is not the same thing as "well, it's easy for anyone to do this". The idea that CL is flawless because it's so powerful that all flaws can be fixed by users is a disease, not a strength. It leads to a community where work is massively duplicated because all libraries are designed for a specific use, and every user needs to bend them to his uses.
- snprbob86 13y ago
  You're dangerously close to trolling, but I'll comment anyway. > a "I hate parens" Lisp-1 Clojure's minimal syntax is, in my opinion, a gigantic improvement over Common Lisp. And I say this as a person who quite likes parens. I feel similarly about Lisp-1s, but that is well trotted territory: Lisp-1s have won. Parens are overloaded in traditional Lisps for both invocation and grouping. The introduction of vectors with square brackets makes a lot of code a great deal more readable at virtually zero cost: It's still homoiconic. Similarly, the inclusion of curly braces for maps is wonderful, as it makes maps a lot more common in Clojure than they would otherwise be in CL, which is a good thing for most business logic. > replicatable in CL as a library Defaults matter. A lot. Presence in a library is insufficient. The fact that seqs et al are in core means that 100% of Clojure libraries use those abstractions. That's a big deal. > I don't understand why the libraries and macros to create similarly compelling interop over ABCL weren't developed instead Rich discussed this on the CL mailing lists long before Clojure or even his first attempt, dotLisp, ever existed. See [1] and [2]. In short, interop needs to be planned for at the lowest levels to make it pleasant to use and efficient to execute. And it's not just JVM interop: Clojure was designed for $SOME_HOST interop, so ClojureScript interops as nicely with JavaScript as Clojure does with the JVM. CL would have two different libraries with two different ideas of interop for two different host platforms. > I don't know why Clojure was created as a new language I think you have a different definition of the word "language" than I do. Look at PG's Arc. It's built on a scheme implementation. It's not so much a new language by your definition as it is a set of scheme libraries. But that's what a language is: A common base vocabulary encoded with a well known set of syntax and semantics rules. Clojure could be implemented (quite trivially, thanks to the aforementioned careful hosting design) as a set of libraries to CL, but it would still be a new language. [1] https://groups.google.com/d/msg/comp.lang.lisp/3-X76dTw8dI/I2oOzMg4G-MJ https://groups.google.com/d/msg/comp.lang.lisp/3-X76dTw8dI/I... [2] https://groups.google.com/d/msg/comp.lang.lisp/3-X76dTw8dI/sJOFnp1puKMJ https://groups.google.com/d/msg/comp.lang.lisp/3-X76dTw8dI/s... Snippet from [2]: If one were starting from scratch, and supplied a platform like .NET, would one define Lisp the way CL is defined? I would hope the answer is 'most definitely not'. For instance, .NET provides for numbers, characters, strings, arrays, hashtables, exceptions, namespaces, files, streams, user-defined types, a type hierarchy and inheritance, I/O, object creation and initialization, reflection etc. Should a language define its own incompatible versions of these things in such an environment?
- rprospero 13y ago
  Honestly, I'm far more of a Schemer than a... Clojurite?Clojurist? Clojourneyman? I did try to make the switch to Common Lisp back in 2006, but I wasn't happy and went back to Scheme. Still, I'm far more interested in learning Clojure than giving Common Lisp another try. Here's what makes the difference for me: 1)Library support. With Clojure, it's a five minute import to get Bessel functions. When I asked about how to do Bessel functions in 2006, I was told to write it myself. I've heard things have become better since then, but I haven't been able to find any evidence that 2)Immutable data structures. Yes, this can be implemented as a library in CL. However, having it as the default means that I know every non-Java function I call isn't going to break that assumption. If I did find a Bessel function library, I can't assume that it's safe. 3)GUI support. In 2006, I needed to write a GUI application that ran on Windows, Mac, and Linux. PLT Scheme (now racket) had options available, but they weren't pretty. When I went to Common Lisp, I was first directed toward CLX, which wasn't native on Mac or Windows. Someone then suggested McClim, which still needed an X-server on Windows and now seems to be largely dead. It was then suggested that I write my own binding to WXwidgets. I considered that, but I'd then need to write a high level wrapper over those low level bindings. Comparatively, from the little I've toyed with the Seesaw library from Clojure, it seems to be a beautiful way of handling GUIs. Okay, I guess this comes down to another library issues. 4)Dotted pairs. The only use I've ever encountered for these is extremely fine tuning performance optimizations, but third party libraries loved surprising me with these at odd moments. I can see how Lisp-1 versus Lisp-2 might be a matter of taste, but I've never heard someone complain that how they missed dotted pairs when working in Scheme or Clojure. They may be a good argument, but I've never heard it. 5) Libraries. I'm sorry that I keep coming back to this point, but I guess it's a big one. Every time I tried to do something interesting in Common Lisp, the recommendation that I was given was to write low level wrappers to three different C libraries. For several of those projects, I found it easier to just cut out the middle man and write the whole damn thing in C. The rest of the time, I wound up writing Lisp that looked almost exactly like C. Honestly, half of this is because I'm a mediocre programmer. I have no pretensions of greatness. If I was a great programmer, I could see how to make my own DSL that made the interaction of the libraries beautiful, instead of C with more parentheses. However, in scheme or clojure, I can usually find the work of another, better programmer, who has already made that DSL. In Common Lisp, I'm usually told to write it myself. I don't know if that's because all the other Common Lisp programmers are so brilliant that they all write DSLs all day or if it's just because they're all mediocre programmers like myself and no one knows how to do it. 6) Global variables. Every examples of idiomatic Common Lisp code I was delivered was littered with globals. This might be a stylistic decision, but it's one I've never liked. A third of my problems seemed to be solved by setting OPEN-NETWORK-SOCKET-AND-SET-FIRE-TO-PRINTER to 1 and STOP-PRINTER-FIRE to nil. I can see this reliance on globals if you're writing servers, where you have a long running application with lots of state, but I wasn't, so it just made the code harder to reason about. 7)Image based programming. I understand from the SmallTalkers that this is the best way to write code, but I don't get it. What always happened for me was that some global SWITCH-CHARACTER-ENCODING-TO-EBCDIC would get set at some point and all my code would now fail. With a file based language, I'd exit and restart to kill this accidental state and everything would be okay. With the image based code, I'd have to go through the assorted globals and find which one had changed.
- coldtea 13y ago
  >The interesting parts of Clojure (i.e., the sequence abstraction design) are replicatable in CL as a library. The interesting part of Clojure for me is that the sequence abstraction design is part of the standard language distribution and NOT implemented as an optional library. The major flaw with Lisps is exactly the proliferation of competing, (and frequently half-arsed), custom solutions for stuff that should be built-in and used by all. I'll take a slightly inferior implementation of something that's standard in a language's libs, over 20 competing solutions or rolling my own, any day of the week.
- abp 13y ago
  http://www.drdobbs.com/architecture-and-design/the-clojure-philosophy/240150710/ http://www.drdobbs.com/architecture-and-design/the-clojure-p...
radicalcut 13y ago
Yeah, they do. And there's quite many of them actually. :-) Clojure might be big in the startup bubble, but that's about it I'm afraid.

I was actually suggesting that I can't believe people still use CL when Clojure exists... I await my lynching. :D

by ibdknox 13y ago

I was actually suggesting that I can't believe people still use CL when Clojure exists... I await my lynching. :D

Well, since you threw that out there... ...I can't believe that people use Clojure-the-language over CL-the-language. It seems to have no reason to exist except as a "I hate parens" Lisp-1. The interesting parts of Clojure (i.e., the sequence abstraction design) are replicatable in CL as a library. Extant issues (e.g., cl's map not mapping over vectors)* can be abstracted over with other tools. While the JVM interop is compelling, I don't understand why the libraries and macros to create similarly compelling interop over ABCL weren't developed instead. Bluntly, I don't know why Clojure was created as a new language instead of an advanced library over Common Lisp. I appreciate the interest it's been able to drum up in the Lisp family, and I deeply appreciate the libraries people have written for it. *: I was wrong: map goes over a variety of types: mapcar, mapcan, etc, are common and only operate on lists. Ignorance uncovered and filled in by knowledge.

gajomi 13y ago
>Bluntly, I don't know why Clojure was created as a new language instead of an advanced library over Common Lisp I think you basically answered your own question :) >JVM interop is compelling
- pnathan 13y ago
  But the thing is, Armed Bear Common Lisp (ABCL) already offers JVM interop. If someone sat down and really massaged it, the currently clunky interop there could be just as shiny as Clojure.
  - loumf 13y ago
    Rich Hickey's previous projects to clojure were all about Lisp<->JVM interop (see http://foil.sourceforge.net/ http://foil.sourceforge.net/, but there is at least one other) -- so I think he found limitations to what you can do.
  - coldtea 13y ago
    >But the thing is, Armed Bear Common Lisp (ABCL) already offers JVM interop. Yes, a half-arsed, barely supported interop. And slow to top. >If someone sat down and really massaged it, the currently clunky interop there could be just as shiny as Clojure. I rest my case.
enduser 13y ago
The only reason I can understand for the existence and use of Clojure is interoperation with Java and because Clojure is more actively developed than ABCL. The big question to me is why people who do not need Java interop are using Clojure. Here are some reasons I can think of: - The tooling around Clojure feels more familiar to Ruby/Python/Node programmers. - Ruby/Python programmers need their programs to run slowly so that they can be certain something is happening. - Cult of personality. Rich Hickey has a lot of great videos and conference presentations. Lisp has no apparent technical or thought leader. Followers need leaders. - Hubris. The same stupidity that causes organizations to throw out Robert's Rules of Order and then subsequently reinvent non-standard solutions to the problems RR was created to solve in the first place. P.S. CL's map works with all sequences, including vectors.
- pnathan 13y ago
  Apologies to CL. I usually use MAP(CAR|CAN). I hadn't investigated MAP itself due to the extra parameter.
- rayiner 13y ago
  To be fair, unlike Ruby/Python/JS, Clojure actually tries to solve a relevant problem in a new way (concurrency). It is something that probably could have been built on top of Common Lisp, but at the same time, there is something to be said for having a relevant paradigm baked into the standard library from the beginning.
- Tuna-Fish 13y ago
  Nice way to ignore the big one. It's less than one fifth of the age of CL, yet it has vastly superior libraries. Part of this is the Java interop, but at this point, even Clojure native libraries tend to be just better than CL libraries. The reason for this is probably the common focus on good, sensible defaults and less on "everyone can easily roll their own". Having a set of basic, sensible data structures and abstractions that everyone share is not the same thing as "well, it's easy for anyone to do this". The idea that CL is flawless because it's so powerful that all flaws can be fixed by users is a disease, not a strength. It leads to a community where work is massively duplicated because all libraries are designed for a specific use, and every user needs to bend them to his uses.
snprbob86 13y ago
You're dangerously close to trolling, but I'll comment anyway. > a "I hate parens" Lisp-1 Clojure's minimal syntax is, in my opinion, a gigantic improvement over Common Lisp. And I say this as a person who quite likes parens. I feel similarly about Lisp-1s, but that is well trotted territory: Lisp-1s have won. Parens are overloaded in traditional Lisps for both invocation and grouping. The introduction of vectors with square brackets makes a lot of code a great deal more readable at virtually zero cost: It's still homoiconic. Similarly, the inclusion of curly braces for maps is wonderful, as it makes maps a lot more common in Clojure than they would otherwise be in CL, which is a good thing for most business logic. > replicatable in CL as a library Defaults matter. A lot. Presence in a library is insufficient. The fact that seqs et al are in core means that 100% of Clojure libraries use those abstractions. That's a big deal. > I don't understand why the libraries and macros to create similarly compelling interop over ABCL weren't developed instead Rich discussed this on the CL mailing lists long before Clojure or even his first attempt, dotLisp, ever existed. See [1] and [2]. In short, interop needs to be planned for at the lowest levels to make it pleasant to use and efficient to execute. And it's not just JVM interop: Clojure was designed for $SOME_HOST interop, so ClojureScript interops as nicely with JavaScript as Clojure does with the JVM. CL would have two different libraries with two different ideas of interop for two different host platforms. > I don't know why Clojure was created as a new language I think you have a different definition of the word "language" than I do. Look at PG's Arc. It's built on a scheme implementation. It's not so much a new language by your definition as it is a set of scheme libraries. But that's what a language is: A common base vocabulary encoded with a well known set of syntax and semantics rules. Clojure could be implemented (quite trivially, thanks to the aforementioned careful hosting design) as a set of libraries to CL, but it would still be a new language. [1] https://groups.google.com/d/msg/comp.lang.lisp/3-X76dTw8dI/I2oOzMg4G-MJ https://groups.google.com/d/msg/comp.lang.lisp/3-X76dTw8dI/I... [2] https://groups.google.com/d/msg/comp.lang.lisp/3-X76dTw8dI/sJOFnp1puKMJ https://groups.google.com/d/msg/comp.lang.lisp/3-X76dTw8dI/s... Snippet from [2]: If one were starting from scratch, and supplied a platform like .NET, would one define Lisp the way CL is defined? I would hope the answer is 'most definitely not'. For instance, .NET provides for numbers, characters, strings, arrays, hashtables, exceptions, namespaces, files, streams, user-defined types, a type hierarchy and inheritance, I/O, object creation and initialization, reflection etc. Should a language define its own incompatible versions of these things in such an environment?
rprospero 13y ago
Honestly, I'm far more of a Schemer than a... Clojurite?Clojurist? Clojourneyman? I did try to make the switch to Common Lisp back in 2006, but I wasn't happy and went back to Scheme. Still, I'm far more interested in learning Clojure than giving Common Lisp another try. Here's what makes the difference for me: 1)Library support. With Clojure, it's a five minute import to get Bessel functions. When I asked about how to do Bessel functions in 2006, I was told to write it myself. I've heard things have become better since then, but I haven't been able to find any evidence that 2)Immutable data structures. Yes, this can be implemented as a library in CL. However, having it as the default means that I know every non-Java function I call isn't going to break that assumption. If I did find a Bessel function library, I can't assume that it's safe. 3)GUI support. In 2006, I needed to write a GUI application that ran on Windows, Mac, and Linux. PLT Scheme (now racket) had options available, but they weren't pretty. When I went to Common Lisp, I was first directed toward CLX, which wasn't native on Mac or Windows. Someone then suggested McClim, which still needed an X-server on Windows and now seems to be largely dead. It was then suggested that I write my own binding to WXwidgets. I considered that, but I'd then need to write a high level wrapper over those low level bindings. Comparatively, from the little I've toyed with the Seesaw library from Clojure, it seems to be a beautiful way of handling GUIs. Okay, I guess this comes down to another library issues. 4)Dotted pairs. The only use I've ever encountered for these is extremely fine tuning performance optimizations, but third party libraries loved surprising me with these at odd moments. I can see how Lisp-1 versus Lisp-2 might be a matter of taste, but I've never heard someone complain that how they missed dotted pairs when working in Scheme or Clojure. They may be a good argument, but I've never heard it. 5) Libraries. I'm sorry that I keep coming back to this point, but I guess it's a big one. Every time I tried to do something interesting in Common Lisp, the recommendation that I was given was to write low level wrappers to three different C libraries. For several of those projects, I found it easier to just cut out the middle man and write the whole damn thing in C. The rest of the time, I wound up writing Lisp that looked almost exactly like C. Honestly, half of this is because I'm a mediocre programmer. I have no pretensions of greatness. If I was a great programmer, I could see how to make my own DSL that made the interaction of the libraries beautiful, instead of C with more parentheses. However, in scheme or clojure, I can usually find the work of another, better programmer, who has already made that DSL. In Common Lisp, I'm usually told to write it myself. I don't know if that's because all the other Common Lisp programmers are so brilliant that they all write DSLs all day or if it's just because they're all mediocre programmers like myself and no one knows how to do it. 6) Global variables. Every examples of idiomatic Common Lisp code I was delivered was littered with globals. This might be a stylistic decision, but it's one I've never liked. A third of my problems seemed to be solved by setting OPEN-NETWORK-SOCKET-AND-SET-FIRE-TO-PRINTER to 1 and STOP-PRINTER-FIRE to nil. I can see this reliance on globals if you're writing servers, where you have a long running application with lots of state, but I wasn't, so it just made the code harder to reason about. 7)Image based programming. I understand from the SmallTalkers that this is the best way to write code, but I don't get it. What always happened for me was that some global SWITCH-CHARACTER-ENCODING-TO-EBCDIC would get set at some point and all my code would now fail. With a file based language, I'd exit and restart to kill this accidental state and everything would be okay. With the image based code, I'd have to go through the assorted globals and find which one had changed.
coldtea 13y ago
>The interesting parts of Clojure (i.e., the sequence abstraction design) are replicatable in CL as a library. The interesting part of Clojure for me is that the sequence abstraction design is part of the standard language distribution and NOT implemented as an optional library. The major flaw with Lisps is exactly the proliferation of competing, (and frequently half-arsed), custom solutions for stuff that should be built-in and used by all. I'll take a slightly inferior implementation of something that's standard in a language's libs, over 20 competing solutions or rolling my own, any day of the week.
abp 13y ago
http://www.drdobbs.com/architecture-and-design/the-clojure-philosophy/240150710/ http://www.drdobbs.com/architecture-and-design/the-clojure-p...

radicalcut 13y ago

Yeah, they do. And there's quite many of them actually. :-) Clojure might be big in the startup bubble, but that's about it I'm afraid.