4 ms·

This is one reason I really like Common Lisp and Clojure: both communities have developed a mindset that allows libraries to be done and, as a result, I notice

This is one reason I really like Common Lisp and Clojure: both communities have developed a mindset that allows libraries to be done and, as a result, I notice a lot less churn than in other languages.

eigenhombre 5y ago
I also like them for the same reason. The languages themselves evolve slowly (Clojure) or not at all (Common Lisp). A library that emphasizes simplicity and does One Thing Well can be stable and continue to be useful indefinitely. There are network effects too -- if my library uses stable libraries and is built on a stable language, it need not change at all. On the other hand, there are the big libraries that, for convenience, pull one or two small things from several others -- their surface area becomes so large they are practically guaranteed to generate more work in terms of security updates, dependency conflicts, and the like. I experience this at times developing in Clojure, whose hosted nature means issues can emerge from the Java ecosystem, which is obviously enormous and dynamic. We recently had a defect at work relating to a conflict between transitive (Java) dependencies from a third party library used to serialize exceptions prior to transmission to their service, and another tool used only for generating "literate"-style code documentation. While not a production defect, it cost us some time and could have been avoided (both by us and the libraries' authors) by more hard-headed evaluation of the tradeoffs involved in introducing certain dependencies in the first place.
cubano 5y ago
I would use Occam's razor with this idea and posit that it is much more like that its a lack of overall mindshare with functional programming than with the nature of language abstractions. Don't tell me that Lisp ever achieved cool-kid status that a thousand different libs wouldn't pop up basically overnight.
- strawhatguy 5y ago
  If the premise is that you limit your dependencies have low maintenance code, you'd probably not include many (any?) of said thousands of libs. Also it isn't about the number of libs, but how often they change.
- fiddlerwoaroof 5y ago
  I don’t think this is entirely right: there are plenty of languages with similarish mindshare that don’t have this: just building a Haskell project, for example, can be a nightmare if they hasn’t been maintained. Scala also has this issue, despite having a similar marketshare as Clojure.
- fulafel 5y ago
  The thing about allowing libraries being done is a bit more nuanced than not having lots of different libraries doing the same thing. There are lots of competing libraries even now and existing libraries do get surpassed in popularity. But they keep working and don't become unusable or problematic as often as in other cultures.

eigenhombre 5y ago

I also like them for the same reason. The languages themselves evolve slowly (Clojure) or not at all (Common Lisp). A library that emphasizes simplicity and does One Thing Well can be stable and continue to be useful indefinitely. There are network effects too -- if my library uses stable libraries and is built on a stable language, it need not change at all. On the other hand, there are the big libraries that, for convenience, pull one or two small things from several others -- their surface area becomes so large they are practically guaranteed to generate more work in terms of security updates, dependency conflicts, and the like. I experience this at times developing in Clojure, whose hosted nature means issues can emerge from the Java ecosystem, which is obviously enormous and dynamic. We recently had a defect at work relating to a conflict between transitive (Java) dependencies from a third party library used to serialize exceptions prior to transmission to their service, and another tool used only for generating "literate"-style code documentation. While not a production defect, it cost us some time and could have been avoided (both by us and the libraries' authors) by more hard-headed evaluation of the tradeoffs involved in introducing certain dependencies in the first place.

cubano 5y ago

I would use Occam's razor with this idea and posit that it is much more like that its a lack of overall mindshare with functional programming than with the nature of language abstractions. Don't tell me that Lisp ever achieved cool-kid status that a thousand different libs wouldn't pop up basically overnight.

strawhatguy 5y ago
If the premise is that you limit your dependencies have low maintenance code, you'd probably not include many (any?) of said thousands of libs. Also it isn't about the number of libs, but how often they change.
fiddlerwoaroof 5y ago
I don’t think this is entirely right: there are plenty of languages with similarish mindshare that don’t have this: just building a Haskell project, for example, can be a nightmare if they hasn’t been maintained. Scala also has this issue, despite having a similar marketshare as Clojure.
fulafel 5y ago
The thing about allowing libraries being done is a bit more nuanced than not having lots of different libraries doing the same thing. There are lots of competing libraries even now and existing libraries do get surpassed in popularity. But they keep working and don't become unusable or problematic as often as in other cultures.