3 ms·

The point the author brings up about the lack of Lisp modules in 2005 is an interesting one and reminds me of the article "Why Perl Didn't Win", posted within t

by bmh100 12y ago

The point the author brings up about the lack of Lisp modules in 2005 is an interesting one and reminds me of the article "Why Perl Didn't Win", posted within the last few days. Browsing clojars.org, a Clojure repository, reveals that there are 11,435 libraries at the time of my writing. That is a great improvement, vastly exceeding the author's positive example of Python's 249 modules at the time. PyPI, a Python repository, currently lists 54,060, so clearly Python is still much more popular than Clojure. Yet, the 11K Clojure libraries seems to be a direct contradiction to his statement: "And lisp modules? Well, every part of the code can modify every other part. You can write a whole new grammar if you're so inclined. None of this helps with the goal of downloading a random package and easily calling whatever you want from it with minimal hassle. There's just a fundamental conflict between easy modularity on the one hand, which requires lots of restrictions and boring standard forms, and fluid modifiability on the other." The Clojure community has made great strides in promoting the adoption of a Lisp among programmers and enterprises.

MrBuddyCasino 12y ago
It certainly helps that it is idiomatic to use Java libs in Clojure, and the Maven repository has 800k+ artifacts.
- bmh100 12y ago
  No doubt. The ability to create a Clojure wrapper around an existing Java library makes bootstrapping a "new" library much faster, while also providing a bridge to Java programmers.
shassard 12y ago
Quicklisp (http://quicklisp.org/ http://quicklisp.org/) is a great resource for Common Lisp libraries. While it doesn't have the huge volume of libraries that's available for Clojure, it's a quality, curated, easy to use source. Combining Quicklisp and SBCL give you a great toolset for getting started with Common Lisp development.
- TeMPOraL 12y ago
  I agree. Common Lisp libraries also tend to be high quality and I'm sometimes amazed by the forethought and attention to details some authors have. Though I sometimes wish there were more libraries.
austinz 12y ago
I think it also helps that, in practice, there seems to be a common philosophy (at least among the Clojurists I've talked to) that macros should be used only when absolutely necessary. Because of this, the sort of unrestrained, ubiquitous code rewriting that the author mentions is rare.
- bmh100 12y ago
  Yes, and a lot of that can also be traced back to the built-in macros that Clojure provides and encourages. Macros like apply, ->, ->>, partial, memoize, and even . just make it so much rarer that a developer needs to write a macro outside of DSL development. It's wonderful.
  - bmh100 12y ago
    Could someone who downvoted this post please offer feedback? I do not understand why this comment did not contribute to the discussion.
    - tim333 12y ago
      I didn't downvote but as someone who uses Python and doesn't know Clojure, phrases like "Macros like apply, ->, ->>, partial, memoize, and even . just make it so much rarer that a developer needs to write a macro" make me glad I don't have to muck about with that stuff.(?)
- dragonwriter 12y ago
  > I think it also helps that, in practice, there seems to be a common philosophy (at least among the Clojurists I've talked to) that macros should be used only when absolutely necessary. Sure. One thing about that is that the DRY principle -- and the expanded form, "don't repeat anyone, ever" -- has been a popular mantra throughout the programming community for a while (and even before that particular form, emphasis on reusable code was common), and Clojure has really come into its own in the time when that that philosophy has been strong. One of the great things about macros is that they enable reusable solutions to broader problems than you can effectively address in library code in many languages; a corollary of which is that most programming in a language with macros should need neither to define new macros nor to use the repetitive boilerplate code that macros enable reusable alternatives to.

by bmh100 12y ago

MrBuddyCasino 12y ago

It certainly helps that it is idiomatic to use Java libs in Clojure, and the Maven repository has 800k+ artifacts.

bmh100 12y ago
No doubt. The ability to create a Clojure wrapper around an existing Java library makes bootstrapping a "new" library much faster, while also providing a bridge to Java programmers.

shassard 12y ago

Quicklisp (http://quicklisp.org/ http://quicklisp.org/) is a great resource for Common Lisp libraries. While it doesn't have the huge volume of libraries that's available for Clojure, it's a quality, curated, easy to use source. Combining Quicklisp and SBCL give you a great toolset for getting started with Common Lisp development.

TeMPOraL 12y ago
I agree. Common Lisp libraries also tend to be high quality and I'm sometimes amazed by the forethought and attention to details some authors have. Though I sometimes wish there were more libraries.

austinz 12y ago

I think it also helps that, in practice, there seems to be a common philosophy (at least among the Clojurists I've talked to) that macros should be used only when absolutely necessary. Because of this, the sort of unrestrained, ubiquitous code rewriting that the author mentions is rare.

bmh100 12y ago
Yes, and a lot of that can also be traced back to the built-in macros that Clojure provides and encourages. Macros like apply, ->, ->>, partial, memoize, and even . just make it so much rarer that a developer needs to write a macro outside of DSL development. It's wonderful.
- bmh100 12y ago
  Could someone who downvoted this post please offer feedback? I do not understand why this comment did not contribute to the discussion.
  - tim333 12y ago
    I didn't downvote but as someone who uses Python and doesn't know Clojure, phrases like "Macros like apply, ->, ->>, partial, memoize, and even . just make it so much rarer that a developer needs to write a macro" make me glad I don't have to muck about with that stuff.(?)
dragonwriter 12y ago
> I think it also helps that, in practice, there seems to be a common philosophy (at least among the Clojurists I've talked to) that macros should be used only when absolutely necessary. Sure. One thing about that is that the DRY principle -- and the expanded form, "don't repeat anyone, ever" -- has been a popular mantra throughout the programming community for a while (and even before that particular form, emphasis on reusable code was common), and Clojure has really come into its own in the time when that that philosophy has been strong. One of the great things about macros is that they enable reusable solutions to broader problems than you can effectively address in library code in many languages; a corollary of which is that most programming in a language with macros should need neither to define new macros nor to use the repetitive boilerplate code that macros enable reusable alternatives to.