Hacker News Reader

Comment by fivea | Hacker News Reader

> How would such a trivial library achieve popularity?

There is no size limit on how many features could ship with a library. In fact, we live in an age where packages like rimraff report around 50 million downloads per week.

But the original question, and the point it made,still stand: why isn't there such a library to provide such a feature? Might it be that you're overblowing it's demand and usefulness? Perhaps there is no such thing in the standard library because no one bothers with it, or feels it's missing?

View on HN

I already gave you an example of a C library that provided that functionality.

And no, people don't reuse trivial libraries in C, this is not JavaScript.

Cross plateform make directory is trivial?

> And no, people don't reuse trivial libraries in C, this is not JavaScript.

You do realize that tribalist arguments based on absolutely no technical point whatsoever do not make any sense at all, don't you? I mean, who in their right mind would argue that only nodejs developers need to delete dirs?

And if you believe that putting together a reliable cross-platform library that handles idempotent directory creation then be my guest and just do it. How hard would it be, right?

This is merely a factual comment.

Node.JS is widely known for having people depend on trivial packages (I vaguely remember some story about half the world being affected because the package doing a trim space went down).

The same is not true for C. Libraries there tend to cover larger domains.

Whether that is caused by technical limitations, culture, or competence of the developers is all irrelevant to that statement.

Libraries are a pain in C. So most C programs use less of them, than if you are writing js

> Libraries are a pain in C.

They really aren't. At all. What exactly are the pain points you experienced with C libraries?

> So most C programs use less of them

This assertion doesn't hold any water. In all the years I worked with C and C++ projects, not even once did I ever heard "let's not add a library, it's hard".

Do you actually have a concrete, real issue in mind?

> What exactly are the pain points you experienced with C libraries?

1. Varying build systems. Does the dependency use cmake? Autoconf? A shell script where you’re instructed to modify some variables specific to your system?

2. The above, but my software is shipping on Linux, windows, and Mac. What’s the best way to get this dependency compiled? Does upstream even support all these OSes?

In all my years of doing C programming, I’ve never seen some add a single function library like is_even and then another like is_odd. But you do see it in languages where it is really easy to add libraries.

in C I always end up building my own world because the default one is broken. for example null terminated strings are just really awful to work with. i'm not alone - alot of larger C projects have their own runtime, particularly memory management. another cross-cutting concern is multihreaded safety and scheduling.

unless the library author broke those functions out, then I need to rehost it in my environment. so I usually end up forking any library that I want to use. this isn't all bad - I find some bugs and integrate the build. I adopt the library and develop and understanding of it sufficient to maintain it myself.

contrast that to a language environment where those things - strings and threads and build are all standardized.

My point of view is that if you program in C you most likely care about being in control of what happens.

Your approach makes perfect sense within that context.

Reply on news.ycombinator.com