[sapling-ginger]

The author first says that CL people usually avoid dependency hell:

>When programming applications in Common Lisp people will often depend on a small(ish) number of stable libraries, and library writers often try to minimize dependencies by utilizing as much of the core language as possible.

But then try to expound on CL's extensibility using libraries:

> No one has been clamoring for a new version of the specification that adds features because Common Lisp's extensibility allows users to add new features to the language as plain old libraries

Very contradictory, and these two paragraphs are in two adjacent sections.

[iLemming]

As other pointed out, there's no contradiction. I would like to add that CL often avoids dependency hell with:

- Standardized Specification: Common Lisp has a stable and comprehensive standard that reduces the need for external libraries.

- Load Time Flexibility: Its dynamic nature allows loading and reloading of code at runtime, facilitating easier management of dependencies.

- Isolation through Packages: The Lisp package system provides a way to encapsulate code and manage namespaces effectively, reducing conflicts.

- Backward Compatibility: Common Lisp places a strong emphasis on backward compatibility, which helps in maintaining stability across versions.

- Mature Ecosystem: Many Common Lisp projects are long-lived and stable, leading to a mature ecosystem with less frequent breaking changes.

I can't claim to be a very experienced CL coder, but I wrote enough Clojure, and similarly, rarely ever see dependency problems, even though Clojure heavily relies on the JVM ecosystem, inheriting both its strengths and complexities. Clojure emphasizes interoperability with Java and uses many Java libraries, which can introduce complex dependency trees and conflicts common in the Java ecosystem, yet at the same time, Clojure emphasizes small, composable libraries (often referred to as the "small libraries" philosophy), reducing the likelihood of large, monolithic dependencies causing issues. The community prioritizes modularity and ease of composition, leading to the prevalence of smaller, more focused libraries. Common Lisp in contrast tends to favor more extensive libraries or systems that provide a broad set of features within a single package.

[skydhash]

The thing is that’s once you’ve casted most external inputs to lisp data structures, you don’t really need anything else other than utility algorithms (crypto,…). And with metaprogramming, it’s easier to do stuff without special classes and decorator. You can visualize the code as data being transformed, as a chain of transformers, or when you do metaprogramming as data generating code and code generating data. It’s all organic and you can do a lot without external code, because very soon you’re coding with a language adapted to your problem domain.

To GP: Think about how simple the HTTP protocol is (the core), so if you want a web framework, you want something that will map the headers and the body to cl data structures and then you can go to solve smaller problems like routing, auth, response generation,… Then you notice boilerplate and you macro them out. Same for most client libraries. It really easy to add an ad-hoc library that solve your problems. So you do that instead of reaching to others’ code.

[kloop]

The lisp world has a rather different idea of extensibility via library than you are used to.

For example, the Common Lisp Object System (CLOS, object oriented programming in lisp) originated as a library. Lisp's main looping mechanism (loop) also originated as a macro (although long before CL standardization).

You just don't do js levels of dependencies when they're adding big features like that. You don't need 100,000 programming paradigms in your code base.

[mepian]

How is this contradictory? The point is that you can extend the language when you really need it.

[fuzztester]

I don't see any contradiction in those two points. Both of them can simultaneously be true.