6 ms·

I don't get the "fewer libraries/modules is a good thing". I like using libraries where some has already encountered and created work-arounds for all of the edg

I don't get the "fewer libraries/modules is a good thing". I like using libraries where some has already encountered and created work-arounds for all of the edge cases for a really domain specific problem I'm not very familiar with so that I can focus on business logic. Am I missing something? What's fast about blindly discovering a bunch of stumbling blocks that you never imagined existed? All that said, I'm a fan of lisps, I've just never used one in production.

filoeleven 5y ago
Perhaps it could have been stated better as “the language design removes the need for a multitude of competing libraries.” The statement should not be taken out of context from the rest of the paragraph, which includes, “These libraries are also generally very high quality…” This means that the two or three libraries you find are more likely to handle all of those edge cases you mentioned. Some libraries haven’t been updated in years because they’ve solved the problem they set out to solve, and nobody’s found a fault with them since then.
didibus 5y ago
There are two types of libraries, the ones that deliver domain specific needs, like a web server, an encryption library, a midi library, a GUI library, a diagraming library, a pdf library, a zip library, a logging library, a database connector library, etc. In Clojure, those all exist, generally by simply reusing the ones that Java or Javascript already invested time and effort into building, though sometimes it has its own as well. The other type of library are generally conveniences, they either simplify existing APIs, add programming constructs, or template/establish a pattern for doing something. These are the ones you tend to not need as much in Clojure, because the language is already so expressive and succinct, and it is pretty trivial to implement your own custom conveniences directly focused to your application needs and your personal preferences.
Orou 5y ago
I agree libraries are great when dealing with very specific domain problems (who wants to hand-roll a datetime module?). But there are also a ton of libraries that aren't for such specific domains or which attempt to bridge multiple domains (i.e. frameworks). The argument made by functional languages like Clojure is that by making heavy use of pure function composition, you don't actually need a million libraries to build large/complex systems. You can do it with a much smaller number of libraries where necessary and take advantage of the language's natural extensibility for the rest.
jdminhbg 5y ago
I think the point here is that it's better to not need a library in the first place than to have tons of choices. As an extreme example, consider NPM's left-pad that caused such a huge mess when it was pulled by its author. It's not good that JS has a left-pad package, because it just shows a gaping hole in what should be JS's standard library. Slightly more abstractly, Clojure's data-oriented paradigm makes a lot of libraries from other languages redundant, because you can simply map and reduce and assoc Clojure maps instead of writing boilerplate.

filoeleven 5y ago

Perhaps it could have been stated better as “the language design removes the need for a multitude of competing libraries.” The statement should not be taken out of context from the rest of the paragraph, which includes, “These libraries are also generally very high quality…” This means that the two or three libraries you find are more likely to handle all of those edge cases you mentioned. Some libraries haven’t been updated in years because they’ve solved the problem they set out to solve, and nobody’s found a fault with them since then.

didibus 5y ago

There are two types of libraries, the ones that deliver domain specific needs, like a web server, an encryption library, a midi library, a GUI library, a diagraming library, a pdf library, a zip library, a logging library, a database connector library, etc. In Clojure, those all exist, generally by simply reusing the ones that Java or Javascript already invested time and effort into building, though sometimes it has its own as well. The other type of library are generally conveniences, they either simplify existing APIs, add programming constructs, or template/establish a pattern for doing something. These are the ones you tend to not need as much in Clojure, because the language is already so expressive and succinct, and it is pretty trivial to implement your own custom conveniences directly focused to your application needs and your personal preferences.

Orou 5y ago

I agree libraries are great when dealing with very specific domain problems (who wants to hand-roll a datetime module?). But there are also a ton of libraries that aren't for such specific domains or which attempt to bridge multiple domains (i.e. frameworks). The argument made by functional languages like Clojure is that by making heavy use of pure function composition, you don't actually need a million libraries to build large/complex systems. You can do it with a much smaller number of libraries where necessary and take advantage of the language's natural extensibility for the rest.

jdminhbg 5y ago

I think the point here is that it's better to not need a library in the first place than to have tons of choices. As an extreme example, consider NPM's left-pad that caused such a huge mess when it was pulled by its author. It's not good that JS has a left-pad package, because it just shows a gaping hole in what should be JS's standard library. Slightly more abstractly, Clojure's data-oriented paradigm makes a lot of libraries from other languages redundant, because you can simply map and reduce and assoc Clojure maps instead of writing boilerplate.