Hacker News Reader

Comment by tushartyagi | Hacker News Reader

I just want to understand that given the mostly negative reaction that's here at HN to the npm ecosystem which is based on the same "minimalist libraries" idea, how is this different?

I'd appreciate if the response is not about JS and/or C, but about the minimalist libraries in JS, C, or any other language. Should I use a large number of small libraries? Should I wrap up some of the code which I use into a libraries even if that code is just a couple of functions without any data structure?

Moreover, I'd admit that I'm a great fan of Chris Wellons blog posts which are pretty technical and original, and use some of his emacs libraries on a daily basis.

View on HN

>I just want to understand that given the mostly negative reaction that's here at HN to the npm ecosystem which is based on the same "minimalist libraries" idea, how is this different?

It's different in that in C you don't pull in 200 dependencies which in-turn bring in another 10+ dependencies each.

You just use 2-3 libs you need (and that they, in turn, don't require anything, or at best the POSIX standard libs), and that's it.

I think the difference is the network of dependencies. Even small libraries on npm often depend on other libraries (e.g., the is-odd library linked in the article depends on is-number).

Minimalist libraries as in the op are generally done out of a fear of libraries, as if libraries take away control from the programmer and make the resulting program lesser. Minimalist libraries in npm arise out of a reverence towards libraries, as if something being implemented in a library is superior to an equivalent homebrewed implementation.

When the OP says a library should ideally have one function, they mean that the one function should do the brunt of the work, but leave any setup and takedown to the caller. When a node lib has a single function, this is because you are expected to import another lib for other purposes (eg left-pad for left padding, right-pad for right padding, rather than a single, generic pad library).

The difference is that there is no package tool. These libraries are not dependencies that can disappear or whose API will break. You are expected to copy them into your source tree, or even use only the idea and make your own version. Also, as my sibling poster points out, they are self-contained.

I think in recent years dogmatic minimalism has shown itself to be destructive. Time is wasted refactoring code and features are removed, reducing usability, all in service of an aesthetic that has lost sight of its purpose.

Each of the guidelines listed independently represent good practices, in general, when applicable. It's worth considering the design choices when developing a library. But promoting a definition of minimalism implicitly promotes an all-or-nothing approach to development. The choice to not include memory allocation should be entirely independent of the choice not to include I/O. Pretending otherwise indicates that the choices aren't driven by pragmatism.

Reply on news.ycombinator.com