> As long as you understand the code and it solves your problem, owning is an advantage

Because the cost of acquiring an understanding of code that solves your problem might be much higher in Lisp than other languages, if the hypothesis is correct that the language facilitates the creation of bad half-baked libraries.

Just to give a somewhat figurative example, the jungle is a much more hospital environment for life in general than temperate environments (it's warmer, full of nutrients, bathed in constant solar energy).

However most humans didn't manage to really expand into the jungles successfully until the advent of modern medicine, because the life there was so prolific that there were all sorts of nasty parasites and diseases, and everything you build sinks into the jungle within years.

Lisp is like that jungle -- everything just grows fantastically easily, but paradoxically that makes it harder to separate the chaff from the wheat.

But these are symptoms; you're still basically arguing that Lisp gives the user too much power. And that's a valid perspective. I don't agree that a language can give the user too much power. Building tools for someone who's supposedly not as smart as your self is a great ego boost, and that's about it.

The less I have to maintain fundamental abstractions, the more energy I can spend building on top of these abstractions. There's a name for this: NIH [0].

While there are some folks [1] that have the time, energy, and brilliance to build things from the ground up all themselves, I unfortunately do not. Moreover, in a collegial work environment, this means the burden is on me to test, document, communicate, and educate on this library. There's enormous additional complexity and risk that comes with building from scratch things like these which change the whole programming paradigm of your application—again, especially in a coworking environment.

[0] https://en.m.wikipedia.org/wiki/Not_invented_here

[1] Donald Knuth and Fabrice Bellard, to name a few.

It is a fallacy that you are not maintaining something with your dependencies. It is the hope that you get nothing but benefits from depending on someone else to build strong dependencies. It is as true of a reality that they are pursuing goals that are not yours.

It is odd, because the "micro library" world ostensibly fixes this by greatly limiting the scope of a dependency. However, it also encourages chaining yourself to many other entities. And it is always the mistakes that people remember, such that anyone that has been burned will remember how it was enabled by micro libraries.

You are maintaining the API boundary between your application and your dependencies. I certainly do not maintain (in the most common sense of the word) my operating system source code, my compiler source code, my server source code, etc.

I have no problem with micro-libraries. In fact, I developed on the notion of the micro-est of libraries: a library generator that gets down to function-level dependencies [0].

[0] http://web.archive.org/web/20140711172208/http://symbo1ics.c...

> my operating system source code, my compiler source code, my server source code, etc.

Actually, you sort of do. You may not know it yet, if you were fortunate enough to never hit a problem with an update to one of them.

Exactly. And I wasn't trying to be anti micro services or libraries. Just pointing out that confirmation bias is a big reason some folks are against them.

It is amplified when folks push them with no caveats. Some of us remember being burned in ways this allowed.